| name | render |
| description | Deploy web services, static sites, and workers to Render using the Render CLI |
| metadata | {"version":"2.1.0","author":"OpenOps Team"} |
| risk_level | write |
| platforms | ["render"] |
| requires | {"cli":"render","install":"npm install -g @render-oss/cli"} |
Render Deployment Skill
When to Use
Use this skill when:
- User wants to deploy web services, APIs, or static sites
- User needs background workers or cron jobs
- User mentions Render as the target platform
- User wants simple, managed infrastructure with free tier
- User needs PostgreSQL or Redis databases
Prerequisites
1. CLI Installation
Verify installation:
render --version
To install Render CLI
npm install -g @render-oss/cli
Or using Homebrew (macOS):
brew install render
2. Authentication
Render CLI uses an API key for non-interactive authentication or browser for interactive mode.
To check login status, run
render whoami
If user has not authenticated (which raise an error of Error: failed to create client: run render login to authenticate), run this command in interactive mode:
render login
Agent workflow (preferred): verify → configure via CLI → verify
render services list
If not authenticated, the CLI typically returns:
Error: No API key configured. Set RENDER_API_KEY or run 'render config set api-key'
Resolve authentication as an agent:
- Ask the user to provide a Render API key (they can create one at
https://dashboard.render.com/u/settings#api-keys).
- Configure the key via CLI (non-interactive):
render config set api-key <api_key>
- Verify authentication:
render services list
Expected output (authenticated):
┌─────────────────────────────────────────────────────────────────────────┐
│ Services │
├──────────────────┬────────────────┬──────────┬──────────────────────────┤
│ Name │ Type │ Status │ URL │
├──────────────────┼────────────────┼──────────┼──────────────────────────┤
│ my-api │ Web Service │ Live │ https://my-api.onrender │
└──────────────────┴────────────────┴──────────┴──────────────────────────┘
Alternative (CI / env-based): RENDER_API_KEY
If the user provides the key as an environment variable (e.g. in CI), ensure it is set:
export RENDER_API_KEY=<api_key>
Then verify with:
render services list
Supported Service Types
| Type | Description | Use Case |
|---|
web_service | HTTP server with public URL | APIs, web apps |
static_site | Static file hosting | SPAs, documentation |
background_worker | Non-HTTP service | Job processors, bots |
private_service | Internal service | Microservices |
Supported Frameworks
Render auto-detects and builds:
| Framework | Language | Build Command | Start Command |
|---|
| Next.js | Node.js | npm run build | npm start |
| Express | Node.js | npm install | node index.js |
| FastAPI | Python | pip install -r requirements.txt | uvicorn main:app |
| Django | Python | pip install -r requirements.txt | gunicorn app.wsgi |
| Flask | Python | pip install -r requirements.txt | gunicorn app:app |
| Go | Go | go build -o app | ./app |
| Rust | Rust | cargo build --release | ./target/release/app |
Render Concepts
Services
Deployable units in Render. Common types:
- Web service: HTTP server with a public URL
- Static site: static hosting for built assets
- Background worker: process without inbound HTTP
- Private service: internal-only service (no public ingress)
Deploys
Each deploy is a build + release cycle for a service. You can trigger deploys via the CLI and check status/history.
Blueprints (render.yaml)
Infrastructure-as-code definition for services/databases. The CLI can launch a blueprint to create resources.
CLI Commands
List Services
render services list
Expected output:
┌─────────────────────────────────────────────────────────────────────────┐
│ Services │
├──────────────────┬────────────────┬──────────┬──────────────────────────┤
│ Name │ Type │ Status │ URL │
├──────────────────┼────────────────┼──────────┼──────────────────────────┤
│ my-api │ Web Service │ Live │ https://my-api.onrender │
│ my-worker │ Background │ Live │ - │
│ my-site │ Static Site │ Live │ https://my-site.onrender │
└──────────────────┴────────────────┴──────────┴──────────────────────────┘
Get Service Details
render services show --name <service-name>
Or by ID:
render services show --id srv-xxxxxxxxxxxxx
Trigger Deploy
For an existing service, trigger a new deployment:
render deploys create --service-id srv-xxxxxxxxxxxxx
Or by service name:
render deploys create --service-name my-api
Expected output:
Deployment triggered successfully.
Deployment ID: dep-xxxxxxxxxxxxx
Status: build_in_progress
List Deployments
render deploys list --service-id srv-xxxxxxxxxxxxx
Expected output:
┌─────────────────────────────────────────────────────────────────────────┐
│ Deployments for my-api │
├──────────────────┬────────────────┬──────────────────────────────────────┤
│ ID │ Status │ Created │
├──────────────────┼────────────────┼──────────────────────────────────────┤
│ dep-abc123 │ live │ 2024-01-15 10:30:00 │
│ dep-xyz789 │ deactivated │ 2024-01-14 09:15:00 │
└──────────────────┴────────────────┴──────────────────────────────────────┘
View Logs
render logs --service-id srv-xxxxxxxxxxxxx
With follow:
render logs --service-id srv-xxxxxxxxxxxxx --tail
Set Environment Variables
render env set --service-id srv-xxxxxxxxxxxxx KEY=value
List Environment Variables
render env list --service-id srv-xxxxxxxxxxxxx
Create Service via Blueprint
Using a render.yaml file:
render blueprint launch
This creates all services defined in render.yaml.
Deployment Steps
0. Check CLI Installation
render --version
If CLI not installed:
- Ask user for permission to install
- Execute:
npm install -g @render-oss/cli (or brew install render on macOS)
- Verify installation with
render --version
1. Check Authentication
render services list
If error about API key:
- Inform user that Render requires an API key from the dashboard
- Open or direct to:
https://dashboard.render.com/u/settings#api-keys
- Once user provides the API key, execute:
render config set api-key <key>
- Verify with
render services list
2. List existing services and get user selection
As an agent, prefer an explicit list → user chooses → act workflow to avoid guessing the target service.
render services list
3. Deploy
For existing service:
render deploys create --service-name <name>
For new service, guide user to:
- Create
render.yaml blueprint
- Run
render blueprint launch
Or create via dashboard and then trigger deploy via CLI.
4. Verify Deployment
render deploys list --service-name <name>
Check latest deployment status is live.
Instance Types and Pricing
| Type | RAM | CPU | Use Case |
|---|
| free | 512 MB | Shared | Development, testing |
| starter | 512 MB | 0.5 | Low-traffic apps |
| standard | 2 GB | 1 | Production apps |
| pro | 4 GB | 2 | High-traffic apps |
| pro_plus | 8 GB | 4 | Resource-intensive |
Free tier limitations:
- Spins down after 15 min inactivity
- 750 hours/month
- No custom domains
Error Handling
| Error Output | Cause | Action |
|---|
No API key configured | Not authenticated | Guide user to create API key, then execute render config set api-key <key> |
Service not found | Wrong name/ID | Execute render services list to find correct service |
Deployment failed | Build error | Execute render logs to diagnose, then fix |
Rate limited | Too many requests | Wait briefly, then retry |
command not found: render | CLI not installed | Ask permission, then install CLI |
Output Parsing
Service List
Parse table output for:
- Service name (first column)
- Service type (second column)
- Status:
Live, Deploying, Failed
Deployment Status
Look for:
Status: live - deployment successful
Status: build_in_progress - still building
Status: failed - deployment failed
Logs
Check for:
Error: or error: lines
- Stack traces
- Exit codes
render.yaml Blueprint
For Infrastructure as Code:
services:
- type: web
name: my-api
env: python
buildCommand: pip install -r requirements.txt
startCommand: uvicorn main:app --host 0.0.0.0 --port $PORT
envVars:
- key: DATABASE_URL
fromDatabase:
name: my-db
property: connectionString
databases:
- name: my-db
plan: free
Health Checks
Render performs health checks on web services:
- Default path:
/
- Custom path: Set in dashboard or render.yaml
- Timeout: 30 seconds
- Unhealthy threshold: 3 consecutive failures
Implement a /health endpoint:
@app.get("/health")
def health():
return {"status": "healthy"}
Example Conversations
Deploy web service (CLI not installed):
User: "Deploy my Express API to Render"
Agent: [executes: render --version]
Agent: "Render CLI is not installed. May I install it for you?"
User: "Yes"
Agent: [executes: npm install -g @render-oss/cli]
Agent: "CLI installed. Checking authentication..."
Agent: [executes: render services list]
Agent: "Render requires an API key. Please create one at:
`https://dashboard.render.com/u/settings#api-keys`
Then share the key with me."
User: "Here it is: rnd_xxxxxxxxxxxxx"
Agent: [executes: render config set api-key rnd_xxxxxxxxxxxxx]
Agent: "API key configured. Checking services..."
Agent: [executes: render services list]
Agent: "Found existing service 'my-api'. Triggering deployment..."
Agent: [executes: render deploys create --service-name my-api]
Agent: "Deployment triggered! Your API will be live at https://my-api.onrender.com"
Deploy web service (already set up):
User: "Deploy my Express API to Render"
Agent: [executes: render services list]
Agent: "Found existing service 'my-api'. Triggering deployment..."
Agent: [executes: render deploys create --service-name my-api]
Agent: "Deployment triggered! Checking status..."
Agent: [executes: render deploys list --service-name my-api]
Agent: "Build in progress. Your API will be live at https://my-api.onrender.com once complete."
Check deployment status:
User: "What's the status of my Render deployment?"
Agent: [executes: render deploys list --service-name my-api]
Agent: "Latest deployment:
- Status: live
- Deployed: 5 minutes ago"
Best Practices
- Use health checks for automatic recovery
- Set start command explicitly for reliable builds
- Use environment groups for shared config
- Enable auto-deploy for CI/CD workflow (configure in dashboard)
- Upgrade from free tier for production (no spin-down)
- Use render.yaml for reproducible infrastructure