一人公司部署方案：Cloudflare Pages、Workers、Vercel、Railway 怎么选

部署面板里有四个服务：blog、tool-api、dashboard、worker-daily-report。前两个跑在 Cloudflare，第三个在 Vercel，最后一个还在 Railway 和 Workers 之间犹豫。它们卡的地方不一样：blog 遇到了构建次数上限，tool-api 超了 Workers 的 CPU 限制，dashboard 收到 Vercel 账单预警，worker-daily-report 还没想清楚后台任务该放容器还是函数。

一人公司的项目类型通常不止一种：内容站、工具站、SaaS 后台、定时任务，很难用一个平台全塞进去。这篇文章按这四类项目梳理平台选择：Cloudflare Pages、Workers、Vercel、Railway 分别适合什么、成本警戒线在哪里、维护压力有多大。

1. 一人公司部署的真实场景：四个项目卡在四个地方

blog 是一个 Astro 静态站点，托管在 Cloudflare Pages。构建次数很快接近 Free 层的 500 builds/month：每次改文章、修样式、调整配置都触发一次部署。20,000 files 的上限暂时还没碰到，但 Pages Functions 的动态功能（评论、搜索）已经计入 Workers 的配额，动态成本和静态成本混在一起算。

tool-api 是一个轻量 API 服务，用 Workers 处理用户登录和数据持久化。流量增长后，100,000 requests/day 的 Free 上限不够用了，10ms CPU 的限制在处理复杂请求时经常超时。要升级到 Paid，最低门槛是 $5/month，而 Workers 的 CPU 和请求计费模型跟静态资产完全不同。

dashboard 是一个 Next.js 全栈应用，部署在 Vercel。Preview deployment 体验很好，但账单里出现了 Function、Image、Build、Analytics 多项计费。团队协作需要 additional paid seat，每个 $20/month。Active CPU 4 hours 和 360 GB-hrs 的 Hobby included 看起来够用，但实际用量要看 Function 执行时间和图片优化次数。

worker-daily-report 是一个后台任务，每天定时生成报告并发邮件。Workers 的 CPU 和内存限制让它跑不了长任务；Railway 能跑 Node 服务和定时任务，但需要监控资源用量（RAM、CPU、egress、volume），不像 Workers 那样完全托管。Hobby $5/month 订阅包含 $5 资源用量，超出后按实际计费，忘了设置上限容易超预期。

这四个项目的核心问题都是同一个：项目类型不同，平台的能力边界和计费模型也不同。内容站、工具站、SaaS 后台、长任务很难用一个平台全塞进去，按项目类型拆分平台是更合理的做法。

2. 四个平台的核心约束

2.1 Cloudflare Pages：静态资产免费，动态函数看 Workers

Cloudflare Pages 的核心能力是静态资产托管，全球 CDN 免费分发。Free 层的限制包括构建次数、文件数、单文件大小：

• 500 builds/month：每次 git push 或手动触发都算一次构建；频繁改内容、修样式容易接近上限。
• 20,000 files：站点总文件数；纯静态博客通常不会超，但大量图片或资源文件需要控制。
• 25 MiB 单文件上限：视频、大型数据文件不适合直接放 Pages。
• 100 custom domains：Free 每项目最多绑定 100 个自定义域名。
• 20 min build timeout：构建超过 20 分钟会失败；复杂构建流程需要优化。

Pages Functions（动态函数）的请求和 CPU 计入 Workers plan，不是 Pages 的静态配额。这意味着：

• 静态资产免费分发，构建和文件限制内。
• 动态功能（评论、搜索、API 代理）要用 Workers 的配额和计费模型。
• Astro/Hugo 纯静态站点完全够用；Next.js SSG 要看框架适配和构建时间。

内容站和静态工具优先选择 Pages，但要清楚构建次数、文件数和动态函数的成本边界。少量动态功能可以用 Pages Functions，但大量动态请求和复杂计算要单独评估 Workers 的付费门槛。

2.2 Cloudflare Workers：轻量函数，请求和 CPU 都有边界

Workers 是 Cloudflare 的动态函数运行环境，适合轻量 API、动态函数和工具站后端。Free 和 Paid 的边界在请求量和 CPU：

• 100,000 requests/day：Free 层的请求上限；流量增长后容易不够用。
• 10ms CPU：Free 层的 CPU 时间限制；处理复杂 JSON、加密、图像转换或其他计算密集逻辑时容易超限；等待外部网络请求本身不计入 CPU 时间。
• $5/month Paid 门槛：超出 Free 后，最低付费是 $5/month（Workers Paid plan）。
• 10M requests/month：Standard 计费层的请求包含量。
• 30M CPU ms/month：Standard 计费层的 CPU 时间包含量。
• 128MB memory：Workers 的内存上限；不适合大数据处理或端计算。

Workers 的设计是轻量函数，不是容器或长任务运行环境。适合的场景包括：

• 轻量 API：用户登录、数据查询、简单业务逻辑。
• 动态函数：Pages Functions 的动态功能（评论、搜索）。
• API 代理：请求转发、缓存、鉴权。

不适合的场景包括：

• 长任务：定时报告生成、数据处理、批量操作。
• 重计算：复杂算法、大数据处理、机器学习推理。
• 数据库连接池：Workers 的限制和外部数据库连接方式不同。

工具站的动态 API 优先选择 Workers，但要清楚请求、CPU 和内存的边界。流量增长后，从 Free 到 Paid 的成本跳跃要提前评估；长任务和重计算要找其他平台。

2.3 Vercel：Next.js 最佳搭档，但账单不只是 Pro seat

Vercel 是 Next.js 的官方托管平台，preview deployment 体验最好，但账单不是只看 Pro seat。Hobby included 的资源有限，多项计费来源容易超预期：

• Active CPU 4 hours：Hobby included 的 Function CPU 时间；Function 执行超过 4 小时后计费。
• 360 GB-hrs Provisioned Memory：Hobby included 的 Function 内存；内存占用超过 360 GB-hrs 后计费。
• 1M invocations：Hobby included 的 Function 调用次数；调用超过 1M 后计费。
• Build $0.0035/CPU minute：使用按需并发或 Elastic build machine 时按构建 CPU 时间计费，标准构建机是否收费要看当前套餐与配置。
• Team seats $20/month/additional paid seat：团队协作时每个额外成员 $20/month。
• deployments/day Free 100 / Pro 6000：部署频率限制；Free 每天 100 次，Pro 6000 次。
• uploads/day Free 5000 / Pro 40000：上传频率限制；图片和资源文件上传多了会受限。

账单可能包含多项计费来源：

• Function：Function 执行时间、内存、调用次数。
• Image：图片优化次数和大小。
• Build：Preview deployment 和生产构建的 CPU 时间。
• Analytics：Web Analytics 和 Speed Insights。
• Observability：Logs、Error Monitoring、Deployment Protection。

账单警示的关键点：

• Preview deployment 频繁会增加构建用量；当项目启用按需并发或 Elastic build machine 时，构建 CPU 时间会进入账单。
• 图片优化产生独立 Image 成本：图片多、优化频繁时计费独立。
• Analytics 和 Observability 是独立计费：不是 Pro seat 包含的，要单独看用量。

Next.js 全栈项目优先选择 Vercel，但要清楚 Hobby included 的边界和多项计费来源。Preview deployment 频繁、图片优化、团队协作时账单容易超预期；Function、Image、Build、Analytics、Observability 都要单独监控用量。

2.4 Railway：容器运行环境，需要监控资源用量

Railway 是容器/PaaS 运行环境，适合 Node 服务、后台任务、数据库，不像 Workers 限制 CPU 和内存。订阅和资源用量分开计费：

• $5 Hobby / $20 Pro 订阅：订阅费固定，不包含资源用量上限。
• Hobby includes $5 resource usage/month：Hobby 订阅包含 $5 资源用量，超出后按实际计费。
• Pro includes $20 resource usage/month：Pro 订阅包含 $20 资源用量，超出后按实际计费。
• RAM $10/GB/month：内存计费；服务运行时占用的 RAM 按月计费。
• CPU $20/vCPU/month：CPU 计费；服务运行时占用的 CPU 按月计费。
• Egress $0.05/GB：出站流量计费；数据流出 Railway 网络时计费。
• Volume storage $0.15/GB/month：持久化存储计费；数据库和文件存储按月计费。
• Free 默认 0.5GB RAM / 1 vCPU / 0.5GB volume：Free 服务的基础资源配置；超出后计费。

Railway 不是”无需运维”的托管平台，需要关注服务器运行状态：

• 监控资源用量：RAM、CPU、egress、volume 的实际用量和成本。
• 设置资源和日志告警：用量接近上限或服务异常时及时收到通知。
• 了解 image retention：不同套餐保留已删除部署镜像的时间不同，关系到回滚窗口和重新构建。
• 服务器运行责任：不像 Workers 那样完全托管，需要关注服务健康、重启策略、备份方案。

成本警戒线：

• 忘了设置资源上限会超额：用量超过订阅包含的 $5/$20 后，按实际计费，不设上限容易失控。
• 忘了关服务会持续计费：服务不停止就持续占用 RAM/CPU/volume，成本一直累积。
• egress/volume 不看会超预期：出站流量和持久化存储独立计费，容易忽略。

Node 服务、后台任务、数据库优先选择 Railway，但要清楚订阅和资源用量分开计费的模型。设置资源和日志告警、定期检查用量、控制 egress 和 volume 成本是必要的维护责任；Railway 不是”无需运维”。

3. 项目类型→平台映射决策表

3.1 内容站（博客/文档站）

内容站是大多数一人公司的第一个项目：博客、文档站、个人站点。特点是静态资产为主、少量动态功能。

项目特征	推荐平台	关键警戒线
Astro/Hugo 纯静态	Cloudflare Pages	构建 500 次/月、文件 20k
Next.js SSG	Cloudflare Pages / Vercel	构建时间、build 成本
少量动态（评论/搜索）	Pages Functions	计入 Workers plan

Astro 或 Hugo 的纯静态站点优先选择 Cloudflare Pages：静态资产全球 CDN 免费分发，构建次数和文件数的 Free 上限通常够用。更多内容站部署细节可以参考Cloudflare Pages 部署教程和Cloudflare 免费限制。

Next.js SSG 的选择要看框架适配和构建时间：Cloudflare 对 Next.js 的支持需看官方文档当前适配，不写”只支持/不支持”的过时绝对判断；Vercel 是 Next.js 创建者，preview deployment 体验好；构建是否产生额外费用取决于构建机和并发配置。

少量动态功能（评论、搜索）可以用 Pages Functions，但请求和 CPU 计入 Workers plan，不是 Pages 的静态配额。动态成本和静态成本分开算，要单独评估 Workers 的付费门槛。更多动态函数场景可以参考Workers API 代理。

内容站的核心警戒线是构建次数和文件数：频繁改内容、修样式容易接近 500 builds/month；大量图片或资源文件需要控制 20,000 files。动态功能要清楚 Workers 的成本边界，不要把 Pages 的静态免费误以为动态也免费。

3.2 工具站（静态/动态）

工具站是独立开发的核心产品：单页应用、生成器、动态 API 服务。区分静态工具和动态 API 是关键。

项目特征	推荐平台	关键警戒线
纯静态工具	Cloudflare Pages	构建、文件限制
轻量动态 API	Workers	请求 100k/day、CPU 10ms
Next.js 全栈	Vercel	Function、Image、Build 成本

纯静态工具（单页应用、生成器）优先选择 Cloudflare Pages：前端逻辑在浏览器执行，后端不需要，静态托管完全够用。构建次数和文件数的限制跟内容站一样。

轻量动态 API（用户登录、数据持久化）优先选择 Workers：请求和 CPU 的 Free 上限够用初期流量，CPU 10ms 的限制在简单业务逻辑内不会超时。流量增长后要评估请求量和 CPU 成本，从 Free 到 Paid 的门槛是 $5/month。Workers 的 128MB memory 限制不适合大数据处理或复杂计算。

Next.js 全栈工具优先选择 Vercel：framework support 好，preview deployment 体验流畅。但 Function、Image、Build、Analytics 的多项计费要单独监控；Preview deployment 频繁时要同时监控构建用量、构建机和并发配置。

工具站流量增长的核心警戒线是请求量和 CPU 成本：Workers 的 Free 到 Paid 门槛是 $5/month，请求和 CPU 超出后计费；Vercel 的 Function 执行时间、内存、调用次数都有 Hobby included 上限，超出后计费。

3.3 SaaS 后台

SaaS 后台是多人协作、需要数据库连接、需要团队管理的项目。Next.js 全栈优先 Vercel，但账单警示和数据库连接是关键问题。

项目特征	推荐平台	关键警戒线
Next.js 全栈	Vercel	Function、Image、Build、Analytics 成本
其他框架	Workers / Vercel	看 framework support
团队协作	Vercel / Railway	team seats 成本

Next.js 全栈 SaaS 后台优先选择 Vercel：preview deployment 体验好，团队协作便利，framework support 最佳。但账单需关注多项计费来源：Function 执行时间、内存、调用次数；Image 图片优化；Build Preview deployment 和生产构建；Analytics Web Analytics 和 Speed Insights；Observability Logs、Error Monitoring、Deployment Protection。更多细节可以参考Cloudflare 价格对比，了解 Cloudflare 和 Vercel 的计费差异。

其他框架的 SaaS 后台要看 Cloudflare Workers 或 Vercel 的 framework support：不写”只支持/不支持”的过时绝对判断，以官方文档当前适配为准。Workers 的请求和 CPU 限制可能不适合复杂业务逻辑；Vercel 的多项计费要单独监控。

团队协作需要 team seats：Vercel additional paid seat $20/month，团队成员多了成本会高。Railway 也有 team 协作功能，但具体成本要看官方当前定价。

数据库连接不在 Workers/Pages/Vercel 内：需要外部服务（Supabase、PlanetScale、Railway volume）。数据库的选择和部署是独立问题，一人公司数据库与存储方案会在后续文章详细讨论。

SaaS 后台的核心警戒线是账单的多项计费和 team seats：Vercel 的 Function、Image、Build、Analytics、Observability 都要单独监控用量；团队协作时每个成员 $20/month。数据库连接需要外部服务，不在部署平台内。

3.4 长任务/容器服务

长任务和容器服务是 Workers 和 Vercel Function 不适合的场景：定时报告生成、数据处理、批量操作、数据库持久化。Railway 的容器运行环境更适合，但需要承担运行责任。

项目特征	推荐平台	关键警戒线
Node 服务/worker	Railway	RAM/CPU/egress/volume 监控
数据库	Railway	Volume 成本、备份策略
后台任务	Railway	资源用量告警

Node 服务和 worker（定时任务、批量操作）优先选择 Railway：不像 Workers 限制 CPU 10ms 和内存 128MB，能跑长任务和复杂计算。但 Railway 是容器运行环境，需要监控资源用量（RAM $10/GB/month、CPU $20/vCPU/month、egress $0.05/GB、volume $0.15/GB/month），设置资源和日志告警，核对 image retention 与回滚窗口。

数据库优先选择 Railway volume 或外部服务（Supabase、PlanetScale）：Railway 的 volume storage $0.15/GB/month，持久化存储成本要看数据量。数据库备份策略和恢复方案要单独设计，不在 Railway 的托管服务内。

后台任务的核心警戒线是资源用量告警：Hobby $5/month 订阅包含 $5 资源用量，超出后按实际计费。忘了设置资源上限会超额；忘了关服务会持续计费；egress/volume 不看会超预期。

Railway 不是”无需运维”：不像 Workers 那样完全托管，需要关注服务器运行状态、服务健康、重启策略、备份方案。设置资源和日志告警、定期检查用量、控制 egress 和 volume 成本是必要的维护责任。

4. 成本模型与警戒线

4.1 Cloudflare 成本模型

Cloudflare 的成本模型分两块：Pages 静态资产免费分发，Workers 动态函数请求和 CPU 计费。

Pages 静态资产成本：

• 静态资产免费分发，构建和文件限制内（500 builds/month、20,000 files）。
• 构建次数接近上限要优化构建流程，减少频繁改内容和样式触发的部署。
• 文件数接近上限要控制图片和资源文件数量，大型文件用外部存储。
• Pages Functions 的动态功能计入 Workers plan，不是 Pages 的静态配额。

Workers 动态函数成本：

• Free 层：100,000 requests/day、10ms CPU。
• 超出 Free 后，Paid 最低 $5/month（Workers Paid plan）。
• Paid 的 Standard 计费：10M requests/month、30M CPU ms/month。
• 超出 Standard 包含量后按实际请求和 CPU 计费。

成本警戒线：

• Pages 静态资产免费，但构建次数、文件数、单文件大小有上限；超出后无法继续部署。
• Workers Free 够用初期流量，但请求和 CPU 超出后必须付费；从 Free 到 Paid 的门槛是 $5/month。
• Pages Functions 的动态成本和静态成本分开算，不要误以为 Pages 全部免费。

一人公司初期可以选择 Pages 静态资产 + Workers Free 额度：内容站静态托管免费，工具站动态 API 用 Free 的请求和 CPU。流量增长后，Workers 的 Paid 成本要提前评估，请求量和 CPU 时间是关键警戒线。

4.2 Vercel 成本模型

Vercel 的成本模型比 Cloudflare 更复杂：Hobby included 资源有限，多项计费来源独立计算。

Hobby included 资源：

• Active CPU 4 hours：Function CPU 时间；超出后按 Active CPU 计费。
• 360 GB-hrs Provisioned Memory：Function 内存；超出后按 Provisioned Memory 计费。
• 1M invocations：Function 调用次数；超出后按 invocation 计费。
• Build usage $0.0035/CPU minute：开启按需并发或选择 Elastic build machine 时按构建 CPU 时间计费；标准构建机通常不按这一项收费。

多项计费来源：

• Function：Active CPU、Provisioned Memory、invocation 的超出部分。
• Image：图片优化次数和大小；独立计费，不在 Hobby included 内。
• Build：Preview deployment 和生产构建的 CPU 时间；按需并发或 Elastic build machine 会产生构建费用。
• Analytics：Web Analytics 和 Speed Insights；独立订阅，不在 Pro seat 内。
• Observability：Logs、Error Monitoring、Deployment Protection；独立订阅。

Team seats：

• additional paid seat $20/month：团队协作时每个额外成员 $20/month。
• Pro plan 的 seat 包含基础资源，但 Function/Image/Build/Analytics/Observability 的超出部分单独计费。

成本警戒线：

• Preview deployment 频繁会增加构建用量；当项目启用按需并发或 Elastic build machine 时，构建 CPU 时间会进入账单。
• 图片优化产生独立 Image 成本：图片多、优化频繁时计费独立，不在 Hobby included 内。
• Analytics 和 Observability 是独立计费：不是 Pro seat 包含的，要单独看用量。
• Function 执行时间、内存、调用次数超出 Hobby included 后按实际计费。

Vercel 的账单不是只看 Pro seat：Function、Image、Build、Analytics、Observability 都要单独监控用量。一人公司选择 Vercel 时，要清楚 Hobby included 的边界和多项计费来源；Preview deployment 频繁、图片优化、团队协作时账单容易超预期。

4.3 Railway 成本模型

Railway 的成本模型是订阅 + 资源用量分开计费：订阅费固定，资源用量按实际消耗计算。

订阅和资源用量：

• Hobby $5/month 订阅 + includes $5 resource usage/month：超出 $5 后按实际计费。
• Pro $20/month 订阅 + includes $20 resource usage/month：超出 $20 后按实际计费。
• Free 默认 0.5GB RAM / 1 vCPU / 0.5GB volume：超出后计费。

资源计费明细：

• RAM $10/GB/month：服务运行时占用的内存按月计费。
• CPU $20/vCPU/month：服务运行时占用的 CPU 按月计费。
• Egress $0.05/GB：出站流量计费；数据流出 Railway 网络时计费。
• Volume storage $0.15/GB/month：持久化存储计费；数据库和文件存储按月计费。
• Image retention：不同套餐保留已删除部署镜像的时间不同，超过窗口后需要重新构建。

成本警戒线：

• 忘了设置资源上限会超额：用量超过订阅包含的 $5/$20 后，按实际计费，不设上限容易失控。
• 忘了关服务会持续计费：服务不停止就持续占用 RAM/CPU/volume，成本一直累积。
• egress/volume 不看会超预期：出站流量和持久化存储独立计费，容易忽略。

Railway 不是”无需运维”的托管平台：需要监控资源用量、设置资源和日志告警、核对 image retention 与回滚窗口、关注服务器运行状态。一人公司选择 Railway 时，要清楚订阅和资源用量分开计费的模型；Hobby $5 包含 $5 资源用量，超出后按实际计费，不设上限容易失控。

5. 维护维度：部署频率、日志、回滚、团队协作

部署频率限制和维护工具是选择平台时容易被忽略的因素：频繁迭代的项目需要关注构建次数和部署次数上限；团队协作需要 team seats 和权限管理。

部署频率/构建限制

• Cloudflare Pages：500 builds/month（Free）、1 concurrent build；频繁改内容、修样式容易接近上限；Pages 支持 preview deployments，但通过 Git 触发的预览构建同样会消耗构建次数。
• Vercel：deployments/day Free 100 / Pro 6000；Preview deployment 频繁会增加构建用量和部署次数；部署次数接近上限会影响迭代效率。
• Railway：无明确部署频率限制，但要看资源用量；部署删除后镜像只在套餐规定的 retention 窗口内可直接回滚，超过窗口需要重新构建。

部署频率的核心警戒线：Pages 的构建次数 500 builds/month 和 Vercel 的部署次数 Free 100/day。频繁迭代的项目要提前评估构建和部署频率，避免接近上限后无法继续迭代。Vercel 的 Preview deployment 频繁会同时增加构建用量和部署次数，两个警戒线都要监控。

日志/回滚/团队协作

• Cloudflare Pages：构建日志、部署历史、rollback；团队协作需要 Cloudflare team account，具体成本要看官方当前定价。
• Vercel：preview deployment、deployment history、analytics、logs；团队协作需要 team seats，additional paid seat $20/month；deployment history 和 rollback 是 Pro plan 的功能。
• Railway：logs、metrics；rollback 功能要看官方当前支持；团队协作功能要看官方当前定价。

维护工具的核心选择：Vercel 的 deployment history、analytics、logs 和 preview deployment 体验最好，适合 Next.js 全栈和团队协作；Cloudflare Pages 的构建日志和 rollback 够用静态站点；Railway 的 logs 和 metrics 需要手动监控，不是完全托管。

团队协作的成本警戒线：Vercel additional paid seat $20/month，团队成员多了成本会高；Cloudflare team account 和 Railway team 的具体成本要看官方当前定价。

6. 下一步：数据库、存储、CI/CD

一人公司部署平台选择只是技术栈的一部分：数据库和存储方案、CI/CD 流程、监控和告警策略是后续需要解决的问题。一人公司数据库与存储方案会在后续文章详细讨论，涵盖 Supabase、PlanetScale、Railway volume 的选择和成本对比。

这篇文章梳理了 Cloudflare Pages、Workers、Vercel、Railway 的核心约束、项目类型映射、成本模型和维护维度。一人公司的项目类型多样：内容站、工具站、SaaS 后台、长任务很难用一个平台全塞进去，按项目类型拆分平台是更合理的做法。成本警戒线和维护压力要提前评估，避免流量增长后账单超预期或迭代受限。