Codex 第 28 课：我让 Codex 把网站部署到了 Cloudflare：一个工具站上线的真实记录

很多人用 AI 把网站做出来，跑在 localhost 时会很兴奋。

然后一问：“怎么让别人也能打开？”事情突然就变成了 Cloudflare、DNS、Worker、数据库、密钥、命令行。

这串词一出来，人很容易又停住。

我这次把一个工具站从本地部署到 Cloudflare，过程里一直让 Codex 配合。最后发现真正难的不是 pnpm exec wrangler deploy 这条命令，而是你得知道它到底要把什么发到哪里，发完以后又该怎么验。

说白了，AI 不是替你按一下发布按钮就完了。你负责账号、权限和最终确认；Codex 负责读项目、写配置、跑构建、看报错、做验收。

下面把我这次怎么做的写清楚。

00 先别急着部署，先看项目到底是什么

我这个站不是纯静态网页。它有：

• 前端页面；
• 注册登录；
• API；
• 用户数据；
• 以后还会接支付、积分和 AI 能力。

所以我选的是：

前端 + 服务端：Cloudflare Workers 数据库：Cloudflare D1 域名和 DNS：Cloudflare 部署命令：Wrangler

Worker 可以理解成 Cloudflare 的服务端运行环境，D1 是它配套的 SQLite 风格数据库，Wrangler 是本机把代码、配置和密钥发到 Cloudflare 的命令行工具。

不是所有项目都必须这么配。纯展示页可以更简单；但一旦要登录、存项目、做配额，这套组合对小工具站挺顺手。

01 你自己要做的，其实不多

如果你准备让 Codex 帮你部署，自己需要参与的主要是四类事情：

• 注册并登录 Cloudflare；
• 把自己的域名添加到 Cloudflare；
• 在浏览器里确认授权、创建数据库这类真实外部动作；
• 保管密钥、验证码和账单信息。

账号密码、短信码、API Token 这类东西不要发给 AI。正确分工是：你在浏览器完成登录，Codex 使用已登录的会话或本机 Wrangler 完成后续配置；到了改 DNS、发版、删库这种动作，再由你确认。

02 先让 Codex 看懂 Wrangler 配置

Wrangler 会读取 wrangler.jsonc 或 wrangler.toml，知道该部署哪个 Worker、绑定哪个 D1 数据库、哪些是公开环境变量。

下面是一个删减后的示意：

{ “name”: “my-product”, “main”: “.output/server/index.mjs”, “compatibility_date”: “2026-07-18”, “d1_databases”: [ { “binding”: “DB”, “database_name”: “my-product-production”, “database_id”: "" } ], “vars”: { “DATABASE_PROVIDER”: “d1”, “VITE_APP_URL”: “https://app.example.com”, “AUTH_URL”: “https://app.example.com” } }

这里有个原则很重要：

• vars 放可以公开的配置，比如站点地址、产品名；
• secret 放 API Key、认证密钥、支付密钥；
• database_id、域名、账户 ID 即使不算密码，也别随手贴进文章、截图或公开仓库。

Cloudflare 官方文档对 Worker 配置和 D1 binding 的说明在这里：Wrangler Configuration。

03 本地没跑通，先别谈上线

不要一上来就部署。先让 Codex 看项目的 package.json、构建脚本和 Worker 配置，然后在项目根目录跑生产构建。

我这个项目的脚本是：

pnpm install pnpm cf:build

其中 cf:build 会把 Web 项目打包成 Cloudflare Worker 能运行的输出，最后生成 .output 目录。

实际使用 Codex 时，我会这样说：

请先读取项目的部署配置和 package.json，确认 Cloudflare 构建命令。 运行构建；如果失败，定位根因后修复。不要改动无关代码。 构建通过后，再告诉我准备部署什么。

这句话的重点不是“让它跑命令”，而是让它先理解项目。不同框架的构建产物不一样，Next、Astro、Vite、TanStack Start 都不能盲套同一条命令。

构建通过时先检查两件事：终端没有 TypeScript 或打包错误；项目确实产出了部署配置指向的入口文件。构建失败时，把完整错误交给 Codex，让它先解释根因和拟修改文件，再修复重跑。不要为了“让命令绿”跳过错误。

04 真正发布，就是这一条命令

构建通过后，最直接的部署命令是：

pnpm exec wrangler deploy

第一次执行时，如果本机没有 Cloudflare 登录状态，Wrangler 会要求你登录授权。授权完成后，它会上传 Worker 代码和静态资源，再打印出一个 Workers 地址。域名已经绑定好的话，也会显示自定义域名。

如果项目已经把构建和部署串成脚本，也可以直接：

pnpm cf:deploy

不过我个人更喜欢先单独跑 pnpm cf:build，确认构建没问题，再手动执行 deploy。对刚上线的产品来说，多一步确认不亏。

Cloudflare 推荐在项目内安装 Wrangler，再通过包管理器运行，而不是把它当成全局黑盒命令。Wrangler Commands

03_Output/01_内容母版/01_长文/assets/2026-07-18_cloudflare-worker-deploy-output-redacted.png

看到这类回显后，不要只看 Uploaded。按顺序确认：

• env.DB 是否显示为 D1 Database，说明生产数据库 binding 已挂上；
• 是否打印了 Workers.dev 地址，证明 Worker 已发布；
• 是否打印了自己的自定义域名；
• 记下 Current Version ID，出问题时可以在 Cloudflare Dashboard 对照部署历史。

05 一个很容易漏的坑：数据库不是自动好的

Worker 部署成功，只代表代码上去了。你还要确认它连的是生产 D1，不是本地 SQLite。

数据库表结构变化时，要先把迁移应用到远程数据库。通用形式是：

pnpm exec wrangler d1 migrations apply my-product-production —remote

如果项目用 Drizzle 或自己的 SQL 迁移脚本，就按项目既有的迁移方式来，不要同时混两套。最怕的是本地表更新了，线上没更新，结果用户一注册就 500。

Cloudflare D1 的迁移文件是 SQL 文件，远程执行一定要带上 —remote；不带它通常只改本地开发数据库。Cloudflare D1 Migrations

06 密钥可以让 Codex 帮你配，但别发给它

API Key 不写进代码。让 Codex 执行下面的命令，终端提示输入时你自己粘贴即可：

pnpm exec wrangler secret put RESEND_API_KEY

或者是：

pnpm exec wrangler secret put AUTH_SECRET pnpm exec wrangler secret put STRIPE_SECRET_KEY

这里的边界很清楚：Codex 可以把命令准备好、检查是否成功、继续部署；但 Key 的正文不要贴到对话框里。密钥上传后，再重新 deploy 或确认 Secret Change 已产生新版本。

07 页面打开了，不等于上线完成

我不会看到“Deployment successful”就结束。至少会过四层：

• 网页能打开 ：首页、核心工具页、登录页返回正常；
• 接口能返回 ：比如公开配置接口、用户信息接口；
• 数据库真能写 ：注册、保存项目、读取项目各做一次；
• 真实第三方链路能走 ：例如注册邮件、支付回调、文件上传。

给 Codex 的验收指令可以更具体一点：

部署后请检查正式域名的首页、登录页和核心工具页。 再调用不含敏感信息的公开接口确认配置已生效。 最后给出已验证项、未验证项和风险，不要把“构建通过”写成“功能已验证”。

这句话很有用。因为“没报错”和“用户能用”是两件事。上次我接邮箱验证，域名状态已经绿了，邮件也能收到，但跨设备点链接后电脑端没有正确继续登录。只有真的拿手机和电脑各走一遍，才发现这个产品问题。

08 出问题时，别急着乱猜

页面 404 或打开的是旧内容

先看本次部署是否真的指向目标 Worker，再看自定义域名是否绑定到这个 Worker。很多时候不是代码没更新，是部署到了错误的项目或错误环境。

数据库报错

确认 Worker 的 D1 binding 名称和代码里使用的 binding 一致；再确认迁移已应用到远程库。

密钥相关报错

确认 Secret 名称一字不差。尤其是生产代码从 process.env.RESEND_API_KEY 读取时，Cloudflare 中也必须是同名 Secret。

前端显示已配置，服务端却不工作

这通常是“前端读到公开变量，服务端没读到 Secret”。认证、支付、发信这些关键逻辑一定要在服务端用完整配置验一次。

09 我现在是怎么用 Codex 做部署的

我不会把它当“帮我一键上线的网站托管员”。更像是一个能读代码、能跑终端、能看构建日志、能在我登录好 Cloudflare 后继续干活的工程搭子。

我负责把账号、权限、域名这些现实世界的门打开；它负责把项目里的配置、代码、命令、验证串起来。

这其实是普通人用 AI 做产品最舒服的边界：命令你不需要背，但每一步在改什么、风险在哪、成功长什么样，你最好知道。

当 pnpm exec wrangler deploy 不再是一句看不懂的咒语，部署这件事就没那么吓人了。

一张可执行清单

第一次部署时，建议开着这份清单逐项完成：

• Cloudflare 账号已登录，域名已添加并完成 DNS 托管；
• 项目根目录存在 wrangler.jsonc 或 wrangler.toml；
• Worker 名称、D1 binding、正式站点 URL 已核对；
• 本地执行 pnpm install、pnpm cf:build 通过；
• 需要的数据库迁移已使用 —remote 应用到生产 D1；
• API Key、认证密钥等已通过 wrangler secret put 写入，不在 Git；
• 执行 pnpm exec wrangler deploy 并记录版本 ID；
• 用无痕窗口访问正式域名的首页、核心页和登录页；
• 做一条真实写入验证，例如新建账号或保存一个项目；
• 检查 Cloudflare Worker 日志和第三方服务日志。

这张清单全部打钩，才可以放心把链接发给别人。

官方资料 ：

• Cloudflare Wrangler 配置
• Cloudflare Workers Secrets
• Cloudflare D1 Migrations

顺手说一个。

前面整篇都在讲「让 Codex 帮我部署到 Cloudflare」。其实我这个工具站，就是用 ShipAny 的 TanStack 模板起的。

ShipAny 是给 Coding Agent 用的开发框架，注册登录、支付订阅、积分、i18n、文件存储这些做工具站要反复造的轮子，它都先搭好了。我选的是 TanStack 这个版本，底层是 TanStack Start。

它对我最大的好处：模板里直接带 /deploy-cloudflare 这种 skill。所以前面那句 pnpm exec wrangler deploy，在我这里就是让 Codex 跑它给好的命令，地基不用我从零打。

原文信息

作者：@xiaoluv12o 原文地址：https://x.com/xiaoluv12o/status/2078676787173965839