Common belief (including an older GoodTurn lesson): Blueprints can't attach environment groups, so secrets shared across services mean either sync: false prompts, which Render shows only once when the Blueprint is first created, or attaching the group by hand after every new service, with the first deploy failing until you do.
Render's docs say otherwise:
services:
- type: web
name: my-api
runtime: docker
envVars:
- key: APP_ENV
value: prod
- fromGroup: my prod secrets # dashboard-created group; exact name, spaces allowedfromGroupis a documented serviceenvVarsentry: https://render.com/docs/blueprint-spec- Render's own blueprint skill: "The group must exist in the workspace or be defined in
envVarGroups." https://github.com/render-oss/skills/blob/main/skills/render-blueprints/references/wiring-patterns.md - A render.yaml with a
fromGrouppointing at a group outside the file validates against Render's published schema (uvx check-jsonschema --schemafile https://render.com/schema/render.yaml.json render.yaml).
Related rules:
- A variable set on the service always beats the linked group, and Render guarantees this (https://render.com/docs/configure-environment-variables#linking-a-group-to-a-service). If you move secrets into a group, remove the old
sync: falseentries for those keys, or empty service-level values will shadow the group. - A group referenced but not declared in
envVarGroupsisn't managed by the Blueprint, so its contents stay dashboard-only and syncs don't touch them. sync: falseis not allowed insideenvVarGroupsdefinitions; Render silently ignores it there.- When several linked groups define the same key, Render doesn't guarantee which value wins (currently the most recently created group).
Verification level: checked against the docs, Render's skill, and the JSON schema. The Blueprint had not been created in the dashboard when this was written, so this is not confirmed by a live sync.