Deploy to Render

Render supports Git-backed services and prebuilt Docker image services.

This skill covers Git-backed flows:

1. Blueprint Method - Generate render.yaml for Infrastructure-as-Code deployments
2. Direct Creation - Create services instantly via MCP tools

Blueprints can also run a prebuilt Docker image by using runtime: image, but the render.yaml still must live in a Git repo.

If there is no Git remote, stop and ask the user to either:

• Create/push a Git remote (can be minimal if only the Blueprint is needed), or
• Use the Render Dashboard/API to deploy a prebuilt Docker image (MCP cannot create image-backed services).

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 only to fill missing information. Do not ask the user to repeat details they already supplied. If the source and required resources are clear, proceed directly to method selection and deployment.

1. Ask whether they want to deploy from a Git repo or a prebuilt Docker image.
2. 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).

Choose Your Deployment Method (Git Repo)

Both methods require a Git repository pushed to GitHub, GitLab, or Bitbucket. (If using runtime: image, the repo can be minimal and only contain render.yaml.)

Method	Best For	Pros
Blueprint	Multi-service apps, IaC workflows	Version controlled, reproducible, supports complex setups
Direct Creation	Single services, quick deployments	Instant creation, no render.yaml file needed

Method Selection Heuristic

Use this decision rule by default unless the user requests a specific method. Analyze the codebase first; only ask if deployment intent is unclear (e.g., DB, workers, cron).

Use Direct Creation (MCP) when ALL are true:

• Single service (one web app or one static site)
• No separate worker/cron services
• No attached databases or Key Value
• Simple env vars only (no shared env groups) If this path fits and MCP isn't configured yet, stop and guide MCP setup before proceeding.

Use Blueprint when ANY are true:

• Multiple services (web + worker, API + frontend, etc.)
• Databases, Key Value, or other datastores are required
• Cron jobs, background workers, or private services
• You want reproducible IaC or a render.yaml committed to the repo
• Monorepo or multi-env setup that needs consistent configuration

If unsure, ask a quick clarifying question, but default to Blueprint for safety. For a single service, strongly prefer Direct Creation via MCP and guide MCP setup if needed.

Prerequisites Check

When starting a deployment, verify these requirements in order:

1. Confirm Source Path (Git vs Docker)

If using Git-based methods (Blueprint or Direct Creation), the repo must be pushed to GitHub/GitLab/Bitbucket. Blueprints that reference a prebuilt image still require a Git repo with render.yaml.

git remote -v

• If no remote exists, stop and ask the user to create/push a remote or switch to Docker image deploy.

2. Establish Render Access

Before reading or changing Render resources, follow references/render-access.md to choose an access path, authenticate, verify the intended workspace, and confirm the required capability. Blueprint validation still requires the Render CLI even when MCP is available.

Once prerequisites are met, proceed with deployment workflow.

Before triggering, monitoring, restarting, or rolling back a deploy, read references/deployments.md for the current lifecycle, health-check, and verification workflow.

When resources communicate over Render's private network, read references/private-networking.md before choosing regions or wiring addresses and ports.

Before selecting or changing a service type, read references/service-types.md.

---

Method 1: Blueprint Deployment (Recommended for Complex Apps)

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.

Before authoring or changing the file, read references/blueprints.md and follow its current specification-fetch, validation, repository-sync, and safety workflow.

For variables, secrets, secret files, or environment groups, also read references/environment-variables.md.

Key Points:

• Select a compute plan appropriate to the resource and workload. Consult references/compute-plans.md for current Plan IDs, defaults, availability, and pricing guidance instead of relying on examples in this skill.
• Unless the user specifies a region, place new resources in the same region as their related existing services to preserve private network connectivity.
• Include every environment variable the app requires and use the intended source of truth and secret mechanism from references/environment-variables.md
• Use appropriate service type: web, worker, cron, keyvalue, or pserv (type: web with runtime: static for static sites)
• 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
• pserv: Private services (internal only, within same account and region)
• keyvalue: Redis-compatible key-value store

A service with type: web and runtime: static is a static site served via global CDN. Static sites do not have a plan.

Postgres databases are defined under the databases key instead of the services key. They do not have a type.

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:

1. Confirm access: follow references/render-access.md
2. Validate: run render blueprints validate render.yaml
   • If the CLI isn't installed, offer to install it and provide the command.
3. Commit + push: git add render.yaml && git commit -m "Add Render deployment configuration" && git push origin main
4. Open Dashboard: Use the Blueprint deeplink and complete Git OAuth if prompted
5. Complete secret configuration: Supply any values required by the selected environment-variable workflow
6. Deploy: Click "Apply" and monitor the deploy

Step 3: Validate Configuration

Follow the validation workflow in references/blueprints.md. If the CLI is installed, run the commands directly; only prompt the user if the CLI is missing:

render blueprints validate render.yaml

If the Blueprint is not at render.yaml relative to the current directory, pass its actual file path instead.

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
git@github.com:user/repo.git	https://github.com/user/repo
git@gitlab.com:user/repo.git	https://gitlab.com/user/repo
git@bitbucket.org: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=<REPOSITORY_URL>

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:

1. Verify render.yaml is merged - Confirm the file exists in your repository on GitHub/GitLab/Bitbucket
2. Click the deeplink to open Render Dashboard
3. Complete Git provider OAuth if prompted
4. Name the Blueprint (or use default from render.yaml)
5. Complete any required secret configuration without exposing values
6. Review services and databases configuration
7. 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, follow references/deployments.md to monitor the specific deploy through a terminal status and verify the resulting workload.

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

---

Method 2: Direct Service Creation (Quick Single-Service Deployments)

For simple deployments without Infrastructure-as-Code, create services directly via MCP tools.

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

Prerequisites for Direct Creation

Repository must be pushed to a Git provider. Render clones your repository to build and deploy services.

git remote -v  # Verify remote exists
git push origin main  # Ensure code is pushed

Supported providers: GitHub, GitLab, Bitbucket

If no remote exists, stop and ask the user to create/push a remote or switch to Docker image deploy.

Note: MCP does not support creating image-backed services. Use the Dashboard/API for prebuilt Docker image deploys.

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

Before changing service configuration, read references/environment-variables.md. Add required env vars via MCP after creation using 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.

---

Post-deploy verification and basic triage (All Methods)

Follow references/deployments.md for deploy-state interpretation and post-live verification. If any check fails, fix it before redeploying.

Detailed checklist and commands: references/post-deploy-checks.md

If the service fails to start or health checks time out, use the basic triage guide: references/troubleshooting-basics.md

Optional: If you need deeper diagnostics (metrics/DB checks/error catalog), suggest installing the render-debug skill. It is not required for the core deploy flow.

Current documentation retrieval

Whenever this skill directs you to consult current Render documentation:

1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as curl. Do not substitute web-search summaries for the document.
2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.
3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.
4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.

When a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.