← Back to Skills
DevOps

deploy-on-render

ojusave By ojusave 👁 51 views ▲ 0 votes

Deploy and operate apps on Render

GitHub
---
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

Comments

Sign in to leave a comment

Loading comments...