From render
Authors and validates render.yaml Blueprints for Render infrastructure. Wires services via fromDatabase/fromService/fromGroup, configures projects/environments/previews, validates schema, fixes immutable field errors.
npx claudepluginhub render-oss/skills --plugin renderThis skill uses the workspace's default tool permissions.
Blueprints define Render infrastructure as YAML (commonly `render.yaml` at the repo root). This skill focuses on **authoring**, **wiring**, **projects/environments**, **previews**, **validation**, and **immutable fields**. Heavy detail lives under `references/`.
Deploys apps to Render by analyzing codebases, generating render.yaml blueprints, and providing dashboard deeplinks. For Git-backed services, Docker images, databases, and cron jobs.
Deploys Git-backed apps to Render by analyzing codebases, generating render.yaml blueprints, creating services via MCP, and providing dashboard deeplinks. Use for hosting on Render.
Automates Render cloud platform operations like listing services, triggering deployments, and managing projects via Rube MCP and Composio toolkit. Use for Render DevOps workflows after connecting via RUBE_MANAGE_CONNECTIONS.
Share bugs, ideas, or general feedback.
Blueprints define Render infrastructure as YAML (commonly render.yaml at the repo root). This skill focuses on authoring, wiring, projects/environments, previews, validation, and immutable fields. Heavy detail lives under references/.
Apply this skill when the user:
render.yaml / BlueprintFor end-to-end deploy flows and MCP/CLI operations, see render-deploy. For env var strategy outside Blueprint syntax, see render-env-vars. For Docker-specific Blueprint fields, see render-docker.
| Key | Purpose |
|---|---|
services | Web, worker, cron, private service, Key Value, static (via web + runtime: static) |
databases | Managed PostgreSQL instances |
envVarGroups | Reusable env var sets attached to services |
projects | Optional grouping; contains environments and service lists |
previews | Defaults for PR preview environments |
A Blueprint may also use patterns like ungrouped resources vs environment-scoped lists, depending on whether you adopt the projects model. Avoid duplicating the same logical resource in multiple places (see references/common-mistakes.md).
https://render.com/schema/render.yaml.jsonrender.yaml with that schema for completions and diagnostics.databases:
- name: mydb
plan: basic-256mb
region: oregon
services:
- type: web
name: api
runtime: node
region: oregon
plan: starter
buildCommand: npm ci && npm run build
startCommand: npm start
envVars:
- key: DATABASE_URL
fromDatabase:
name: mydb
property: connectionString
type | Role |
|---|---|
web | Public HTTP service (use runtime: static for static sites) |
pserv | Private service (internal HTTP/TCP; not public) |
worker | Long-running background process |
cron | Scheduled job (schedule required) |
keyvalue | Managed Key Value (Redis-compatible); alias redis accepted in Blueprints |
Common runtime values: node, python, go, ruby, rust, elixir, docker, image, static.
docker: Build from Dockerfile (see dockerfilePath, dockerContext, dockerCommand).image: Run a prebuilt container image (registry + optional registryCredential).static: Static site; requires staticPublishPath and build output paths (see references).Env vars under envVars (and analogous patterns in groups) can pull values from other resources instead of hardcoding secrets.
fromDatabaseReference a database in databases: by name. Properties include:
connectionString, host, port, user, password, databasefromServiceReference a service by name. Typical properties:
host, port, hostport, connectionString, envVarKeyWhich properties are valid depends on target service type (e.g. Key Value vs pserv). See references/wiring-patterns.md.
fromGroupAttach shared vars from envVarGroups (by group name).
value: Literal string.generateValue: Let Render generate a random secret (password/API key).sync: Set sync: false for secrets that should not sync from repo on every update (see edge cases in wiring reference).Full patterns and combinations: references/wiring-patterns.md.
For multi-service apps, use the projects/environments pattern instead of flat top-level services/databases. This groups all related resources into a single Render project, supports multiple environments (production, staging), and enables environment-scoped configuration.
projects:
- name: my-app
environments:
- name: production
services:
- type: web
name: api
runtime: node
plan: standard
buildCommand: npm ci && npm run build
startCommand: npm start
envVars:
- key: DATABASE_URL
fromDatabase:
name: db
property: connectionString
- key: REDIS_URL
fromService:
type: keyvalue
name: cache
property: connectionString
- key: API_SECRET
sync: false
- type: worker
name: jobs
runtime: node
plan: starter
buildCommand: npm ci
startCommand: node worker.js
envVars:
- key: DATABASE_URL
fromDatabase:
name: db
property: connectionString
- key: REDIS_URL
fromService:
type: keyvalue
name: cache
property: connectionString
- type: keyvalue
name: cache
plan: starter
maxmemoryPolicy: noeviction
ipAllowList:
- source: 0.0.0.0/0
description: everywhere
databases:
- name: db
plan: starter
Key rules:
services and databases lists.envVarGroups can be scoped to a project environment or shared across the workspace.For single-service apps, flat top-level services/databases is fine. Reach for the projects pattern when you have multiple services, need staging/production separation, or want environment-scoped env groups.
Top-level previews controls PR previews:
previews.generation: off (default), manual, or automaticpreviews.expireAfterDays: Auto-delete preview stacks after N daysServices can override preview behavior (e.g. service-level previews.generation). Limitations: autoscaling behavior, sync: false vars, previewPlan / flexible instance constraints—see references/preview-environments.md.
render blueprints validate
Requires Render CLI v2.7.0+. Run from the repo root (or pass the appropriate path options your CLI version supports). Fix schema and semantic errors before merging Blueprint changes.
Official schema: https://render.com/schema/render.yaml.json
CRITICAL: Some fields cannot change after the resource is created. Edits may be rejected or require replacement resources.
type: Cannot change (e.g. web → worker).runtime: Cannot change (e.g. node → docker).Cannot change after creation:
name (logical Blueprint/database identifier in this context)databaseNameuserregionpostgresMajorVersionPlan other fields (disk, HA, replicas) carefully up front; consult Render docs for fields that can scale vs require recreation.
| Area | Fields |
|---|---|
| Plans | plan, previewPlan (previews), database plan |
| Build/run | buildCommand, startCommand, preDeployCommand, rootDir |
| Deploy | autoDeployTrigger: commit, checksPass, or off |
| Lifecycle | maxShutdownDelaySeconds: 1–300, default 30 |
| HTTP | healthCheckPath, domains |
| Storage | disk (name, mountPath, sizeGB) |
| Scale | scaling / numInstances (see references) |
| Monorepo | buildFilter (paths, ignoredPaths) |
| Docker | dockerfilePath, dockerContext, dockerCommand, registryCredential |
Deprecated names to avoid: env (use runtime), redis (use keyvalue), autoDeploy (use autoDeployTrigger), pullRequestPreviewsEnabled (use previews.generation). Details: references/common-mistakes.md.
| Document | Contents |
|---|---|
references/field-reference.md | YAML fields by service type, database, groups, projects, previews, scaling, disk, static, Key Value |
references/wiring-patterns.md | fromDatabase / fromService / fromGroup examples, sync: false, generateValue, combinations |
references/common-mistakes.md | Branch + previews, buildFilter, replicas, duplicates, preview plans, wiring mistakes |
references/preview-environments.md | previews.generation, expiry, overrides, previewPlan, disks, PR workflow |