render

name	render
title	Render
category	Hosting & Deploy
description	Use to deploy web services, workers, cron jobs, and databases — declaratively via a render.yaml Blueprint or from the dashboard.
tags	["hosting","deploy","paas","blueprint","cron","databases"]
official_docs	https://render.com/docs
sources	["https://render.com/docs/blueprint-spec"]
last_verified	2026-08-10T00:00:00.000Z

Render — Skillship

A PaaS for web services, background workers, cron jobs, static sites, and managed Postgres/Key-Value. Define your whole stack as code in render.yaml (a "Blueprint") for reproducible deploys.

🧭 When to use this skill

• Use when: you need always-on web services, workers, or scheduled cron jobs with managed Postgres.
• Use when: you want infrastructure-as-code via a single render.yaml.
• Don't use for: edge functions (use Cloudflare) or purely static/frontends where Vercel/Netlify fit better.

⚡ Quickstart

1. Add a render.yaml Blueprint (repo root)

services:
  - type: web
    name: my-api
    runtime: node
    plan: starter
    buildCommand: npm install && npm run build
    startCommand: npm start
    healthCheckPath: /healthz
    autoDeployTrigger: commit
    preDeployCommand: npm run migrate     # runs after build, before start — great for DB migrations
    envVars:
      - key: NODE_ENV
        value: production
      - key: STRIPE_SECRET_KEY
        sync: false                       # prompts for the secret in the dashboard on creation
      - key: SESSION_SECRET
        generateValue: true               # Render generates a random 256-bit value
      - key: DATABASE_URL
        fromDatabase:
          name: my-db
           


    
     
     

2. Deploy

• Dashboard → New → Blueprint → connect the repo containing render.yaml. Render creates every service/DB.

🧩 Common recipes

Recipe: Build from a Dockerfile

services:
  - type: web
    name: web
    runtime: docker
    dockerfilePath: ./Dockerfile
    healthCheckPath: /

Recipe: A cron job

services:
  - type: cron
    name: nightly
    runtime: node
    schedule: "0 3 * * *"
    buildCommand: npm install
    startCommand: node scripts/nightly.js

Recipe: Background worker + managed Key-Value (Redis-compatible)

services:
  - type: worker
    name: queue
    runtime: node
    startCommand: node worker.js
    envVars:
      - key: REDIS_URL
        fromService: { type: keyvalue, name: cache, property: connectionString }
  - type: keyvalue
    name: cache
    ipAllowList: []      # internal connections only

Recipe: Validate the Blueprint before pushing

render blueprints validate render.yaml

🚀 Ship to production

• Secrets use sync: false (prompted) or env groups — never hardcoded values in render.yaml.
• healthCheckPath set so Render can do zero-downtime deploys.
• DB migrations run via preDeployCommand (not on every instance start).
• autoDeployTrigger set intentionally (commit, checksPass, or off).
• Region and plan chosen per service; ipAllowList set for Key-Value (required) and sensitive DBs.
• Persistent disks noted: they disable zero-downtime deploys for that service.

🔐 Security & secrets

• Secret env vars: sync: false (dashboard-prompted) or generateValue: true (random). Don't commit real secrets.
• Reference DB/service properties with fromDatabase/fromService rather than copying credentials.
• Lock down datastore access with ipAllowList (empty list = internal-only).

🐛 Common errors & fixes

Symptom	Likely cause	Fix
Blueprint sync fails referencing a service	Referenced service not in workspace	Ensure it exists or is defined in the Blueprint
Deploys aren't zero-downtime	No health check / persistent disk attached	Set healthCheckPath; note disks disable it
Migrations run multiple times	Put in startCommand	Move to preDeployCommand
Secret ignored on update	sync: false only prompts on creation	Add/edit the value manually in the dashboard
Key-Value won't create	Missing required ipAllowList	Provide ipAllowList (use [] for internal-only)

📚 Sources

• https://render.com/docs/blueprint-spec