部署指南

本指南仅覆盖核心交付的部署：

前端：apps/web（用户站）、apps/admin（管理后台）
后端：node1-auth ~ node10-ai（10 个 Worker）

增值服务（如 AI 提供商服务）不包含在内。详见增值服务。

选择你的路径

文档侧栏里，命令行与 Dev Console 相关章节都收在 部署指南 下。请先选定下面其中一条路径，再只按该路径的顺序阅读对应页面。

ZShip 支持两种方式搭建本地开发环境并部署到 Cloudflare：

纯命令行（CLI）部署

适合以下情况：

你使用的是基础版/精简版，没有带 Dev Console
你更喜欢命令行，或需要在 CI/自动化中脚本化部署
你希望完全掌控每一步

你需要在终端中手动执行 pnpm install、wrangler d1 create、wrangler deploy 等命令。

从这里开始： CLI：开始之前

图形控制台（Dev Console）部署

适合以下情况：

你使用的是完整 ZShip 模板，带有 Dev Console
你更喜欢用图形界面完成本地启动和云端部署
你希望少记命令、少漏步骤

你只需执行一次 pnpm dev:console，然后在浏览器 UI 中完成环境检查、数据库迁移、服务启动和 Cloudflare 部署。

从这里开始： 先认识 Dev Console

请严格按你选择的路径顺序阅读，不要跳步。

获取源码的两种方式

用户拿到这套模板，通常有两种做法：

方式 1：GitHub Fork

意思是：

用户直接在 GitHub 上把官方仓库 fork 到自己的账号或组织下面

优点：

还保留和官方仓库的上游关系
后续官方模板更新时，用户更容易手动同步
更适合你们这种”官方持续迭代模板，用户基于模板二次开发”的场景

缺点：

不会自动更新
官方仓库有新提交后，用户仍然需要自己手动同步
如果用户改动很多，后续同步时可能有冲突

方式 2：直接复制代码后自己新建仓库

意思是：

用户下载官方代码
然后自己重新创建一个全新的 Git 仓库

优点：

仓库历史更干净
对有些客户来说，心理上更像”这已经是我自己的项目”

缺点：

和官方仓库没有上游关系
后续官方模板更新时，用户不会有现成的同步入口
想吃到官方更新，通常只能手动比对、手动拷贝，维护成本更高

这套文档覆盖什么

本指南覆盖这套模板的 Cloudflare 上线路径：

backend/node1-auth-service
backend/node2-support-service
backend/node3-pay-service
backend/node4-notify-service
backend/node5-blog-service
backend/node6-cdn-service
backend/node7-site-service
backend/node8-prompt-service
backend/node9-checkin-service
backend/node10-ai-service
apps/web
apps/admin

分方式阅读顺序

若选命令行（CLI）

若选 Dev Console

排障与线上工具索引

主题	文档
上线自检、Observability、CDN/R2、邮件与 Webhook、常见报错	上线检查和常见报错
Dev Console 与 Cloudflare 控制台分工	先认识 Dev Console §4
密钥与仓库安全	注意事项 — 安全与密钥