version: "1.0.0" name: render-env-vars description: >- Configures environment variables, secrets, and env groups on Render. Use when the user needs to set env vars, wire secrets between services, create env groups, use generateValue, set sync: false, or troubleshoot missing or incorrect environment variable values in Blueprints or the Dashboard. license: MIT compatibility: Render Dashboard, CLI, or MCP tools metadata: author: Render version: "1.0.0" category: configuration

Environment Variables on Render

Render exposes configuration to services as environment variables. Values are always strings at the platform layer—applications must parse numbers, booleans, and structured data explicitly.

There are three primary ways to set variables:

1. Render Dashboard — per-service UI, bulk import from .env, save/redeploy options
2. Blueprint — envVars (and related keys) in render.yaml
3. MCP / API — e.g. update_environment_variables on a service

Deep wiring patterns, full platform variable tables, and language-specific notes live under references/.

When to Use This Skill

Use this skill when users want to:

• Add, change, or remove environment variables or secrets
• Understand Dashboard vs Blueprint vs API/MCP flows
• Use environment groups for shared configuration
• Wire fromDatabase, fromService, fromGroup, sync: false, or generateValue in Blueprints
• Debug missing vars, secret files, precedence, or platform-injected names

For full Blueprint authoring, pair with render-blueprints. For first-time deploys, render-deploy. For web service behavior and ports, render-web-services.

Setting Variables

Dashboard

• Add variables individually (name + value) or in bulk by pasting/uploading a .env-style file.
• Save options typically include:
• Save and rebuild & deploy — picks up build-time changes
• Deploy only — runtime change without a full rebuild (when applicable)
• Save only — persist without triggering a deploy

Use Dashboard edits when iterating quickly or when the repo should not carry certain values.

Blueprint (render.yaml)

Declare envVars on each service. Values can be literals, generated secrets, sync-disabled prompts, or references to databases, other services, or env groups. See Blueprint Wiring below and references/wiring-reference.md for exhaustive patterns and YAML.

MCP / API

Automation tools can set variables on existing services (e.g. update_environment_variables). Useful for CI, rotation, or keeping Dashboard state in sync with external secret stores—without committing secrets to Git.

Secret Management

• `sync: false` — Render prompts in the Dashboard for the value only on initial Blueprint setup when the resource is first created. On Blueprint updates, sync: false is ignored (values are not re-prompted from the file alone). These vars are excluded from preview environments and are invalid inside environment groups.
• `generateValue: true` — Render generates a base64-encoded 256-bit random value at provision time. Use for passwords, signing keys, or tokens that do not need human-chosen values.
• Never commit real secrets in render.yaml as plain value: entries. Prefer Dashboard, secret manager integration, generateValue, or sync: false with Dashboard entry.

Secret files

• Store sensitive file content as secret files (not inline env strings). They appear as plaintext files under `/etc/secrets/<filename>`.
• Combined limit: 1 MB total secret file payload per service or per linked env group (as applicable to your setup).
• Docker: secret files are available under `/etc/secrets/` on the running instance.

Environment Groups

Environment groups are named collections of variables linked to multiple services.

• Precedence: Service-level variables override variables from linked groups with the same name.
• Multiple groups on one service: the group that was most recently created wins for overlapping keys. This ordering is not documented as stable—avoid relying on it; use distinct names or consolidate groups.
• Groups can be scoped to a project environment so staging and production differ without duplicating every service definition.

Blueprint Wiring (Summary)

Full syntax, examples, and edge cases: references/wiring-reference.md. Authoritative Blueprint docs: render-blueprints skill.

Platform-Injected Variables

Render sets read-only variables your app can read at runtime (and some at build). A concise list:

Build vs runtime availability, language version env vars, and WEB_CONCURRENCY defaults: references/platform-variables.md.

Runtime-Specific Defaults

Render and buildpacks may set defaults (verify in your service’s Environment tab):

Always bind HTTP servers to `0.0.0.0` and `PORT` (or the stack’s documented port env) unless using a static site or custom Docker entrypoint.

Common Issues

1. Everything is a string — DEBUG=false is truthy in many parsers; use explicit comparison or typed config loaders.
2. `WEB_CONCURRENCY` — Default behavior changed for services created after December 8, 2025. Compare with older services when debugging worker counts; see references/platform-variables.md.
3. Undocumented `RENDER_*` variables — Names and semantics may change; do not depend on undocumented injection for critical logic.
4. Blueprint vs Dashboard drift — Editing only render.yaml does not retroactively apply sync: false prompts on update; merge strategy for env keys is easy to misunderstand—test in a scratch service.
5. Secret file paths — Code must read `/etc/secrets/<filename>`; wrong paths or missing mounts usually show as file-not-found at runtime.

References

• references/wiring-reference.md — Complete Blueprint envVar wiring, YAML examples, precedence, edge cases
• references/platform-variables.md — Injected variables (build vs runtime), language versions, concurrency, reading vars from code

Related Skills

• render-blueprints — Full Blueprint authoring, validation, multi-service layouts
• render-deploy — First deploy, repo requirements, MCP vs YAML
• render-web-services — Ports, health checks, scaling behavior tied to env-driven servers