Render

Render Skill

Deploy and manage applications on Render using Blueprints (render.yaml), the Dashboard, or the API. This skill mirrors the Codex render-deploy flow: analyze codebase → generate/validate Blueprint → commit & push → one-click Dashboard deeplink → optional API/mcporter verify or re-deploy.

When to Use This Skill

Activate when the user wants to:

• Deploy, host, or publish an application on Render
• Create or edit a render.yaml Blueprint (new or existing repo)
• Add web, static site, private, worker, or cron services; Postgres; or Key Value
• Configure env vars, health checks, scaling, disks, or regions
• Set up preview environments or projects
• Validate a Blueprint or get Dashboard/API links

Deployment Method Selection

1. If RENDER_API_KEY is set → Prefer REST API or MCP (fastest; no user click). Use references/rest-api-deployment.md for request bodies, or mcporter if configured (see references/mcp-integration.md).
2. If no API key → Use Blueprint + deeplink (user commits, pushes, then clicks the deeplink to deploy).

Check for API key:

[ -n "$RENDER_API_KEY" ] && echo "RENDER_API_KEY is set" || echo "RENDER_API_KEY is not set"

Happy Path (New Users)

Before deep analysis, use this short sequence to reduce friction:

1. Ask whether they want to deploy from a Git repo (required for Blueprint and deeplink) or only get guidance. If no Git remote, they must create/push one first.
2. Ask whether the app needs a database, workers, cron, or other services so you can choose the right Blueprint shape.

Then follow Deploy to Render below (Blueprint → push → deeplink → verify).

Prerequisites Check

1. Git remote – Required for Blueprint deploy. Run git remote -v; if none, ask the user to create a repo on GitHub/GitLab/Bitbucket, add origin, and push.
2. Render CLI (optional) – For local validation: render blueprints validate render.yaml. Install: brew install render or Render CLI.
3. API key (optional) – For verifying deploys or triggering re-deploys: Dashboard → API Keys. Set RENDER_API_KEY in the environment.

Security Notes

• Never commit secrets to render.yaml — always use sync: false for API keys, passwords, and tokens; the user fills them in the Dashboard.
• Validate before suggesting deployment — run render blueprints validate render.yaml or use the Validate Blueprint API so invalid YAML is never pushed.
• Validate user-provided values — when writing env vars or service names from user input into YAML, sanitize or quote as needed to avoid injection.

References

• references/codebase-analysis.md (detect runtime, build/start commands, env vars)
• references/blueprint-spec.md (root keys, service types, env vars, validation)
• references/rest-api-deployment.md (direct API create service: ownerId, request bodies, type mapping)
• references/mcp-integration.md (Render MCP tools, mcporter usage, supported runtimes/plans/regions)
• references/post-deploy-checks.md (verify deploy status and health via API)
• references/troubleshooting-basics.md (build/startup/runtime failures)
• assets/ (example Blueprints: node-express.yaml, python-web.yaml, static-site.yaml, web-with-postgres.yaml)

Blueprint Basics

• File: render.yaml at the root of the Git repository (required).
• Root-level keys (official spec): services, databases, envVarGroups, projects, ungrouped, previews.generation, previews.expireAfterDays.
• Spec: Blueprint YAML Reference. JSON Schema for IDE validation: https://render.com/schema/render.yaml.json (e.g. YAML extension by Red Hat in VS Code/Cursor).

Validation: render blueprints validate render.yaml (Render CLI v2.7.0+), or the Validate Blueprint API endpoint.

Service Types

Note: Private services use pserv, not private. Key Value is a service with type: keyvalue; do not use a separate root key for it in new Blueprints (some older blueprints use keyValueStores and fromKeyValueStore—prefer the official format).

Runtimes

Use runtime (preferred; env is deprecated): node, python, elixir, go, ruby, rust, docker, image, static. For static sites: type: web, runtime: static, and staticPublishPath (e.g. ./build or ./dist) required.

Minimal Web Service

services:
  - type: web
    name: my-app
    runtime: node
    buildCommand: npm install
    startCommand: npm start
    envVars:
      - key: NODE_ENV
        value: production

Python example: runtime: python, buildCommand: pip install -r requirements.txt, startCommand: uvicorn app.main:app --host 0.0.0.0 --port $PORT (or gunicorn). Set PYTHON_VERSION / NODE_VERSION in envVars when needed.

Static Site

- type: web
  name: my-blog
  runtime: static
  buildCommand: yarn build
  staticPublishPath: ./build

Optional: headers, routes (redirects/rewrites). See Static Sites.

Environment Variables

• Literal: key + value (never hardcode secrets).
• From Postgres: fromDatabase.name + fromDatabase.property (e.g. connectionString).
• From Key Value or other service: fromService.type + fromService.name + fromService.property (e.g. connectionString, host, port, hostport) or fromService.envVarKey for another service’s env var.
• Secret / user-set: sync: false (user is prompted in Dashboard on first create; add new secrets manually later). Cannot be used inside env var groups.
• Generated: generateValue: true (base64 256-bit value).
• Shared: fromGroup: <envVarGroups[].name> to attach an env var group.

Env groups cannot reference other services (no fromDatabase/fromService in groups) and cannot use sync: false. Put secrets and DB/KV references in service-level envVars, or reference a group and add service-specific vars alongside.

Databases (Render Postgres)

databases:
  - name: my-db
    plan: basic-256mb
    databaseName: my_app
    user: my_user
    region: oregon
    postgresMajorVersion: "18"

Plans (current): free, basic-256mb, basic-1gb, basic-4gb, pro-*, accelerated-*. Legacy: starter, standard, pro, pro plus (no new DBs on legacy). Optional: diskSizeGB, ipAllowList, readReplicas, highAvailability.enabled. Reference in services: fromDatabase.name, property: connectionString.

Key Value (Redis/Valkey)

Key Value instances are services with type: keyvalue (or deprecated redis). ipAllowList is required: use [] for internal-only, or - source: 0.0.0.0/0 to allow external.

services:
  - type: keyvalue
    name: my-cache
    ipAllowList:
      - source: 0.0.0.0/0
        description: everywhere
    plan: free
    maxmemoryPolicy: allkeys-lru

Reference in another service: fromService.type: keyvalue, fromService.name: my-cache, property: connectionString. Policies: allkeys-lru (caching), noeviction (job queues), etc. See Key Value.

Note: Some repos use root-level keyValueStores and fromKeyValueStore; the official spec uses services + fromService. Prefer the official form for new Blueprints.

Cron Jobs

- type: cron
  name: my-cron
  runtime: python
  schedule: "0 * * * *"
  buildCommand: "true"
  startCommand: python scripts/daily.py
  envVars: []

schedule is a cron expression (minute hour day month weekday). buildCommand is required (use "true" if no build). Free plan not available for cron/worker/pserv.

Env Var Groups

Share vars across services. No fromDatabase/fromService/sync: false inside groups—only literal values or generateValue: true.

envVarGroups:
  - name: app-env
    envVars:
      - key: CONCURRENCY
        value: "2"
      - key: APP_SECRET
        generateValue: true

services:
  - type: web
    name: api
    envVars:
      - fromGroup: app-env
      - key: DATABASE_URL
        fromDatabase:
          name: my-db
          property: connectionString

Health Check, Region, Pre-deploy

• Web only: healthCheckPath: /health for zero-downtime deploys.
• Region: region: oregon (default), ohio, virginia, frankfurt, singapore (set at create; cannot change later).
• Pre-deploy: preDeployCommand runs after build, before start (e.g. migrations).

Scaling

• Manual: numInstances: 2.
• Autoscaling (Professional workspace): scaling.minInstances, scaling.maxInstances, scaling.targetCPUPercent or scaling.targetMemoryPercent. Not available with persistent disks.

Disks, Monorepos, Docker

• Persistent disk: disk.name, disk.mountPath, disk.sizeGB (web, pserv, worker).
• Monorepo: rootDir, buildFilter.paths / buildFilter.ignoredPaths, dockerfilePath / dockerContext.
• Docker: runtime: docker (build from Dockerfile) or runtime: image (pull from registry). Use dockerCommand instead of startCommand when needed.

Preview Environments & Projects

• Preview environments: Root-level previews.generation: off | manual | automatic, optional previews.expireAfterDays. Per-service previews.generation, previews.numInstances, previews.plan.
• Projects/environments: Root-level projects with environments (each lists services, databases, envVarGroups). Use for staging/production. Optional ungrouped for resources not in any environment.

Common Deployment Patterns

Full stack (web + Postgres + Key Value)

Web service with fromDatabase for Postgres and fromService for Key Value. Add one databases entry and one type: keyvalue service; reference both from the web service envVars. See assets/web-with-postgres.yaml for Postgres; add a keyvalue service and fromService for Redis URL.

Microservices (API + worker + cron)

Multiple services in one Blueprint: type: web for the API, type: worker for a background processor, type: cron for scheduled jobs. Share envVarGroups or repeat env vars; use fromDatabase/fromService for shared DB/Redis. All use the same branch and buildCommand/startCommand as appropriate per runtime.

Preview environments for PRs

Set root-level previews.generation: automatic (or manual). Optionally previews.expireAfterDays: 7. Each PR gets a preview URL; per-service overrides with previews.generation, previews.numInstances, or previews.plan when needed.

Plans (Services)

plan: free | starter | standard | pro | pro plus (and for web/pserv/worker: pro max, pro ultra). Omit to keep existing or default to starter for new. Free not available for pserv, worker, cron.

Dashboard & API

• Dashboard: https://dashboard.render.com — New → Blueprint, connect repo, select render.yaml.
• Key Value: https://dashboard.render.com/new/redis