DevOps
deploy-on-render
Deploy and operate apps on Render
---
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:
```bash
[ -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](https://github.com/render-oss/cli).
3. **API key (optional)** – For verifying deploys or triggering re-deploys: [Dashboard → API Keys](https://dashboard.render.com/u/*/settings#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](https://render.com/docs/blueprint-spec). 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](https://api-docs.render.com/reference/validate-blueprint) 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
```yaml
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
```yaml
- type: web
name: my-blog
runtime: static
buildCommand: yarn build
staticPublishPath: ./build
```
Optional: `headers`, `routes` (redirects/rewrites). See [Static Sites](https://render.com/docs/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)
```yaml
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.
```yaml
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](https://render.com/docs/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
```yaml
- 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`.
```yaml
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:
... (truncated)
devops
By
Comments
Sign in to leave a comment