Back to Skills
    🦞

    deploy-on-render

    Deploy and operate apps on Render

    By @ojusave
    View on GitHub
    SKILL.md
    ---
    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)