--- name: render description: Deploy and operate apps on Render (Blueprint + one-click Dashboard deeplink, same flow as Codex render-deploy). Use when the user wants to deploy, host, or publish an app; create or edit render.yaml; add web, static, workers, cron, Postgres, or Key Value; get the Blueprint deeplink to deploy; trigger or verify deploys via API when RENDER_API_KEY is set; connect Render MCP via mcporter for direct service creation; or configure env vars, health checks, scaling, previews, and projects. metadata: { "openclaw": { "emoji": "☁️", "homepage": "https://render.com/docs", "version": "1.0.0" } } ---

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

| type | Purpose | |------------|--------| | web | Public HTTP app or static site (use runtime: static for static) | | pserv | Private service (internal hostname only, no public URL) | | worker | Background worker (runs continuously, e.g. job queues) | | cron | Scheduled job (cron expression; runs and exits) | | keyvalue | Render Key Value instance (Redis/Valkey-compatible; defined in services) |

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: 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.

...