render-deploy

by openai

Deploy applications to Render with Git-backed services or prebuilt Docker images via Blueprint or direct creation. Supports two deployment methods: Blueprint (Infrastructure-as-Code via render.yaml) for multi-service apps, and Direct Creation (MCP tools) for single services Analyzes codebases to determine runtime, build/start commands, environment variables, and required datastores (databases, Redis, cron jobs) Generates render.yaml configurations with automatic service type selection (web,... npx skills add https://github.com/openai/skills --skill render-deploy Download ZIPGitHub23.2k

When to Use This Skill

Activate this skill when users want to:

• Deploy an application to Render

• Create a render.yaml Blueprint file

• Set up Render deployment for their project

• Host or publish their application on Render's cloud platform

• Create databases, cron jobs, or other Render resources

Happy Path (New Users)

Use this short prompt sequence before deep analysis to reduce friction:

• Ask whether they want to deploy from a Git repo or a prebuilt Docker image.

• Ask whether Render should provision everything the app needs (based on what seems likely from the user's description) or only the app while they bring their own infra. If dependencies are unclear, ask a short follow-up to confirm whether they need a database, workers, cron, or other services.

Then proceed with the appropriate method below.

Choose Your Source Path

Git Repo Path: Required for both Blueprint and Direct Creation. The repo must be pushed to GitHub, GitLab, or Bitbucket.

Prebuilt Docker Image Path: Supported by Render via image-backed services. This is not supported by MCP; use the Dashboard/API. Ask for:

• Image URL (registry + tag)

• Registry auth (if private)

• Service type (web/worker) and port

If the user chooses a Docker image, guide them to the Render Dashboard image deploy flow or ask them to add a Git remote (so you can use a Blueprint with runtime: image).

Blueprint Workflow

Step 1: Analyze Codebase

Analyze the codebase to determine framework/runtime, build and start commands, required env vars, datastores, and port binding. Use the detailed checklists in references/codebase-analysis.md.

Step 2: Generate render.yaml

Create a render.yaml Blueprint file following the Blueprint specification.

Complete specification: references/blueprint-spec.md

Key Points:

• Always use plan: free unless user specifies otherwise

• Include ALL environment variables the app needs

• Mark secrets with sync: false (user fills these in Dashboard)

• Use appropriate service type: web, worker, cron, static, or pserv

• Use appropriate runtime: references/runtimes.md

Basic Structure:

services:
 - type: web
 name: my-app
 runtime: node
 plan: free
 buildCommand: npm ci
 startCommand: npm start
 envVars:
 - key: DATABASE_URL
 fromDatabase:
 name: postgres
 property: connectionString
 - key: JWT_SECRET
 sync: false # User fills in Dashboard

databases:
 - name: postgres
 databaseName: myapp_db
 plan: free

Service Types:

• web: HTTP services, APIs, web applications (publicly accessible)

• worker: Background job processors (not publicly accessible)

• cron: Scheduled tasks that run on a cron schedule

• static: Static sites (HTML/CSS/JS served via CDN)

• pserv: Private services (internal only, within same account)

Service type details: references/service-types.md Runtime options: references/runtimes.md Template examples: assets/

Step 2.5: Immediate Next Steps (Always Provide)

After creating render.yaml, always give the user a short, explicit checklist and run validation immediately when the CLI is available:

• Authenticate (CLI): run render whoami -o json (if not logged in, run render login or set RENDER_API_KEY)

• Validate (recommended): run render blueprints validate

• If the CLI isn't installed, offer to install it and provide the command.

• Commit + push: git add render.yaml && git commit -m "Add Render deployment configuration" && git push origin main

• Open Dashboard: Use the Blueprint deeplink and complete Git OAuth if prompted

• Fill secrets: Set env vars marked sync: false

• Deploy: Click "Apply" and monitor the deploy

Step 3: Validate Configuration

Validate the render.yaml file to catch errors before deployment. If the CLI is installed, run the commands directly; only prompt the user if the CLI is missing:

render whoami -o json # Ensure CLI is authenticated (won't always prompt)
render blueprints validate

Fix any validation errors before proceeding. Common issues:

• Missing required fields (name, type, runtime)

• Invalid runtime values

• Incorrect YAML syntax

• Invalid environment variable references

Configuration guide: references/configuration-guide.md

Step 4: Commit and Push

IMPORTANT: You must merge the render.yaml file into your repository before deploying.

Ensure the render.yaml file is committed and pushed to your Git remote:

git add render.yaml
git commit -m "Add Render deployment configuration"
git push origin main

If there is no Git remote yet, stop here and guide the user to create a GitHub/GitLab/Bitbucket repo, add it as origin, and push before continuing.

Why this matters: The Dashboard deeplink will read the render.yaml from your repository. If the file isn't merged and pushed, Render won't find the configuration and deployment will fail.

Verify the file is in your remote repository before proceeding to the next step.

Step 5: Generate Deeplink

Get the Git repository URL:

git remote get-url origin

This will return a URL from your Git provider. If the URL is SSH format, convert it to HTTPS:

SSH Format HTTPS Format [email protected] :user/repo.git https://github.com/user/repo [email protected] :user/repo.git https://gitlab.com/user/repo [email protected] :user/repo.git https://bitbucket.org/user/repo

Conversion pattern: Replace git@<host>: with https://<host>/ and remove .git suffix.

Format the Dashboard deeplink using the HTTPS repository URL:

https://dashboard.render.com/blueprint/new?repo= 

Example:

https://dashboard.render.com/blueprint/new?repo=https://github.com/username/repo-name

Step 6: Guide User

CRITICAL: Ensure the user has merged and pushed the render.yaml file to their repository before clicking the deeplink. If the file isn't in the repository, Render cannot read the Blueprint configuration and deployment will fail.

Provide the deeplink to the user with these instructions:

• Verify render.yaml is merged - Confirm the file exists in your repository on GitHub/GitLab/Bitbucket

• Click the deeplink to open Render Dashboard

• Complete Git provider OAuth if prompted

• Name the Blueprint (or use default from render.yaml)

• Fill in secret environment variables (marked with sync: false)

• Review services and databases configuration

• Click "Apply" to deploy

The deployment will begin automatically. Users can monitor progress in the Render Dashboard.

Step 7: Verify Deployment

After the user deploys via Dashboard, verify everything is working.

Check deployment status via MCP:

list_deploys(serviceId: " ", limit: 1)

Look for status: "live" to confirm successful deployment.

Check for runtime errors (wait 2-3 minutes after deploy):

list_logs(resource: [" "], level: ["error"], limit: 20)

Check service health metrics:

get_metrics(
 resourceId: " ",
 metricTypes: ["http_request_count", "cpu_usage", "memory_usage"]
)

If errors are found, proceed to the Post-deploy verification and basic triage section below.

When to Use Direct Creation

• Single web service or static site

• Quick prototypes or demos

• When you don't need a render.yaml file in your repo

• Adding databases or cron jobs to existing projects

Direct Creation Workflow

Use the concise steps below, and refer to references/direct-creation.md for full MCP command examples and follow-on configuration.

Step 1: Analyze Codebase

Use references/codebase-analysis.md to determine runtime, build/start commands, env vars, and datastores.

Step 2: Create Resources via MCP

Create the service (web or static) and any required databases or key-value stores. See references/direct-creation.md.

If MCP returns an error about missing Git credentials or repo access, stop and guide the user to connect their Git provider in the Render Dashboard, then retry.

Step 3: Configure Environment Variables

Add required env vars via MCP after creation. See references/direct-creation.md.

Remind the user that secrets can be set in the Dashboard if they prefer not to pass them via MCP.

Step 4: Verify Deployment

Check deploy status, logs, and metrics. See references/direct-creation.md.

For service discovery, configuration details, quick commands, and common issues, see references/deployment-details.md.