render-deploy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Deploy to Render

部署到Render

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

This skill covers Git-backed flows:

Blueprint Method - Generate render.yaml for Infrastructure-as-Code deployments
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).

Render支持基于Git的服务和预构建Docker镜像服务。

本技能涵盖基于Git的工作流：

蓝图法 - 生成用于基础设施即代码部署的render.yaml
直接创建 - 通过MCP工具即时创建服务

蓝图也可以通过使用

runtime: image

来运行预构建Docker镜像，但

render.yaml

仍必须存储在Git仓库中。

如果没有Git远程仓库，请暂停并要求用户执行以下操作之一：

创建/推送Git远程仓库（如果只需要蓝图，仓库可以是最小化的），或者
使用Render Dashboard/API部署预构建Docker镜像（MCP无法创建基于镜像的服务）。

Prerequisites

前提条件

When sandboxing blocks the deployment network calls, rerun with
```
sandbox_permissions=require_escalated
```
.
The deployment might take a few minutes. Use appropriate timeout values.

当沙箱阻止部署网络调用时，使用
```
sandbox_permissions=require_escalated
```
重新运行。
部署可能需要几分钟时间，请设置适当的超时值。

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

当用户希望执行以下操作时激活本技能：

将应用部署到Render
创建render.yaml蓝图文件
为项目设置Render部署
在Render的云平台上托管或发布应用
创建数据库、定时任务或其他Render资源

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.

在深入分析之前，使用以下简短提示序列以减少操作阻力：

询问用户是要从Git仓库还是预构建Docker镜像进行部署。
询问Render是否应自动配置应用所需的所有资源（根据用户描述判断可能性），还是仅创建应用而由用户自行提供基础设施。如果依赖关系不明确，请简短跟进确认是否需要数据库、工作进程、定时任务或其他服务。

然后按照以下相应方法继续操作。

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

Git仓库路径： 蓝图法和直接创建法都需要此路径。仓库必须推送到GitHub、GitLab或Bitbucket。

预构建Docker镜像路径： Render通过基于镜像的服务支持此方式。但MCP不支持此方式；请使用Dashboard/API。需要询问用户：

镜像URL（注册表+标签）
注册表认证信息（如果是私有镜像）
服务类型（web/worker）和端口

如果用户选择Docker镜像，请引导他们使用Render Dashboard的镜像部署流程，或要求他们添加Git远程仓库（以便可以使用带有

runtime: image

的蓝图）。

Choose Your Deployment Method (Git Repo)

选择部署方法（Git仓库）

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

两种方法都需要推送到GitHub、GitLab或Bitbucket的Git仓库。（如果使用

runtime: image

，仓库可以是最小化的，仅包含

render.yaml

。）

方法	最佳适用场景	优势
蓝图法	多服务应用、基础设施即代码工作流	版本可控、可重现、支持复杂配置
直接创建法	单服务、快速部署	即时创建、无需render.yaml文件

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, Redis/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.

除非用户要求特定方法，否则默认使用以下决策规则。先分析代码库；仅当部署意图不明确时（例如是否需要数据库、工作进程、定时任务）才询问用户。

当以下所有条件都满足时，使用直接创建法（MCP）：

单服务（一个Web应用或一个静态站点）
无独立的工作进程/定时任务服务
无附加数据库或键值存储
仅需简单环境变量（无共享环境变量组）如果符合此路径且MCP尚未配置，请暂停并引导用户完成MCP设置后再继续。

当以下任一条件满足时，使用蓝图法：

多服务（Web+工作进程、API+前端等）
需要数据库、Redis/键值存储或其他数据存储
需要定时任务、后台工作进程或私有服务
希望使用可重现的基础设施即代码，或在仓库中提交render.yaml
需要一致配置的单体仓库或多环境设置

如果不确定，请快速询问澄清问题，但默认优先选择蓝图法。对于单服务，强烈建议通过MCP使用直接创建法，并在需要时引导用户完成MCP设置。

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

bash

git remote -v

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

2. Check MCP Tools Availability (Preferred for Single-Service)

MCP tools provide the best experience. Check if available by attempting:

list_services()

If MCP tools are available, you can skip CLI installation for most operations.

3. Check Render CLI Installation (for Blueprint validation)

bash

render --version

If not installed, offer to install:

macOS:
```
brew install render
```

Linux/macOS:

curl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | sh

4. MCP Setup (if MCP isn't configured)

list_services()

fails because MCP isn't configured, ask whether they want to set up MCP (preferred) or continue with the CLI fallback. If they choose MCP, ask which AI tool they're using, then provide the matching instructions below. Always use their API key.

开始部署时，请按顺序验证以下要求：

1. 确认源路径（Git vs Docker）

如果使用基于Git的方法（蓝图法或直接创建法），仓库必须推送到GitHub/GitLab/Bitbucket。引用预构建镜像的蓝图仍需要包含render.yaml的Git仓库。

bash

git remote -v

如果没有远程仓库，请暂停并要求用户创建/推送远程仓库或切换到Docker镜像部署。

2. 检查MCP工具可用性（单服务优先选择）

MCP工具提供最佳体验。通过尝试以下命令检查是否可用：

list_services()

如果MCP工具可用，大多数操作可以跳过CLI安装。

3. 检查Render CLI安装情况（用于蓝图验证）

bash

render --version

如果未安装，提供安装选项：

macOS：
```
brew install render
```

Linux/macOS：

curl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | sh

4. MCP设置（如果MCP未配置）

如果

list_services()

因MCP未配置而失败，请询问用户是否要设置MCP（优先选择）或继续使用CLI备选方案。如果用户选择MCP，请询问他们使用的是哪种AI工具，然后提供以下对应的设置说明。请始终使用他们的API密钥。

Cursor

Walk the user through these steps:

Get a Render API key:

https://dashboard.render.com/u/*/settings#api-keys

Add this to
```
~/.cursor/mcp.json
```
(replace
```
<YOUR_API_KEY>
```
):

json

{
  "mcpServers": {
    "render": {
      "url": "https://mcp.render.com/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

Restart Cursor, then retry
```
list_services()
```
.

引导用户完成以下步骤：

获取Render API密钥：

https://dashboard.render.com/u/*/settings#api-keys

将以下内容添加到
```
~/.cursor/mcp.json
```
（替换
```
<YOUR_API_KEY>
```
）：

json

{
  "mcpServers": {
    "render": {
      "url": "https://mcp.render.com/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

重启Cursor，然后重试
```
list_services()
```
。

Claude Code

Walk the user through these steps:

Get a Render API key:

https://dashboard.render.com/u/*/settings#api-keys

Add the MCP server with Claude Code (replace
```
<YOUR_API_KEY>
```
):

bash

claude mcp add --transport http render https://mcp.render.com/mcp --header "Authorization: Bearer <YOUR_API_KEY>"

Restart Claude Code, then retry
```
list_services()
```
.

引导用户完成以下步骤：

获取Render API密钥：

https://dashboard.render.com/u/*/settings#api-keys

使用Claude Code添加MCP服务器（替换
```
<YOUR_API_KEY>
```
）：

bash

claude mcp add --transport http render https://mcp.render.com/mcp --header "Authorization: Bearer <YOUR_API_KEY>"

重启Claude Code，然后重试
```
list_services()
```
。

Codex

Walk the user through these steps:

Get a Render API key:

https://dashboard.render.com/u/*/settings#api-keys

Set it in their shell:

bash

export RENDER_API_KEY="<YOUR_API_KEY>"

Add the MCP server with the Codex CLI:

bash

codex mcp add render --url https://mcp.render.com/mcp --bearer-token-env-var RENDER_API_KEY

Restart Codex, then retry
```
list_services()
```
.

引导用户完成以下步骤：

获取Render API密钥：

https://dashboard.render.com/u/*/settings#api-keys

在shell中设置：

bash

export RENDER_API_KEY="<YOUR_API_KEY>"

使用Codex CLI添加MCP服务器：

bash

codex mcp add render --url https://mcp.render.com/mcp --bearer-token-env-var RENDER_API_KEY

重启Codex，然后重试
```
list_services()
```
。

Other Tools

其他工具

If the user is on another AI app, direct them to the Render MCP docs for that tool's setup steps and install method.

如果用户使用其他AI应用，请引导他们查看Render MCP文档中对应工具的设置步骤和安装方法。

Workspace Selection

工作区选择

After MCP is configured, have the user set the active Render workspace with a prompt like:

Set my Render workspace to [WORKSPACE_NAME]

5. Check Authentication (CLI fallback only)

If MCP isn't available, use the CLI instead and verify you can access your account:

bash

undefined

MCP配置完成后，让用户通过类似以下提示设置活动Render工作区：

将我的Render工作区设置为[WORKSPACE_NAME]

5. 检查认证情况（仅CLI备选方案）

如果MCP不可用，请改用CLI并验证是否可以访问账户：

bash

undefined

Check if user is logged in (use -o json for non-interactive mode)

检查用户是否已登录（非交互模式使用-o json）

render whoami -o json


If `render whoami` fails or returns empty data, the CLI is not authenticated. The CLI won't always prompt automatically, so explicitly prompt the user to authenticate:

If neither is configured, ask user which method they prefer:
- **API Key (CLI)**: `export RENDER_API_KEY="rnd_xxxxx"` (Get from https://dashboard.render.com/u/*/settings#api-keys)
- **Login**: `render login` (Opens browser for OAuth)

**6. Check Workspace Context**

Verify the active workspace:

get_selected_workspace()


Or via CLI:
```bash
render workspace current -o json

To list available workspaces:

list_workspaces()

If user needs to switch workspaces, they must do so via Dashboard or CLI (

render workspace set

Once prerequisites are met, proceed with deployment workflow.

render whoami -o json


如果`render whoami`失败或返回空数据，表示CLI未认证。CLI不会始终自动提示，因此请明确提示用户进行认证：

如果两者都未配置，请询问用户偏好哪种方法：
- **API密钥（CLI）**：`export RENDER_API_KEY="rnd_xxxxx"`（从https://dashboard.render.com/u/*/settings#api-keys获取）
- **登录**：`render login`（打开浏览器进行OAuth认证）

**6. 检查工作区上下文**

验证活动工作区：

get_selected_workspace()


或通过CLI：
```bash
render workspace current -o json

列出可用工作区：

list_workspaces()

如果用户需要切换工作区，必须通过Dashboard或CLI（

render workspace set

）完成。

满足所有前提条件后，继续部署工作流。

Method 1: Blueprint Deployment (Recommended for Complex Apps)

方法1：蓝图部署（复杂应用推荐）

Blueprint Workflow

蓝图工作流

Step 1: Analyze Codebase

步骤1：分析代码库

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.

分析代码库以确定框架/运行时、构建和启动命令、所需环境变量、数据存储和端口绑定。使用references/codebase-analysis.md中的详细检查清单。

Step 2: Generate render.yaml

步骤2：生成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:

yaml

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/

按照蓝图规范创建

render.yaml

蓝图文件。

完整规范：references/blueprint-spec.md

关键点：

除非用户指定，否则始终使用
```
plan: free
```
包含应用所需的所有环境变量
使用
```
sync: false
```
标记密钥（用户在Dashboard中填写）
使用适当的服务类型：
```
web
```
、
```
worker
```
、
```
cron
```
、
```
static
```
或
```
pserv
```
使用适当的运行时：references/runtimes.md

基本结构：

yaml

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  # 用户在Dashboard中填写

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

服务类型：

```
web
```
：HTTP服务、API、Web应用（公开可访问）
```
worker
```
：后台任务处理器（不公开可访问）
```
cron
```
：按定时计划运行的任务
```
static
```
：静态站点（通过CDN提供HTML/CSS/JS）
```
pserv
```
：私有服务（仅在同一账户内可访问）

服务类型详情：references/service-types.md 运行时选项：references/runtimes.md 模板示例：assets/

Step 2.5: Immediate Next Steps (Always Provide)

步骤2.5：立即后续步骤（必须提供）

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

创建render.yaml后，始终为用户提供简短明确的检查清单，并在CLI可用时立即运行验证：

认证（CLI）：运行
```
render whoami -o json
```
（如果未登录，运行
```
render login
```
或设置
```
RENDER_API_KEY
```
）
验证（推荐）：运行
```
render blueprints validate
```
- 如果未安装CLI，提供安装选项和命令。

提交并推送：

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

打开Dashboard：使用蓝图深度链接，并在提示时完成Git OAuth认证
填写密钥：设置标记为
```
sync: false
```
的环境变量
部署：点击“应用”并监控部署过程

Step 3: Validate Configuration

步骤3：验证配置

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:

bash

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

验证render.yaml文件以在部署前发现错误。如果已安装CLI，直接运行命令；仅当CLI缺失时才提示用户：

bash

render whoami -o json  # 确保CLI已认证（不会始终提示）
render blueprints validate

在继续之前修复所有验证错误。常见问题：

缺少必填字段（
```
name
```
、
```
type
```
、
```
runtime
```
）
无效的运行时值
YAML语法错误
无效的环境变量引用

配置指南：references/configuration-guide.md

Step 4: Commit and Push

步骤4：提交并推送

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:

bash

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.

重要提示： 必须先将

render.yaml

文件合并到仓库中，然后才能部署。

确保

render.yaml

文件已提交并推送到Git远程仓库：

bash

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

如果还没有Git远程仓库，请在此处暂停并引导用户创建GitHub/GitLab/Bitbucket仓库，将其添加为

origin

，然后推送后再继续。

为什么这很重要： Dashboard深度链接将从仓库中读取render.yaml。如果文件未合并和推送，Render将无法找到配置，部署将失败。

在继续下一步之前，验证文件是否已存在于远程仓库中。

Step 5: Generate Deeplink

步骤5：生成深度链接

Get the Git repository URL:

bash

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

获取Git仓库URL：

bash

git remote get-url origin

这将返回来自Git提供商的URL。如果是SSH格式，请转换为HTTPS格式：

SSH格式	HTTPS格式
`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`

转换模式： 将

git@<host>:

替换为

https://<host>/

并移除

.git

后缀。

使用HTTPS仓库URL格式化Dashboard深度链接：

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

示例：

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

Step 6: Guide User

步骤6：引导用户

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.

关键提示： 确保用户在点击深度链接之前已将render.yaml文件合并并推送到仓库。如果文件不在仓库中，Render将无法读取蓝图配置，部署将失败。

为用户提供深度链接和以下说明：

验证render.yaml已合并 - 确认文件存在于GitHub/GitLab/Bitbucket的仓库中
点击深度链接打开Render Dashboard
提示时完成Git提供商OAuth认证
为蓝图命名（或使用render.yaml中的默认名称）
填写密钥环境变量（标记为
```
sync: false
```
的变量）
查看服务和数据库配置
点击“应用”开始部署

部署将自动开始。用户可以在Render Dashboard中监控进度。

Step 7: Verify Deployment

步骤7：验证部署

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

Check deployment status via MCP:

list_deploys(serviceId: "<service-id>", limit: 1)

Look for

status: "live"

to confirm successful deployment.

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

list_logs(resource: ["<service-id>"], level: ["error"], limit: 20)

Check service health metrics:

get_metrics(
  resourceId: "<service-id>",
  metricTypes: ["http_request_count", "cpu_usage", "memory_usage"]
)

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

用户通过Dashboard部署后，验证一切正常。

通过MCP检查部署状态：

list_deploys(serviceId: "<service-id>", limit: 1)

查找

status: "live"

以确认部署成功。

检查运行时错误（部署后等待2-3分钟）：

list_logs(resource: ["<service-id>"], level: ["error"], limit: 20)

检查服务健康指标：

get_metrics(
  resourceId: "<service-id>",
  metricTypes: ["http_request_count", "cpu_usage", "memory_usage"]
)

如果发现错误，请继续执行以下部署后验证和基本故障排查部分。

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

方法2：直接服务创建（快速单服务部署）

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

对于无需基础设施即代码的简单部署，通过MCP工具直接创建服务。

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

单Web服务或静态站点
快速原型或演示
不需要在仓库中添加render.yaml文件时
为现有项目添加数据库或定时任务时

Prerequisites for Direct Creation

直接创建法前提条件

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

bash

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.

仓库必须推送到Git提供商。 Render将克隆仓库以构建和部署服务。

bash

git remote -v  # 验证远程仓库存在
git push origin main  # 确保代码已推送

支持的提供商：GitHub、GitLab、Bitbucket

如果没有远程仓库，请暂停并要求用户创建/推送远程仓库或切换到Docker镜像部署。

注意： MCP不支持创建基于镜像的服务。预构建Docker镜像部署请使用Dashboard/API。

Direct Creation Workflow

直接创建工作流

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

使用以下简洁步骤，完整的MCP命令示例和后续配置请参考references/direct-creation.md。

Step 1: Analyze Codebase

步骤1：分析代码库

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

使用references/codebase-analysis.md确定运行时、构建/启动命令、环境变量和数据存储。

Step 2: Create Resources via MCP

步骤2：通过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.

创建服务（web或static）以及任何所需的数据库或键值存储。请参阅references/direct-creation.md。

如果MCP返回关于缺少Git凭据或仓库访问权限的错误，请暂停并引导用户在Render Dashboard中连接其Git提供商，然后重试。

Step 3: Configure Environment Variables

步骤3：配置环境变量

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.

创建后通过MCP添加所需的环境变量。请参阅references/direct-creation.md。

提醒用户，如果他们不想通过MCP传递密钥，可以在Dashboard中设置。

Step 4: Verify Deployment

步骤4：验证部署

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.

检查部署状态、日志和指标。请参阅references/direct-creation.md。

有关服务发现、配置详情、快速命令和常见问题，请参阅references/deployment-details.md。

Post-deploy verification and basic triage (All Methods)

部署后验证和基本故障排查（所有方法）

Keep this short and repeatable. If any check fails, fix it before redeploying.

Confirm the latest deploy is
```
live
```
and serving traffic
Hit the health endpoint (or root) and verify a 200 response
Scan recent error logs for a clear failure signature
Verify required env vars and port binding (
```
0.0.0.0:$PORT
```
)

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

保持简短且可重复。如果任何检查失败，请在重新部署前修复。

确认最新部署已处于
```
live
```
状态并正在提供流量
访问健康端点（或根路径）并验证返回200响应
扫描近期错误日志以查找明确的失败特征
验证所需环境变量和端口绑定（
```
0.0.0.0:$PORT
```
）

详细检查清单和命令：references/post-deploy-checks.md

如果服务无法启动或健康检查超时，请使用基本故障排查指南： references/troubleshooting-basics.md

Troubleshooting

故障排查

Escalated Network Access

提升网络权限

If deployment fails due to network issues (timeouts, DNS errors, connection resets), rerun the deploy with escalated permissions (use

sandbox_permissions=require_escalated

). The deploy requires escalated network access when sandbox networking blocks outbound requests.

Example guidance to the user:

The deploy needs escalated network access to deploy to Render. I can rerun the command with escalated permissions—want me to proceed?

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.

如果部署因网络问题（超时、DNS错误、连接重置）而失败，请使用提升权限重新运行部署（使用

sandbox_permissions=require_escalated

）。当沙箱网络阻止出站请求时，部署需要提升网络权限。

给用户的示例指引：

部署到Render需要提升网络权限。我可以使用提升权限重新运行命令——是否继续？

可选：如果需要更深入的诊断（指标/数据库检查/错误目录），建议安装

render-debug

技能。核心部署流程不需要此技能。