部署到 Cloudflare

使用 Cloudflare Workers、Containers、Queues、R2 与 Postgres 部署 Open Connector。

Cloudflare 是当前维护的生产部署目标。自托管是在自己的 Cloudflare 账户中运行这套拓扑，并管理自己的数据库、密钥和 OAuth 应用。API 的 Hono 应用直接运行在 Cloudflare Worker 中；Container binding 仅保留用于明确规划的紧急恢复。领域包仍与具体部署平台分离。

部署组件

应用	运行时	职责
`apps/server`	Worker + Hyperdrive	API、OAuth、MCP 与工具调用
`apps/app`	Worker Static Assets	控制台 SPA
`apps/web`	Worker + Static Assets	营销站
`apps/fumadocs`	Worker + Static Assets	文档站
`apps/trigger-worker`	Queue Consumer + Cron Worker	供应商事件、投递与持久恢复
`apps/worker`	Cron Worker	每小时的计费对账

Postgres 保存平台状态，托管生产环境使用 Neon；Worker 通过 Hyperdrive 连接数据库。 R2 通过 S3 兼容适配器存储 Blob。Server Dockerfile 构建保留的紧急恢复镜像，不代表另一个 Compose 生产服务。

1. 配置自己的账户

准备 Node.js 22+、pnpm、Docker 和仓库依赖，然后确认 Wrangler 账户：

pnpm install
pnpm --filter server exec wrangler login
pnpm --filter server exec wrangler whoami

逐一检查各应用的 wrangler.jsonc，将仓库中的生产账户 ID、域名替换为自己的值。创建所引用的 Queue、死信队列、Hyperdrive 配置与 R2 Bucket，并替换名称、ID 和跨 Worker 绑定名称。配置引用的日志与 tracing 导出目标，或按自己的可观测性方案移除这些目标引用。仓库目前不提供一键创建全部基础设施的工具。

API origin、CORS、OAuth 回调和前端 .env.production 必须一致。 VITE_* 会编译进公开站点资源；VITE_MANAGED_OAUTH_PROVIDERS 只应列出 API 实际配置的供应商。

2. 配置运行时密钥

各应用在 Wrangler 配置的 secrets.required 中声明必填密钥，完整配置以环境变量校验 schema 为准。例如，以下命令会提示输入密钥，不需要把值写进源码：

pnpm --filter server exec wrangler secret put DATABASE_URL --env production
pnpm --filter server exec wrangler secret put BETTER_AUTH_SECRET --env production
pnpm --filter server exec wrangler secret put CONNECTOR_ENCRYPTION_KEY --env production
pnpm --filter server exec wrangler secret put SERVER_DEPLOYMENT_CONTROL_TOKEN --env production

还需配置其余必填的 OTLP、Queue 和 R2 凭证，以及部署需要的 OAuth、计费密钥。密钥按 Worker 隔离；Server 的密钥不会自动配置到 Trigger 或计费 Worker。 SERVER_DEPLOYMENT_CONTROL_TOKEN 至少 32 个字符；Server Worker 与 GitHub production environment 必须保存同一个随机值。

请安全备份加密密钥。没有重新加密已有凭证就替换 CONNECTOR_ENCRYPTION_KEY，会让现有连接无法读取。

3. 准备数据库与目录

通过受保护的环境变量提供生产 DATABASE_URL 后执行：

pnpm db:migrate
pnpm tools:publish-catalog

确认目标是生产数据库，避免本地 .env 误选开发库。Server 启动不会自动发布 Runtime Catalog。使用计费功能时，在初始化或修改套餐后，通过目标数据库与 Stripe 凭证执行 pnpm --filter worker provision；这是运维命令，不是第二套定时运行时。

4. 校验并发布

从干净的源码检出执行：

pnpm deploy:cloudflare:dry-run
pnpm deploy:cloudflare

根命令会严格检查配置并发布全部六个应用。Server 先上传 0% 流量的 candidate，执行配置 reconciliation 和待处理的应用数据 migration，再通过只读 readiness 检查后推广准确的源码 SHA；准确版本 smoke 检查失败时会恢复旧版本流量。普通本地发布不会自动迁移数据库 schema，有 schema 变更时先完成迁移。

GitHub Release 工作流通过 Deploy (Cloudflare) 发布准确的 release commit。在 GitHub production environment 中配置：

Secret	用途
`CLOUDFLARE_API_TOKEN`	发布至配置的 Cloudflare 账户
`DATABASE_URL`	发布前迁移与生产运行时相同的数据库
`SERVER_DEPLOYMENT_CONTROL_TOKEN`	授权准备 0% 流量的 Server candidate

运行时密钥保存在 Cloudflare。CI 使用应用各自的 .env.production 公开构建配置，不再读取 AWS 配置存储。如果 Server Worker 尚无控制密钥 binding，工作流会在迁移后、上传前从受保护的 GitHub 值安装；已有 binding 不会被覆盖。

5. 验证与恢复

检查 API 根路径返回 200 OK，且 x-open-connector-release 与发布源码一致。运行营销站和文档站 smoke 检查，验证控制台、一次经认证的工具调用、供应商入口以及 Queue/Cron 处理，并查看日志、trace 和指标。

Server 推广后会把上一个不可变 Worker 版本保留在 0% 流量。准确版本 smoke 检查失败时协调器会自动恢复该版本；后续故障也可由运维人员手动恢复。回滚代码前确认数据库兼容性；部署不会撤销迁移或供应商侧操作。

当前维护流程不包含 AWS/OpenTofu 配置或另一套生产调度器。旧安装留下的云资源需要单独盘点后再退役。