很多人用 AI 把网站做出来，跑在 localhost 时会很兴奋。
然后一问：“怎么让别人也能打开？”事情突然就变成了 Cloudflare、DNS、Worker、数据库、密钥、命令行。
这串词一出来，人很容易又停住。
我这次把一个工具站从本地部署到 Cloudflare，过程里一直让 Codex 配合。最后发现真正难的不是 pnpm exec wrangler deploy 这条命令，而是你得知道它到底要把什么发到哪里，发完以后又该怎么验。
说白了，AI 不是替你按一下发布按钮就完了。你负责账号、权限和最终确认；Codex 负责读项目、写配置、跑构建、看报错、做验收。
下面把我这次怎么做的写清楚。
先别急着部署，先看项目到底是什么
我这个站不是纯静态网页。它有：
- 前端页面；
- 注册登录；
- API；
- 用户数据；
- 以后还会接支付、积分和 AI 能力。
所以我选的是：
前端 + 服务端：Cloudflare Workers
数据库：Cloudflare D1
域名和 DNS：Cloudflare
部署命令：WranglerWorker 可以理解成 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": "<your-d1-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
看到这类回显后，不要只看 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 跑它给好的命令，地基不用我从零打。
如果你也想自己搞个工具站，又不想从登录和域名这种地基开始啃，可以去看看 ShipAny：https://shipany.ai/。
我这边有一个优惠码：XIAOLUX，想试的话可以用上。