Update to Render

{
  "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.",
  "included_files": [
    {
      "relative_path": "references/platform-variables.md",
      "size_in_bytes": 5014
    },
    {
      "relative_path": "references/wiring-reference.md",
      "size_in_bytes": 6628
    }
  ],
  "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\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"
}