Render Skill

Deploy apps to Render from OpenClaw. Prefer a Blueprint when the app is more than one service. Prefer native Render MCP for a single web or static site once MCP is connected. Workflows are a separate service type and do not belong in render.yaml yet.

Field names and CLI verbs change. Before emitting YAML or API bodies, fetch Blueprint spec and MCP docs. Official Cursor/Codex skills: render-oss/skills.

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
• Add web, static, private, worker, cron, or Workflow services; Postgres; or Key Value
• Connect Render MCP from OpenClaw, or fall back to mcporter / REST
• Validate a Blueprint or get a Dashboard deeplink

Method Selection

Use this rule unless the user names a method.

Direct create (MCP, else REST) when all of these are true:

• One web service or one static site
• No worker, cron, private service, or Workflow
• No Postgres or Key Value at create time
• Simple env vars only (no env groups)
• MCP is connected, or RENDER_API_KEY is set and the user accepts REST

If this path fits and MCP is not connected, set up MCP first (references/mcp-integration.md). Do not invent a Blueprint unless the user prefers IaC.

Blueprint + push + deeplink when any of these are true:

• Multiple services
• Postgres, Key Value, worker, cron, or private service
• The user wants IaC in the repo
• No MCP and no API key

Dashboard or Render CLI for Workflows. Blueprints cannot create or manage them. See references/workflows.md.

Live actions (required)

Creating services, triggering deploys (API, MCP trigger_deploy, or a deploy hook), replacing env vars, restarting, or destroying resources changes a live Render workspace and can incur cost. Blueprint Apply in the Dashboard is the user’s click; do not also fire API/MCP/hook deploys unless they asked for that too.

Before any mutating call, state in chat and wait for an explicit yes for this action:

• Target workspace (not “whatever is selected”)
• Service or Blueprint name
• Environment: production vs preview vs new
• Plan / that the resource can be billable and persistent
• What will happen (create, redeploy, env replace, destroy)

Do not treat a general “deploy this app” from an earlier turn as consent to redeploy now.

Read-only list/get/logs/metrics are fine once credentials exist.

Credentials: never print RENDER_API_KEY, deploy-hook URLs with secrets, or Authorization headers. Check presence, not value:

[ -n "$RENDER_API_KEY" ] && echo "RENDER_API_KEY is set" || echo "RENDER_API_KEY is not set"
openclaw mcp doctor render --probe

Do not echo headers, curl -v, or MCP probe output that might contain the token. Prefer a test workspace for first-time MCP/REST creates.

Happy Path (New Users)

Happy Path (New Users)

1. Git repo (GitHub, GitLab, Bitbucket, or Cursor Origin) vs prebuilt Docker image. Image-backed services are Dashboard/API only; MCP cannot create them. A Blueprint with runtime: image still needs render.yaml in a Git repo.
2. Whether Render should provision the database, workers, cron, or Workflow the app actually needs.

Then follow the matching method below.

Prerequisites

1. Git remote for Blueprint and MCP Git deploys: git remote -v. If none, ask the user to create a repo, add origin, and push. Cursor Origin is in beta; workspace admins connect it in Render Account Settings.
2. Render CLI (optional) for render blueprints validate and render workflows init. Install: brew install render or the Render CLI.
3. API key (optional) for MCP, REST, verify, and re-deploy: API Keys. Set RENDER_API_KEY. Do not commit it.

Security Notes

• Never put secret values in render.yaml, chat, or logs. Record env names only; use sync: false and have the user fill values in the Dashboard.
• Validate before push: render blueprints validate render.yaml or the Validate Blueprint API.
• Do not git commit / git push unless the user asked to deploy or confirmed the Blueprint file.
• New Key Value instances: ipAllowList: [] unless the user asked for public access.
• Do not set continuous auto-deploy unless the user wants every push to go live.
• Sanitize user-supplied names before writing YAML.

References

• references/codebase-analysis.md
• references/blueprint-spec.md
• references/workflows.md
• references/mcp-integration.md
• references/rest-api-deployment.md
• references/post-deploy-checks.md
• references/troubleshooting-basics.md
• assets/ (node-express, python-web, static-site, web-with-postgres)

---

Method 1: Blueprint + deeplink

Step 1: Analyze and write render.yaml

Use references/codebase-analysis.md. Put render.yaml at the repo root. sync: false for secrets. Validate before asking for a push.

render blueprints validate render.yaml

Step 2: Commit and push

Render reads the Blueprint from the Git remote.

git add render.yaml
git commit -m "Add Render deployment configuration"
git push origin main

Stop if there is no remote.

Step 3: Dashboard deeplink

git remote get-url origin

Convert SSH to HTTPS and drop .git:

SSH	HTTPS
git@github.com:user/repo.git	https://github.com/user/repo
git@gitlab.com:user/repo.git	https://gitlab.com/user/repo
git@bitbucket.org:user/repo.git	https://bitbucket.org/user/repo

Cursor Origin remotes: use the HTTPS URL Render’s Git-provider docs show for that host. Do not guess a hostname.

Deeplink:

https://dashboard.render.com/blueprint/new?repo=<REPO_HTTPS_URL>

User checklist: confirm render.yaml is on the default branch, click the link, finish Git OAuth, fill sync: false vars, Apply.

Step 4: Verify

If MCP is connected, use list_services / list_deploys / list_logs (see references/mcp-integration.md). Else REST (references/post-deploy-checks.md). Expect latest deploy status: "live".

Re-deploy

Only after the Live actions checklist. A deploy hook URL is a production trigger: same confirmation as MCP/REST.

• Push to the linked branch when the user already enabled auto-deploy and wants this commit live.
• MCP: trigger_deploy (after yes).
• REST: POST https://api.render.com/v1/services/{serviceId}/deploys with Authorization: Bearer $RENDER_API_KEY. Optional body: { "clearCache": "do_not_clear" } or "clear".
• Deploy hook: curl -X POST "$RENDER_DEPLOY_HOOK_URL" only if the user provided the hook and confirmed this redeploy. Do not log the URL.

---

Method 2: Direct create (MCP or REST)

Single web or static site only. Confirm the repo is pushed. Complete Live actions (workspace, plan/cost, explicit yes). Then references/mcp-integration.md (preferred) or references/rest-api-deployment.md.

MCP cannot create: workers, private services, Workflows, image-backed services. Use Blueprint or Dashboard for those.

Set the workspace first (list_workspaces / get_selected_workspace, or ask the user to pick one). Do not create in the first workspace returned without confirmation.

---

Blueprint snippets

File: render.yaml at repo root (Render can use another path at setup; default is root).

Root keys: services, databases, envVarGroups, projects, ungrouped, previews. Not Workflows.

Service types in YAML: web, pserv, worker, cron, keyvalue. Static site: type: web + runtime: static. Private services: pserv, not private.

Runtimes: node, python, elixir, go, ruby, rust, docker, image, static. Prefer runtime; env is deprecated.

Web

services:
  - type: web
    name: my-app
    runtime: node
    plan: free
    buildCommand: npm ci
    startCommand: npm start
    healthCheckPath: /health
    envVars:
      - key: NODE_ENV
        value: production

Python: runtime: python, buildCommand: pip install -r requirements.txt, startCommand: uvicorn app.main:app --host 0.0.0.0 --port $PORT. Bind HTTP to 0.0.0.0:$PORT. Set PYTHON_VERSION / NODE_VERSION when the repo pins them.

Static site

No plan field.

- type: web
  name: my-blog
  runtime: static
  buildCommand: npm ci && npm run build
  staticPublishPath: ./dist

Optional: headers, routes.

Env vars

• Literal: key + value (never secrets).
• Postgres: fromDatabase.name + fromDatabase.property (connectionString).
• Key Value / other service: fromService.type + fromService.name + fromService.property (or fromService.envVarKey).
• Secret: sync: false (service-level only; not inside env groups).
• Generated: generateValue: true.
• Shared: fromGroup: <envVarGroups[].name>.

Env groups cannot use fromDatabase, fromService, or sync: false.

Postgres

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

Plans: free, basic-256mb, basic-1gb, basic-4gb, pro-*, accelerated-*. Free instances expire after 30 days. Confirm the default major version on the spec before pinning. Optional: diskSizeGB, ipAllowList, readReplicas, highAvailability.enabled, storageAutoscalingEnabled, connectionPool.

Key Value

ipAllowList is required. Default to private:

services:
  - type: keyvalue
    name: my-cache
    ipAllowList: []
    plan: free
    maxmemoryPolicy: allkeys-lru

Public access only if requested: source: 0.0.0.0/0. Reference with fromService.type: keyvalue, property: connectionString. Paid instances persist; see spec for persistenceMode.

Cron

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

buildCommand is required. Free plan is not available for cron, worker, or pserv.

Env groups

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, region, scaling, disks, Docker

• Web: healthCheckPath for zero-downtime deploys.
• region: oregon (default), ohio, virginia, frankfurt, singapore. Set at create.
• preDeployCommand after build, before start (migrations).
• Manual scale: numInstances. Autoscaling: scaling.minInstances / maxInstances / CPU or memory targets. Not with persistent disks.
• Disk: disk.name, disk.mountPath, disk.sizeGB on web, pserv, worker.
• Monorepo: rootDir, buildFilter.paths / ignoredPaths.
• Docker: runtime: docker or runtime: image. dockerCommand instead of startCommand when needed.

Previews and projects

• previews.generation: off | manual | automatic. Optional previews.expireAfterDays.
• projects with environments for staging/production. ungrouped for leftovers.

Service plans

free | starter | standard | pro | pro plus (web/pserv/worker also pro max, pro ultra). Omit to keep an existing plan. Default for new paid-capable services is starter if you skip plan. Free is not available for pserv, worker, cron.

Dashboard: https://dashboard.render.com. New Key Value: https://dashboard.render.com/new/redis.

---

Checklist

1. Choose MCP/REST vs Blueprint vs Workflow CLI using the heuristic above.
2. Write render.yaml when using Blueprint: runtime, Key Value as type: keyvalue, ipAllowList: [] unless public access was requested.
3. sync: false for secrets at service level only.
4. Validate, commit, push, then the Blueprint deeplink. Or create via MCP after workspace selection.
5. Verify deploy live. Fix from references/troubleshooting-basics.md before a second deploy.

Rules

• Prefer Blueprint for the full app; MCP for one web or static site; Dashboard/CLI for Workflows.
• Never commit API keys or secrets.
• Use fromService with the real type (keyvalue, pserv).
• Confirm live docs when a field is missing from this file rather than guessing.