Render应用部署Skill render-deploy

---

名称: render-deploy 描述: 通过分析代码库、生成render.yaml蓝图并提供Dashboard深链接，将应用程序部署到Render。当用户想要在Render云平台上部署、托管、发布或设置其应用程序时使用。 元数据: 作者: github.com/openai/skills 版本: ‘1.0.0’

部署到Render

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

此技能涵盖基于Git的流程：

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

蓝图也可以通过使用runtime: image运行预构建Docker镜像，但render.yaml仍需位于Git仓库中。

如果没有Git远程，停止并询问用户：

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

前提条件

• 当沙盒环境阻止部署网络调用时，使用sandbox_permissions=require_escalated重新运行。
• 部署可能需要几分钟。请使用适当的超时值。

API密钥和秘密的安全要求

关键 - 必须保护用户凭据：

处理Render API密钥或任何秘密时：

1. 切勿要求用户在聊天中直接粘贴API密钥 - 而是指导他们设置环境变量：

   export RENDER_API_KEY="rnd_xxxxx"
   

2. 切勿在示例中包含实际API密钥 - 始终使用占位符如<YOUR_API_KEY>或rnd_xxxxx

3. 指导用户安全存储 - 引导他们：

   • 为CLI认证设置环境变量
   • 使用Render Dashboard设置服务秘密（标记为sync: false的环境变量）
   • 切勿将秘密提交到Git

4. 当用户需要API密钥时，提供此指导：

   • “从以下地址获取您的API密钥：https://dashboard.render.com/u/*/settings#api-keys”
   • “将其设置为环境变量：export RENDER_API_KEY='your-key-here'”
   • “切勿共享或提交此密钥”

5. 对于MCP配置，显示结构但强调：

   • 将<YOUR_API_KEY>替换为他们的实际密钥
   • 此文件不应提交到版本控制
   • 密钥应保持私有

6. 如果用户意外在聊天中共享秘密，立即：

   • 警告他们密钥可能已泄露
   • 指导他们在Render Dashboard中撤销密钥
   • 指导他们创建新密钥

何时使用此技能

当用户想要时激活此技能：

• 将应用程序部署到Render
• 创建render.yaml蓝图文件
• 为其项目设置Render部署
• 在Render云平台上托管或发布其应用程序
• 创建数据库、cron作业或其他Render资源

快乐路径（新用户）

使用此简短提示序列，在进行深度分析前减少摩擦：

1. 询问他们是否要从Git仓库或预构建Docker镜像部署。
2. 询问Render是否应提供应用所需的一切（基于用户描述的可能性），或仅提供应用，而他们自带基础设施。如果依赖关系不明确，询问简短的后续问题以确认是否需要数据库、工作程序、cron或其他服务。

然后继续以下适当方法。

选择您的源路径

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

预构建Docker镜像路径： Render支持通过镜像支持的服务。此路径不受MCP支持；使用Dashboard/API。询问：

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

如果用户选择Docker镜像，引导他们到Render Dashboard镜像部署流程，或要求他们添加Git远程（以便您可以使用带有runtime: image的蓝图）。

选择您的部署方法（Git仓库）

两种方法都需要Git仓库推送到GitHub、GitLab或Bitbucket。（如果使用runtime: image，仓库可以最小化，仅包含render.yaml。）

方法	最适合	优点
蓝图	多服务应用、IaC工作流	版本控制、可复制、支持复杂设置
直接创建	单服务、快速部署	即时创建、无需render.yaml文件

方法选择启发式

默认使用此决策规则，除非用户请求特定方法。首先分析代码库；仅当部署意图不明确时询问（例如，数据库、工作程序、cron）。

当以下所有条件为真时使用直接创建（MCP）：

• 单服务（一个Web应用或一个静态站点）
• 无单独的工作程序/cron服务
• 无附加数据库或Key Value
• 仅简单环境变量（无共享环境组） 如果此路径适合且MCP尚未配置，停止并指导MCP设置后再继续。

当以下任一条件为真时使用蓝图：

• 多服务（web + worker、API + 前端等）
• 需要数据库、Redis/Key Value或其他数据存储
• Cron作业、后台工作程序或私有服务
• 您想要可复制的IaC或将render.yaml提交到仓库
• 需要一致配置的单仓库或多环境设置

如果不确定，询问快速澄清问题，但为安全起见默认使用蓝图。对于单服务，强烈推荐通过MCP直接创建，并在需要时指导MCP设置。

前提条件检查

开始部署时，按顺序验证这些要求：

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

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

git remote -v

• 如果无远程存在，停止并询问用户创建/推送远程或切换到Docker镜像部署。

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

MCP工具提供最佳体验。尝试检查是否可用：

list_services()

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

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

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

指导用户完成以下步骤：

1. 获取Render API密钥：

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

2. 添加到~/.cursor/mcp.json（替换<YOUR_API_KEY>）：

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

3. 重启Cursor，然后重试list_services()。

Claude Code

指导用户完成以下步骤：

1. 获取Render API密钥：

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

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

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

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

其他工具

如果用户使用其他AI应用，引导他们到该工具的Render MCP文档以获取设置步骤和安装方法。

工作空间选择

配置MCP后，让用户设置活动的Render工作空间，提示如：

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

5. 检查认证（仅CLI回退）

如果MCP不可用，使用CLI并验证您可以访问账户：

# 检查用户是否登录（使用-o json进行非交互模式）
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：

render workspace current -o json

列出可用工作空间：

list_workspaces()

如果用户需要切换工作空间，必须通过Dashboard或CLI（render workspace set）完成。

一旦前提条件满足，继续部署工作流。

---

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

蓝图工作流

步骤1：分析代码库

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

步骤2：生成render.yaml

创建render.yaml蓝图文件，遵循蓝图规范。

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

关键点：

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

基本结构：

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：按cron计划运行的预定任务
• static：静态站点（通过CDN服务的HTML/CSS/JS）
• pserv：私有服务（仅内部，在同一账户内）

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

步骤2.5：立即后续步骤（始终提供）

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

1. 认证（CLI）：运行render whoami -o json（如果未登录，运行render login或设置RENDER_API_KEY）
2. 验证（推荐）：运行render blueprints validate
   • 如果CLI未安装，提供安装命令。
3. 提交+推送：git add render.yaml && git commit -m "添加Render部署配置" && git push origin main
4. 打开Dashboard：使用蓝图深链接，如果提示，完成Git OAuth
5. 填写秘密：设置标记为sync: false的环境变量
6. 部署：点击“应用”并监控部署

步骤3：验证配置

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

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

在继续前修复任何验证错误。常见问题：

• 缺失必需字段（name、type、runtime）
• 无效的运行时值
• 不正确的YAML语法
• 无效的环境变量引用

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

步骤4：提交和推送

重要： 部署前必须将render.yaml文件合并到仓库中。

确保render.yaml文件已提交并推送到Git远程：

git add render.yaml
git commit -m "添加Render部署配置"
git push origin main

如果尚无Git远程，停止并指导用户创建GitHub/GitLab/Bitbucket仓库，添加为origin，并在继续前推送。

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

继续下一步前，验证文件在远程仓库中。

步骤5：生成深链接

获取Git仓库URL：

git remote get-url origin

这将返回Git提供商的URL。如果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=<仓库URL>

示例：

https://dashboard.render.com/blueprint/new?repo=https://github.com/用户名/仓库名称

步骤6：指导用户

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

向用户提供深链接及以下说明：

1. 验证render.yaml已合并 - 确认文件存在于GitHub/GitLab/Bitbucket上的仓库中
2. 点击深链接打开Render Dashboard
3. 如果提示，完成Git提供商OAuth
4. 命名蓝图（或使用render.yaml中的默认值）
5. 填写秘密环境变量（标记为sync: false）
6. 检查服务和数据库配置
7. 点击“应用”部署

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

步骤7：验证部署

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

通过MCP检查部署状态：

list_deploys(serviceId: "<服务ID>", limit: 1)

查找status: "live"以确认成功部署。

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

list_logs(resource: ["<服务ID>"], level: ["error"], limit: 20)

检查服务健康指标：

get_metrics(
  resourceId: "<服务ID>",
  metricTypes: ["http_request_count", "cpu_usage", "memory_usage"]
)

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

---

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

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

何时使用直接创建

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

直接创建的前提条件

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

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

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

如果无远程存在，停止并询问用户创建/推送远程或切换到Docker镜像部署。

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

直接创建工作流

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

步骤1：分析代码库

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

步骤2：通过MCP创建资源

创建服务（web或静态）及任何所需数据库或键值存储。参见references/direct-creation.md。

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

步骤3：配置环境变量

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

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

步骤4：验证部署

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

---

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

---

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

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

1. 确认最新部署为live并正在服务流量
2. 访问健康端点（或根）并验证200响应
3. 扫描最近的错误日志以查找明显故障特征
4. 验证所需环境变量和端口绑定（0.0.0.0:$PORT）

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

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

故障排除

升级网络访问

如果部署因网络问题失败（超时、DNS错误、连接重置），使用升级权限重新运行部署（使用sandbox_permissions=require_escalated）。当沙盒网络阻止出站请求时，部署需要升级网络访问。

向用户提供示例指导：

部署需要升级网络访问以部署到Render。我可以使用升级权限重新运行命令—您希望我继续吗？

可选：如果需要更深入的诊断（指标/数据库检查/错误目录），建议安装render-debug技能。核心部署流程不需要它。