← RenderCONTENT HISTORY
WHAT CHANGED
changed
changed
Update to Render
Snapshot Oct 24, 2026 · 12:46 UTC · version 1.0.2
Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.
Instructions updated for render-env-vars
Skill instructions — Now says: Before inspecting or changing environment variables, secrets, secret files, or environment groups, read `references/environment-variables.md` for the current...
Observed in instructions or declared skills. Runtime behavior has not been tested.
Save Render and check future changes in Following.
Up to 10 plugins free · no card required.
All fields and original values.
Skill instructions
Before
Sep 30, 2026 · 22:43 UTC
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...
After
Oct 24, 2026 · 12:46 UTC
Before inspecting or changing environment variables, secrets, secret files, or environment groups, read `references/environment-variables.md` for the current documentation, source-of-truth, safety, and mutation workflow. Blueprint wiring...
Supporting files
Before
Sep 30, 2026 · 22:43 UTC
[{"relative_path":"references/platform-variables.md","size_in_bytes":5014},{"relative_path":"references/wiring-reference.md","size_in_bytes":6628}]
After
Oct 24, 2026 · 12:46 UTC
[{"relative_path":"references/environment-variables.md","size_in_bytes":4653},{"relative_path":"references/platform-variables.md","size_in_bytes":1329},{"relative_path":"references/wiring-reference.md","size_in_bytes":4459}]
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -15,15 +15,9 @@ # 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. +Before inspecting or changing environment variables, secrets, secret files, or environment groups, read `references/environment-variables.md` for the current documentation, source-of-truth, safety, and mutation workflow. -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/`. +Blueprint wiring examples and language-specific application notes live under `references/`. ## When to Use This Skill @@ -37,111 +31,47 @@ 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. - -| Mechanism | Role | -|-----------|------| -| `value` | Hardcoded string (non-secret config only) | -| `generateValue: true` | Platform-generated secret | -| `sync: false` | Dashboard prompt on **initial** create only | -| `fromDatabase` | Inject DB fields (`connectionString`, `host`, `port`, `user`, `password`, `database`) | -| `fromService` | Key Value: `type: keyvalue` + properties; private/web: `host`, `hostport`, or `envVarKey` | -| `fromGroup` | Link all vars from a named group | +After reading `references/environment-variables.md`, use `references/wiring-reference.md` for task-specific `fromDatabase`, `fromService`, and `fromGroup` examples. Consult **render-blueprints** for the complete Blueprint workflow. ## Platform-Injected Variables -Render sets **read-only** variables your app can read at runtime (and some at build). A concise list: - -| Variable | Typical meaning | -|----------|-----------------| -| `RENDER` | `"true"` when running on Render | -| `RENDER_SERVICE_TYPE` | Service kind (e.g. web, worker) | -| `RENDER_SERVICE_ID` | Service identifier | -| `RENDER_SERVICE_NAME` | Human-readable service name | -| `RENDER_INSTANCE_ID` | Current instance | -| `RENDER_EXTERNAL_URL` | Public URL (when applicable) | -| `RENDER_EXTERNAL_HOSTNAME` | Public hostname | -| `RENDER_DISCOVERY_SERVICE` | Service discovery hostname (private network) | -| `RENDER_GIT_COMMIT` | Deployed commit SHA | -| `RENDER_GIT_BRANCH` | Branch for this deploy | -| `PORT` | HTTP port to bind (**default `10000`**) | -| `IS_PULL_REQUEST` | Preview deploy indicator | -| `RENDER_CPU_COUNT` | vCPU count for the instance | -| `RENDER_WEB_CONCURRENCY` | Suggested worker/process count hint | - -Build vs runtime availability, language version env vars, and **WEB_CONCURRENCY** defaults: `references/platform-variables.md`. +Use the current default-variable reference fetched through `references/environment-variables.md` instead of relying on a fixed catalog. Language-specific application notes remain in `references/platform-variables.md`. ## Runtime-Specific Defaults -Render and buildpacks may set defaults (verify in your service’s **Environment** tab): - -| Runtime | Notable defaults | -|---------|------------------| -| **Node.js** | `NODE_ENV=production` | -| **Python** | `PYTHON_VERSION` (pinned by build); Gunicorn-oriented images often set `GUNICORN_CMD_ARGS` to bind **`0.0.0.0:10000`** | -| **Ruby** | `RAILS_ENV=production`, `RAILS_LOG_TO_STDOUT=true` | -| **Go** | `GO111MODULE=on` (legacy modules flag; still seen on older stacks) | -| **Rust** | `ROCKET_PORT=10000` (Rocket convention) | - 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. +- When diagnosing a port-binding failure, first establish whether the service uses a native runtime or Docker and inspect its actual start command; the applicable defaults differ. +- For a web service, `PORT` defaults to **`10000`**. Prefer reading `$PORT` in the start command rather than hardcoding that number or setting `PORT` merely to match an arbitrary hardcoded port. +- Native Python services currently receive `GUNICORN_CMD_ARGS` with a default bind to **`0.0.0.0:10000`**. A custom Gunicorn start command should bind to **`0.0.0.0:$PORT`** so the process and Render's health checks use the same port. + ## 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. +`WEB_CONCURRENCY` defaults differ for some older and newer services. When debugging worker counts, compare service creation date and explicit overrides, then confirm current behavior using `references/environment-variables.md` and `references/platform-variables.md`. ## 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 +- `references/environment-variables.md` — Current configuration docs, secret handling, groups, platform variables, and mutation safety +- `references/wiring-reference.md` — Blueprint cross-resource wiring examples and workspace edge cases +- `references/platform-variables.md` — Concurrency, native-runtime versus Docker behavior, and application parsing notes ## 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 + +<!-- shared:documentation-retrieval --> +## Current documentation retrieval + +Whenever this skill directs you to consult current Render documentation: + +1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as `curl`. Do not substitute web-search summaries for the document. +2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient. +3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead. +4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details. + +When a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable. +<!-- /shared:documentation-retrieval -->
Full technical diff · 2 changed fields
changed /included_files
BEFORE
[
{
"relative_path": "references/platform-variables.md",
"size_in_bytes": 5014
},
{
"relative_path": "references/wiring-reference.md",
"size_in_bytes": 6628
}
]AFTER
[
{
"relative_path": "references/environment-variables.md",
"size_in_bytes": 4653
},
{
"relative_path": "references/platform-variables.md",
"size_in_bytes": 1329
},
{
"relative_path": "references/wiring-reference.md",
"size_in_bytes": 4459
}
]changed /skill_md_contents
BEFORE
"---\nname: render-env-vars\ndescription: >-\n Configures environment variables, secrets, and env groups on Render. Use when\n the user needs to set env vars, wire secrets between services, create env\n groups, use generateValue, set sync: false, or troubleshoot missing or\n incorrect environment variable values in Blueprints or the Dashboard.\nlicense: MIT\ncompatibility: Render Dashboard, CLI, or MCP tools\nmetadata:\n author: Render\n version: \"1.0.0\"\n category: configuration\n---\n\n# Environment Variables on Render\n\nRender exposes configuration to services as **environment variables**. Values are always **strings** at the platform layer—applications must parse numbers, booleans, and structured data explicitly.\n\nThere are **three** primary ways to set variables:\n\n1. **Render Dashboard** — per-service UI, bulk import from `.env`, save/redeploy options\n2. **Blueprint** — `envVars` (and related keys) in `render.yaml`\n3. **MCP / API** — e.g. `update_environment_variables` on a service\n\nDeep wiring patterns, full platform variable tables, and language-specific notes live under `references/`.\n\n## When to Use This Skill\n\nUse this skill when users want to:\n\n- Add, change, or remove environment variables or secrets\n- Understand Dashboard vs Blueprint vs API/MCP flows\n- Use **environment groups** for shared configuration\n- Wire `fromDatabase`, `fromService`, `fromGroup`, `sync: false`, or `generateValue` in Blueprints\n- Debug missing vars, secret files, precedence, or platform-injected names\n\nFor full Blueprint authoring, pair with **render-blueprints**. For first-time deploys, **render-deploy**. For web service behavior and ports, **render-web-services**.\n\n## Setting Variables\n\n### Dashboard\n\n- Add variables **individually** (name + value) or **in bulk** by pasting/uploading a `.env`-style file.\n- **Save options** typically include:\n - **Save and rebuild & deploy** — picks up build-time changes\n - **Deploy only** — runtime change without a full rebuild (when applicable)\n - **Save only** — persist without triggering a deploy\n\nUse Dashboard edits when iterating quickly or when the repo should not carry certain values.\n\n### Blueprint (`render.yaml`)\n\nDeclare `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.\n\n### MCP / API\n\nAutomation 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.\n\n## Secret Management\n\n- **`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**.\n- **`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.\n- **Never commit real secrets** in `render.yaml` as plain `value:` entries. Prefer Dashboard, secret manager integration, `generateValue`, or `sync: false` with Dashboard entry.\n\n### Secret files\n\n- Store sensitive file content as **secret files** (not inline env strings). They appear as **plaintext files** under **`/etc/secrets/<filename>`**.\n- **Combined limit**: **1 MB** total secret file payload per service or per linked env group (as applicable to your setup).\n- **Docker**: secret files are available under **`/etc/secrets/`** on the running instance.\n\n## Environment Groups\n\n**Environment groups** are named collections of variables linked to **multiple services**.\n\n- **Precedence**: **Service-level** variables **override** variables from linked groups with the same name.\n- **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.\n- Groups can be **scoped to a project environment** so staging and production differ without duplicating every service definition.\n\n## Blueprint Wiring (Summary)\n\nFull syntax, examples, and edge cases: `references/wiring-reference.md`. Authoritative Blueprint docs: **render-blueprints** skill.\n\n| Mechanism | Role |\n|-----------|------|\n| `value` | Hardcoded string (non-secret config only) |\n| `generateValue: true` | Platform-generated secret |\n| `sync: false` | Dashboard prompt on **initial** create only |\n| `fromDatabase` | Inject DB fields (`connectionString`, `host`, `port`, `user`, `password`, `database`) |\n| `fromService` | Key Value: `type: keyvalue` + properties; private/web: `host`, `hostport`, or `envVarKey` |\n| `fromGroup` | Link all vars from a named group |\n\n## Platform-Injected Variables\n\nRender sets **read-only** variables your app can read at runtime (and some at build). A concise list:\n\n| Variable | Typical meaning |\n|----------|-----------------|\n| `RENDER` | `\"true\"` when running on Render |\n| `RENDER_SERVICE_TYPE` | Service kind (e.g. web, worker) |\n| `RENDER_SERVICE_ID` | Service identifier |\n| `RENDER_SERVICE_NAME` | Human-readable service name |\n| `RENDER_INSTANCE_ID` | Current instance |\n| `RENDER_EXTERNAL_URL` | Public URL (when applicable) |\n| `RENDER_EXTERNAL_HOSTNAME` | Public hostname |\n| `RENDER_DISCOVERY_SERVICE` | Service discovery hostname (private network) |\n| `RENDER_GIT_COMMIT` | Deployed commit SHA |\n| `RENDER_GIT_BRANCH` | Branch for this deploy |\n| `PORT` | HTTP port to bind (**default `10000`**) |\n| `IS_PULL_REQUEST` | Preview deploy indicator |\n| `RENDER_CPU_COUNT` | vCPU count for the instance |\n| `RENDER_WEB_CONCURRENCY` | Suggested worker/process count hint |\n\nBuild vs runtime availability, language version env vars, and **WEB_CONCURRENCY** defaults: `references/platform-variables.md`.\n\n## Runtime-Specific Defaults\n\nRender and buildpacks may set defaults (verify in your service’s **Environment** tab):\n\n| Runtime | Notable defaults |\n|---------|------------------|\n| **Node.js** | `NODE_ENV=production` |\n| **Python** | `PYTHON_VERSION` (pinned by build); Gunicorn-oriented images often set `GUNICORN_CMD_ARGS` to bind **`0.0.0.0:10000`** |\n| **Ruby** | `RAILS_ENV=production`, `RAILS_LOG_TO_STDOUT=true` |\n| **Go** | `GO111MODULE=on` (legacy modules flag; still seen on older stacks) |\n| **Rust** | `ROCKET_PORT=10000` (Rocket convention) |\n\nAlways 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.\n\n## Common Issues\n\n1. **Everything is a string** — `DEBUG=false` is truthy in many parsers; use explicit comparison or typed config loaders.\n2. **`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`.\n3. **Undocumented `RENDER_*` variables** — Names and semantics may change; do not depend on undocumented injection for critical logic.\n4. **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.\n5. **Secret file paths** — Code must read **`/etc/secrets/<filename>`**; wrong paths or missing mounts usually show as file-not-found at runtime.\n\n## References\n\n- `references/wiring-reference.md` — Complete Blueprint `envVar` wiring, YAML examples, precedence, edge cases\n- `references/platform-variables.md` — Injected variables (build vs runtime), language versions, concurrency, reading vars from code\n\n## Related Skills\n\n- **render-blueprints** — Full Blueprint authoring, validation, multi-service layouts\n- **render-deploy** — First deploy, repo requirements, MCP vs YAML\n- **render-web-services** — Ports, health checks, scaling behavior tied to env-driven servers\n"
AFTER
"---\nname: render-env-vars\ndescription: >-\n Configures environment variables, secrets, and env groups on Render. Use when\n the user needs to set env vars, wire secrets between services, create env\n groups, use generateValue, set sync: false, or troubleshoot missing or\n incorrect environment variable values in Blueprints or the Dashboard.\nlicense: MIT\ncompatibility: Render Dashboard, CLI, or MCP tools\nmetadata:\n author: Render\n version: \"1.0.0\"\n category: configuration\n---\n\n# Environment Variables on Render\n\nBefore inspecting or changing environment variables, secrets, secret files, or environment groups, read `references/environment-variables.md` for the current documentation, source-of-truth, safety, and mutation workflow.\n\nBlueprint wiring examples and language-specific application notes live under `references/`.\n\n## When to Use This Skill\n\nUse this skill when users want to:\n\n- Add, change, or remove environment variables or secrets\n- Understand Dashboard vs Blueprint vs API/MCP flows\n- Use **environment groups** for shared configuration\n- Wire `fromDatabase`, `fromService`, `fromGroup`, `sync: false`, or `generateValue` in Blueprints\n- Debug missing vars, secret files, precedence, or platform-injected names\n\nFor full Blueprint authoring, pair with **render-blueprints**. For first-time deploys, **render-deploy**. For web service behavior and ports, **render-web-services**.\n\n## Blueprint Wiring (Summary)\n\nAfter reading `references/environment-variables.md`, use `references/wiring-reference.md` for task-specific `fromDatabase`, `fromService`, and `fromGroup` examples. Consult **render-blueprints** for the complete Blueprint workflow.\n\n## Platform-Injected Variables\n\nUse the current default-variable reference fetched through `references/environment-variables.md` instead of relying on a fixed catalog. Language-specific application notes remain in `references/platform-variables.md`.\n\n## Runtime-Specific Defaults\n\nAlways 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.\n\n- When diagnosing a port-binding failure, first establish whether the service uses a native runtime or Docker and inspect its actual start command; the applicable defaults differ.\n- For a web service, `PORT` defaults to **`10000`**. Prefer reading `$PORT` in the start command rather than hardcoding that number or setting `PORT` merely to match an arbitrary hardcoded port.\n- Native Python services currently receive `GUNICORN_CMD_ARGS` with a default bind to **`0.0.0.0:10000`**. A custom Gunicorn start command should bind to **`0.0.0.0:$PORT`** so the process and Render's health checks use the same port.\n\n## Common Issues\n\n`WEB_CONCURRENCY` defaults differ for some older and newer services. When debugging worker counts, compare service creation date and explicit overrides, then confirm current behavior using `references/environment-variables.md` and `references/platform-variables.md`.\n\n## References\n\n- `references/environment-variables.md` — Current configuration docs, secret handling, groups, platform variables, and mutation safety\n- `references/wiring-reference.md` — Blueprint cross-resource wiring examples and workspace edge cases\n- `references/platform-variables.md` — Concurrency, native-runtime versus Docker behavior, and application parsing notes\n\n## Related Skills\n\n- **render-blueprints** — Full Blueprint authoring, validation, multi-service layouts\n- **render-deploy** — First deploy, repo requirements, MCP vs YAML\n- **render-web-services** — Ports, health checks, scaling behavior tied to env-driven servers\n\n<!-- shared:documentation-retrieval -->\n## Current documentation retrieval\n\nWhenever this skill directs you to consult current Render documentation:\n\n1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as `curl`. Do not substitute web-search summaries for the document.\n2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.\n3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.\n4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.\n\nWhen a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.\n<!-- /shared:documentation-retrieval -->\n"
Full snapshot data
{
"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.",
"included_files": [
{
"relative_path": "references/environment-variables.md",
"size_in_bytes": 4653
},
{
"relative_path": "references/platform-variables.md",
"size_in_bytes": 1329
},
{
"relative_path": "references/wiring-reference.md",
"size_in_bytes": 4459
}
],
"name": "render-env-vars",
"skill_md_contents": "---\nname: render-env-vars\ndescription: >-\n Configures environment variables, secrets, and env groups on Render. Use when\n the user needs to set env vars, wire secrets between services, create env\n groups, use generateValue, set sync: false, or troubleshoot missing or\n incorrect environment variable values in Blueprints or the Dashboard.\nlicense: MIT\ncompatibility: Render Dashboard, CLI, or MCP tools\nmetadata:\n author: Render\n version: \"1.0.0\"\n category: configuration\n---\n\n# Environment Variables on Render\n\nBefore inspecting or changing environment variables, secrets, secret files, or environment groups, read `references/environment-variables.md` for the current documentation, source-of-truth, safety, and mutation workflow.\n\nBlueprint wiring examples and language-specific application notes live under `references/`.\n\n## When to Use This Skill\n\nUse this skill when users want to:\n\n- Add, change, or remove environment variables or secrets\n- Understand Dashboard vs Blueprint vs API/MCP flows\n- Use **environment groups** for shared configuration\n- Wire `fromDatabase`, `fromService`, `fromGroup`, `sync: false`, or `generateValue` in Blueprints\n- Debug missing vars, secret files, precedence, or platform-injected names\n\nFor full Blueprint authoring, pair with **render-blueprints**. For first-time deploys, **render-deploy**. For web service behavior and ports, **render-web-services**.\n\n## Blueprint Wiring (Summary)\n\nAfter reading `references/environment-variables.md`, use `references/wiring-reference.md` for task-specific `fromDatabase`, `fromService`, and `fromGroup` examples. Consult **render-blueprints** for the complete Blueprint workflow.\n\n## Platform-Injected Variables\n\nUse the current default-variable reference fetched through `references/environment-variables.md` instead of relying on a fixed catalog. Language-specific application notes remain in `references/platform-variables.md`.\n\n## Runtime-Specific Defaults\n\nAlways 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.\n\n- When diagnosing a port-binding failure, first establish whether the service uses a native runtime or Docker and inspect its actual start command; the applicable defaults differ.\n- For a web service, `PORT` defaults to **`10000`**. Prefer reading `$PORT` in the start command rather than hardcoding that number or setting `PORT` merely to match an arbitrary hardcoded port.\n- Native Python services currently receive `GUNICORN_CMD_ARGS` with a default bind to **`0.0.0.0:10000`**. A custom Gunicorn start command should bind to **`0.0.0.0:$PORT`** so the process and Render's health checks use the same port.\n\n## Common Issues\n\n`WEB_CONCURRENCY` defaults differ for some older and newer services. When debugging worker counts, compare service creation date and explicit overrides, then confirm current behavior using `references/environment-variables.md` and `references/platform-variables.md`.\n\n## References\n\n- `references/environment-variables.md` — Current configuration docs, secret handling, groups, platform variables, and mutation safety\n- `references/wiring-reference.md` — Blueprint cross-resource wiring examples and workspace edge cases\n- `references/platform-variables.md` — Concurrency, native-runtime versus Docker behavior, and application parsing notes\n\n## Related Skills\n\n- **render-blueprints** — Full Blueprint authoring, validation, multi-service layouts\n- **render-deploy** — First deploy, repo requirements, MCP vs YAML\n- **render-web-services** — Ports, health checks, scaling behavior tied to env-driven servers\n\n<!-- shared:documentation-retrieval -->\n## Current documentation retrieval\n\nWhenever this skill directs you to consult current Render documentation:\n\n1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as `curl`. Do not substitute web-search summaries for the document.\n2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.\n3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.\n4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.\n\nWhen a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.\n<!-- /shared:documentation-retrieval -->\n"
}SHA-256 of public snapshot: f8358d3f46940bd494a80eb55cb95f73ea35a354f3862d9df3864ad82dc49839