The current render_env_group_link resource appears to model the full set of services linked to an env group:
resource "render_env_group_link" "example" {
env_group_id = "evg-..."
service_ids = ["srv-..."]
}
That works when one Terraform state owns the entire service set for an env group, but it does not compose well when multiple Terraform roots/modules each need to link one service to the same shared env group.
A per-edge resource would map directly to Render’s existing Link/Unlink service API endpoints:
- Link service: POST /v1/env-groups/{envGroupId}/services/{serviceId}
- Unlink service: DELETE /v1/env-groups/{envGroupId}/services/{serviceId}
If an env group is shared across multiple independently managed services, each Terraform root currently has to manage the whole service_ids set. That causes ownership conflicts across Terraform states.
Example:
# root A
resource "render_env_group_link" "shared" {
env_group_id = "evg-shared"
service_ids = [render_private_service.a.id]
}
# root B
resource "render_env_group_link" "shared" {
env_group_id = "evg-shared"
service_ids = [render_private_service.b.id]
}
Root B cannot safely append its service without taking ownership of root A’s link. In practice this can fail with:
service link already exists for evg-...
import the existing service link before adding a new service
Even if each root imports the same evg-..., both roots still own the authoritative full set and can race or remove links created by another root.
Proposed Resource
Add a resource that manages exactly one env-group/service edge:
resource "render_env_group_service_link" "this" {
env_group_id = var.shared_env_group_id
service_id = render_private_service.this.id
}
Expected Behavior:
- Create: call POST /v1/env-groups/{envGroupId}/services/{serviceId}.
- Read: retrieve the env group and confirm serviceId is present in its service links.
- Delete: call DELETE /v1/env-groups/{envGroupId}/services/{serviceId}.
- env_group_id and service_id should likely be ForceNew / replacement-only.
- If the link already exists during create, treating that as success would make the resource idempotent and import-friendly.
- If the link is absent during delete/read, handle it like other deleted remote objects.
This lets separately managed services independently declare without any one root needing to know or own every other linked service.
The existing render_env_group_link resource can remain useful for cases where one Terraform state intentionally owns the complete set. This proposed resource would cover the composable “ensure this one service is linked” use case.
The current
render_env_group_linkresource appears to model the full set of services linked to an env group:That works when one Terraform state owns the entire service set for an env group, but it does not compose well when multiple Terraform roots/modules each need to link one service to the same shared env group.
A per-edge resource would map directly to Render’s existing Link/Unlink service API endpoints:
If an env group is shared across multiple independently managed services, each Terraform root currently has to manage the whole service_ids set. That causes ownership conflicts across Terraform states.
Example:
Root B cannot safely append its service without taking ownership of root A’s link. In practice this can fail with:
Even if each root imports the same evg-..., both roots still own the authoritative full set and can race or remove links created by another root.
Proposed Resource
Add a resource that manages exactly one env-group/service edge:
Expected Behavior:
This lets separately managed services independently declare without any one root needing to know or own every other linked service.
The existing
render_env_group_linkresource can remain useful for cases where one Terraform state intentionally owns the complete set. This proposed resource would cover the composable “ensure this one service is linked” use case.