From render
Configures environment variables, secrets, and env groups on Render. Helps set vars, wire secrets between services, create groups, use generateValue/sync:false, or troubleshoot issues in Blueprints/Dashboard.
npx claudepluginhub render-oss/skills --plugin renderThis skill uses the workspace's default tool permissions.
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.
Authors and validates render.yaml Blueprints for Render infrastructure. Wires services via fromDatabase/fromService/fromGroup, configures projects/environments/previews, validates schema, fixes immutable field errors.
Deploys Git-backed apps to Render by analyzing codebases, generating render.yaml blueprints, creating services via MCP, and providing dashboard deeplinks. Use for hosting on Render.
Manages env vars with better-env: typed config schemas, Vercel sync from local files, prebuild validation. Useful for type-safe envs in Vercel deploys.
Share bugs, ideas, or general feedback.
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:
.env, save/redeploy optionsenvVars (and related keys) in render.yamlupdate_environment_variables on a serviceDeep wiring patterns, full platform variable tables, and language-specific notes live under references/.
Use this skill when users want to:
fromDatabase, fromService, fromGroup, sync: false, or generateValue in BlueprintsFor full Blueprint authoring, pair with render-blueprints. For first-time deploys, render-deploy. For web service behavior and ports, render-web-services.
.env-style file.Use Dashboard edits when iterating quickly or when the repo should not carry certain values.
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.
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.
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.render.yaml as plain value: entries. Prefer Dashboard, secret manager integration, generateValue, or sync: false with Dashboard entry./etc/secrets/<filename>./etc/secrets/ on the running instance.Environment groups are named collections of variables linked to multiple services.
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 |
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.
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.
DEBUG=false is truthy in many parsers; use explicit comparison or typed config loaders.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.RENDER_* variables — Names and semantics may change; do not depend on undocumented injection for critical logic.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./etc/secrets/<filename>; wrong paths or missing mounts usually show as file-not-found at runtime.references/wiring-reference.md — Complete Blueprint envVar wiring, YAML examples, precedence, edge casesreferences/platform-variables.md — Injected variables (build vs runtime), language versions, concurrency, reading vars from code