跳到主要内容
AI教程

使用 GoLive 部署代理构建的应用：托管、数据库、域名、身份验证、电子邮件和支付

了解如何安装 GoLive、通过编码代理启动应用、在提供商变更发生前进行审核、验证最终部署、检测偏差、创建所有权文档，并安全地拆除资源。本教程还介绍 Alpha 版本中经过测试的提供商、实验性功能以及重要限制。

AI我搜编辑部阅读约 16 分钟
使用 GoLive 部署代理构建的应用：托管、数据库、域名、身份验证、电子邮件和支付

GoLive 的功能

GoLive 是一个开源 Agent Skill，可将由代理构建的应用从源代码部署到真实基础设施。它会检查代码仓库，检测所需服务，提出针对特定提供商的变更方案，征求批准，通过你自己的账户应用这些变更，并验证其能够观察到的结果。

该项目旨在弥合应用生成与实际为用户运营之间的差距。根据应用的不同，可能涉及托管、数据库、环境变量、身份验证、自定义域名、事务性邮件和测试模式支付。

GoLive 不要求 GoLive 账户或托管式 GoLive 后端，也不包含产品遥测。提供商访问权限始终绑定到你自己的账户和登录信息。

Alpha 警告：当前版本为 0.1.0-alpha.3。部分流程已使用一次性实时资源进行验证，但项目路线图中的更广泛检查清单并不意味着每种上线流程都已完成。

主要功能

  • 代码仓库检测：GoLive 会检查应用，并识别其似乎需要的基础设施和服务。
  • 保留现有提供商：它会保留应用已在使用的提供商，而不是自动替换它们。
  • 先批准后执行：在更改提供商之前，会展示目标账户、资源详情、变更内容和可用的费用信息。
  • 人工交接：注册、浏览器登录、身份验证、购买、收件箱访问及其他仅限人工执行的操作仍由你控制。
  • 验证：GoLive 会检查可观察的结果，并明确报告任何受阻或未验证的事项。
  • 生命周期记录：它会记录已创建的资源，支持按需运行 golive status 漂移检查，并可生成交接产物。
  • 受控拆除：运行期间创建的资源可以通过单独规划并批准的拆除流程移除。
  • 引导式提供商支持：对于没有内置适配器的提供商，GoLive 可以通过官方 CLI、官方 MCP 集成、API 或控制面板说明，尽力执行流程。

当前 Alpha 范围

目前最成熟的 Alpha 路径涵盖两个托管提供商和两个数据库提供商：

  • 托管：Vercel 和 Netlify。
  • 数据库：Supabase 和 Neon。
  • 自定义域名 DNS：Porkbun 和 GoDaddy 已与 Vercel 完成实时测试的记录写入流程。
  • 事务性邮件：Resend 域名设置、DNS 验证和真实应用发送均已完成测试。
  • 支付：Stripe 测试模式密钥、Webhook 注册、签名事件验证以及真实测试卡支付均已完成验证。
  • 身份验证：Supabase Auth 策略配置和可选择加入的注册流程已有实时证据。密码恢复和账户隔离已实现，并通过模拟测试覆盖，但尚未完成同等程度的实时验证。

已完成实时测试的应用组合是 Vercel 与 Supabase，以及 Netlify 与 Neon。其他交叉组合可能只有模拟测试覆盖，尚未达到相同级别的实时验证。Cloudflare DNS 仍处于实验阶段，尚未成为经过验证的 Alpha 路径。

前置要求

安装 GoLive 前，请准备以下内容：

  • Node.js 20 或更高版本。
  • npm 和 npx。
  • 通过 GitHub 和 Skills CLI 安装渠道安装时需要 Git。
  • 能够加载技能并运行命令的编码代理。

已使用 Codex 和 Claude Code 检查安装流程。其他代理客户端目前尚未验证。

使用 Skills CLI 安装 GoLive

若要为所有项目安装一次技能，请从任意目录运行以下命令：

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

交互式安装程序会要求你选择代理。使用方向键移动，按 Space 选择，再按 Enter 确认。

为 Codex 进行非交互式安装

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent codex --yes

为 Claude Code 进行非交互式安装

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent claude-code --yes

若要安装到项目本地，请从项目代码仓库运行命令，并省略 --global。安装过程会复制技能说明、提供商参考资料和预构建运行时，但不会连接提供商账户或部署应用。

从 npm 安装

同一版本也以 golive npm 包的形式提供。此渠道无需 Git 或 Skills CLI 即可安装技能。

Codex 安装

npx golive@alpha install --agent codex

Claude Code 安装

npx golive@alpha install --agent claude

添加 --global 可将其安装到主目录，而不是当前项目：

npx golive@alpha install --agent codex --global

npm 安装程序不会覆盖现有目标，也不会连接提供商账户。两个安装渠道包含相同的项目版本。

npm 包还提供单独的终端操作：

npx golive@alpha help
npx golive@alpha version
npx golive@alpha detect
npx golive@alpha menu
npx golive@alpha plan
npx golive@alpha verify
npx golive@alpha handoff

终端 apply 操作需要已批准的计划 ID 和明确确认。这些命令执行的是单独的操作，不能替代完整的对话式技能工作流。

在编码代理中启动 GoLive

在编码代理中打开应用程序仓库。如果新安装的技能没有显示，请重新加载技能或启动新的代理会话。

在 Codex 中，在聊天里调用该技能：

$golive Help me take this app live.

在 Claude Code 中，使用：

/golive Help me take this app live.

你也可以用自然语言提供更具体的指令：

Use the golive skill to take this app live. Keep the providers it already uses.
Show me the destination accounts and plan before changing anything.
Use test resources for now.

golive skill 不是终端命令。安装 Skills CLI 不会添加全局 golive 可执行文件。编码代理会运行已安装技能目录中包含的 CLI。npm 软件包则通过 npx golive@alpha 单独提供命令。

了解部署工作流

典型运行会遵循受控流程，而不是立即创建资源。

  1. 检查：GoLive 分析仓库，检测现有的提供商集成和缺失的基础设施。
  2. 澄清：当无法从应用程序中确定答案时，代理会询问应使用哪个提供商或账户。
  3. 身份验证：你在单独的终端或浏览器中完成提供商登录步骤。
  4. 确认目标：GoLive 检查已连接的账户、团队或组织，以便你确认资源将在哪里创建。
  5. 制定计划：代理会展示资源名称、可用时的 ID、设置、变更以及相关成本信息。
  6. 批准：在你批准计划之前，不应应用任何提供商变更。
  7. 应用：GoLive 配置并连接已批准的资源。
  8. 验证：代理检查部署、集成和应用程序可观察到的行为。
  9. 记录：创建的资源和验证结果会被保存，以便稍后进行状态检查、交接或拆除。

如果计划在批准后发生变化，GoLive 会要求再次批准。某些工作（例如附加身份验证或域名）可能会在初始部署之后通过后续计划完成。

示例：部署已使用 Supabase 的应用

假设仓库中已经包含 Supabase 集成，但尚未选择托管提供商。请从以下指令开始：

$golive Take this app live using test resources. Keep its existing Supabase integration.

GoLive 可能会询问你是否要使用 Vercel、Netlify 或其他提供商。选择 Vercel 会采用 alpha 版本经过实时测试的 Vercel 和 Supabase 路径。随后，它会确定使用现有的 Supabase 项目，还是创建一个新的临时测试项目。

系统可能会要求你单独进行身份验证：

vercel login
supabase login

登录后，让代理识别已连接的 Vercel 团队和 Supabase 组织。在批准计划前，请仔细检查这些目标。

已批准的计划可能包括创建托管项目、创建或选择数据库项目、传输所需的环境变量、部署应用程序以及验证结果。完成后，GoLive 会报告线上 URL、验证证据以及仍未完成的检查项。

在设置期间保护凭据

除非提供商工作流明确且安全地要求使用特定机制，否则不要将提供商密钥粘贴到代理聊天中。在 macOS 上，GoLive 可以使用原生隐藏输入对话框来获取所需的 API 密钥。对话框会说明密钥的用途以及存储位置。该值会直接写入本地凭据文件，而不会显示在聊天或命令输出中。

其他平台会使用你的编辑器作为备用方式。请继续检查系统请求的内容，并尽可能使用权限范围适当的测试凭据，同时确认目标账户正确无误。

验证不应仅限于首页

成功的部署 URL 只是开始。验证应符合应用程序的实际行为。根据所选路径，GoLive 可以检查以下方面：

  • 托管部署是否完成并提供应用程序服务。
  • 数据库环境变量是否已接入部署。
  • 应用程序是否可以连接到其数据库。
  • 受支持路径上的身份验证 CRUD 或会话隔离检查是否成功。
  • 自定义域名是否具备所需的 DNS 记录、所有权证明和 HTTPS 响应。
  • Resend 是否验证了发件域名，以及应用程序是否可以执行真实发送。
  • Stripe 测试付款是否到达经过签名验证的 webhook 事件。

GoLive 无法观察到的任何内容都应明确标记为未验证。例如，收件箱投递情况由人工确认，因为 GoLive 不会检查收件人的收件箱。

检查部署偏差

GoLive 实现了按需运行的 golive status 工作流，用于比较记录的预期状态与可观察到的提供商状态。这是偏差检查，不是持续监控或告警。

golive status

使用 npm 安装时，请查看软件包帮助，了解已安装 alpha 版本中提供的终端操作：

npx golive@alpha help

在手动更改服务商配置后、将项目交接给其他负责人之前，或规划拆除操作之前，执行状态检查。将无法访问或无法验证的资源视为需要调查的问题，而不要默认它们处于正常状态。

创建交接记录

交接工作流会为 GoLive 已知的基础设施创建所有权文档。README 说明，golive handoff --write 已在一次仅使用 Vercel 的一次性测试环境中运行，并且已审核其生成的构件，以避免包含类似凭据的值。

golive handoff --write

在将项目移交给客户或其他工程团队之前，交接记录很有用。审核生成的文档及其 JSON 对应文件，确认每个服务商账户和资源所有者，并通过适当的安全渠道单独传递密钥。

安全拆除一次性资源

当不再需要测试部署时，请要求该技能规划删除操作：

$golive Plan teardown for the resources created by this project. Show me everything that will be removed before deleting anything.

拆除流程受到审批控制。实时验证包括一个一次性 Netlify 项目：在没有 --confirm-destroy 的情况下阻止删除，随后在明确确认后完成移除。经过测试的清理还包括 DNS 记录、Resend 发送密钥，以及由 GoLive 创建的 Stripe 测试模式端点。

务必检查拆除计划中的共享数据库、域名、DNS 区域、电子邮件配置、支付端点，以及可能已包含重要数据的项目。GoLive 能够移除某项资源，并不意味着移除该资源就是合适的做法。

高级提示

早期实验优先使用经过测试的组合

根据目前最有力的证据，建议从 Vercel 与 Supabase，或 Netlify 与 Neon 开始。其他组合可能有效，但模拟覆盖并不等同于已完成的实时运行。

使用明确的测试资源

评估 alpha 版本时，请要求使用一次性或测试资源。Stripe 支持经过了测试模式的专门验证；README 并未声称其已具备同等的实时模式支付能力、退款处理、订阅处理或权益验证能力。

谨慎声明可选的 Supabase Auth 流程

Supabase Auth 策略设置可以通过经过批准的计划管理注册、电子邮件确认、最小密码长度、邮件发送器设置、站点 URL 和重定向允许列表。可选的注册流程可通过以下配置启用：

auth:
  e2e: true

密码恢复和账户隔离也有配置标志：

auth:
  recovery: true
  isolation: true
  identityPath: /your-identity-route
  isolationPath: /your-rows-route

根据 alpha 文档，后两种流程已实现并由模拟测试覆盖，但尚未完成实时验证。隔离功能要求应用路由具备预期行为；缺少路由或路由不适用时，会生成交接任务，而不是错误地判定为通过。

将确认标志视为安全闸门

可能影响实时系统的操作使用显式闸门。项目所述示例包括用于 DNS 写入的 --confirm-dns、用于某些真实账户或实时值操作的 --confirm-live，以及用于拆除的 --confirm-destroy。在审核确切计划和目标之前，不要绕过这些检查。

区分内置适配器与引导式服务商

对于不受支持的服务商，GoLive 会先检查官方 CLI、官方 MCP 集成或 API，然后才回退到控制台引导。这仍属于尽力而为的辅助。完成度和验证深度不作保证，因此当自动化无法继续时，应预期会得到明确的阻塞原因和下一步操作。

谨慎试用发布功能

项目包含已实现但尚未经过实时验证的预览、发布检查、晋级和回滚能力。预览行为通过 golive.yaml 中的配置选择启用：

release:
  preview: true

晋级和回滚使用其他可选启用值：

release:
  preview: true
  promote: true
  rollback: true

由于这些能力尚未经过实时验证，只能在受控的测试环境中使用，并检查每个生成的计划。成功的部署可以将服务商的部署标识记录到 .golive/state.json 中，使后续能力能够引用特定部署，而不是含义不明确的 URL。

重要限制

  • 该项目仍处于早期 alpha 阶段。
  • 并非所有框架或新用户账户设置都经过验证。
  • 专用后端服务器、容器、对象存储、监控、分析、后台任务，以及其他若干上线类别仍属于路线图项目。
  • 不包含持续监控和告警；状态检查按需执行。
  • Cloudflare DNS 属于实验功能，而不是经过验证的 alpha 路径。
  • Supabase 密码恢复和账户隔离已经实现，但尚未完成实时验证。
  • 用于 Supabase Auth 的 Resend 自定义 SMTP 已实现并由模拟测试覆盖，但尚未经过实时验证。
  • 与内置适配器相比，引导式服务商无法获得相同的完成度或验证保证。

结论

GoLive 提供了一种由审批驱动的方式，将代理构建的应用部署到由你拥有的基础设施上。从一次性资源开始，优先选择经过实时测试的服务商组合，在批准更改前验证目标账户，并审核每个未解决的问题。部署得到验证后，使用状态检查和交接文档保留运维上下文；当不再需要测试资源时，再使用受闸门控制的拆除流程。