这是一张容量规划表，不是假装实测报告。四个工具都能用 Docker 跑起来，但资源瓶颈完全不同：n8n 多数时候卡内存和执行数据，OneAPI 卡数据库持久化，Plausible CE 卡 ClickHouse，PostHog 则是一整套产品分析基础设施。
我会把口径限定在独立开发者和小团队后台：每天几十到几千次工作流、低到中等网站访问量、少量内部成员使用。更高事件量、企业合规和多区域高可用不在这篇里硬估。
先买多大 VPS 才不浪费？
| 使用限制 | 适合放什么 | CPU / RAM | 磁盘 | 备份策略 |
|---|---|---|---|---|
| 单人低流量 | n8n + OneAPI，少量 workflow 和 token 转发 | 1-2 vCPU / 2GB | 30GB SSD | 每晚备份 .n8n、/data、SQLite 文件 |
| 独立 SaaS 正式后台 | n8n + OneAPI + PostgreSQL 或 MySQL | 2 vCPU / 4GB | 50-80GB SSD | 数据库 dump + 卷目录打包，升级前快照 |
| PostHog 同机限制 | PostHog hobby 单独一台，不和业务后台混放 | 4 vCPU / 16GB | 80GB 起 | 升级前备份，ClickHouse / Postgres / MinIO 分开确认 |
| 不建议同机 | PostHog + Plausible CE + n8n + OneAPI 全塞一台 | 规格不可拍脑袋 | 事件量决定 | 拆机或用托管服务，先降低恢复复杂度 |
这张表优先解决资源隔离问题：别把「轻后台」和「事件分析数据库」混在一个容器栈里。n8n 官方也写明它本身不算 CPU intensive，小实例常常够用，内存比 CPU 更值得盯；PostHog 的官方 hobby 要求则直接写到 4 vCPU、16GB RAM、30GB 以上存储。
n8n 为什么不该只看 CPU？
n8n Docker 文档推荐的启动方式会暴露 5678 端口，并把 volume 挂到 /home/node/.n8n。默认 SQLite 会保存 credentials、past executions 和 workflows；切到 PostgreSQL 后，.n8n 目录仍建议持久化，因为里面还有 encryption key、日志和其他资产。
容量上，n8n 的麻烦通常来自 workflow 写法，而不是空跑服务。Code node 处理大 JSON、二进制文件、图片转存、批量 HTTP Request，都会让内存瞬间上去。只跑 Slack 通知、表单入库、定时同步的单人后台，2GB RAM 可以起步；把它当 ETL 跑批量文件，4GB 也可能紧。
备份要按恢复路径设计：SQLite 模式备份 .n8n 整个目录；PostgreSQL 模式备份数据库，同时保留 .n8n。n8n 官方还提醒，实例重启或宕机期间错过的 Cron / Webhook executions 不可恢复，关键任务要在前面加队列、重试或缓存层。
Plausible CE 的底线在哪里？
Plausible CE 不是一个单二进制小服务。它的 README 要求 Docker + Docker Compose，CPU 支持 SSE 4.2 或 NEON，因为底层 ClickHouse 需要这些指令集；内存建议至少 2GB，避免 ClickHouse 和 Plausible 一起跑时 OOM。
如果只是一个独立产品官网、文档站、博客，Plausible CE 可以单机跑，建议从 2 vCPU、4GB RAM、50GB SSD 开始。低访问量时 CPU 不会长期高，但 ClickHouse 的磁盘和内存要留余量，尤其是事件保留时间拉长之后。
Plausible 自托管页面把责任说得很直：server capacity、uptime、backup、security、stability 都由用户自己负责。换句话说，CE 省下订阅费，也把值班和恢复工作交回给你。
PostHog 能不能和业务后台放一起？
不建议。PostHog 自托管文档把 hobby deploy 的机器写成 Ubuntu VM，规格等同 Hetzner 4 vCPU、16GB RAM、30GB+ storage，还要求域名 A 记录指向实例。示例 stack 里能看到 web、worker、plugins、Caddy、ClickHouse、Kafka、Zookeeper、Redis、Postgres、MinIO。
这类栈一旦和 n8n、OneAPI、数据库、反向代理同机，排障会变得很难：是 Kafka 重启、ClickHouse 写入慢、Postgres 磁盘满，还是 Caddy 证书问题？独立开发者最怕的不是多花一台 VPS，而是一个产品分析工具拖垮正式后台。
我的限制是：PostHog 要么单独一台 4 vCPU / 16GB 起步，要么用 Cloud；不要为了「自托管」三个字把它塞进 2GB 小机。官方也说明自托管要自己管理 infrastructure 和 scaling，付费功能还存在 Cloud-only 的限制。
OneAPI 小机够用吗？
OneAPI 的官方 Docker 命令把服务映射到 3000:3000，并把数据目录挂到 /home/ubuntu/data/one-api:/data。它的最小运维清单先看三件事：/data 是否真的持久化、管理员密码是否改掉、备份是否覆盖数据库。
单人或小团队低并发转发，1 vCPU / 1GB RAM 能跑起来，但更稳妥的起步是 1-2 vCPU / 2GB RAM。只要开始多人用、日志增长、渠道变多，就把 SQLite 迁到 MySQL；多机器部署还要统一 SESSION_SECRET，并用 Redis 做缓存或限速相关状态。
OneAPI README 里的 Zeabur 部署说明提醒：没有设置 SQL_DSN，redeploy 后数据不会持久化。这个风险比机器规格更常见，很多人不是因为 VPS 太小丢数据，而是 volume 和数据库路径没写清楚。
备份限制怎么画？
| 工具 | 必备持久化对象 | 升级前动作 | 最容易漏掉的东西 |
|---|---|---|---|
| n8n | .n8n，SQLite 或 PostgreSQL | 停容器或快照后备份数据库与卷 | encryption key、执行历史、日志 |
| Plausible CE | ClickHouse 数据、Postgres 数据、.env | 备份 compose、环境变量、数据库目录 | SECRET_KEY_BASE 和事件保留策略 |
| PostHog | ClickHouse、Postgres、MinIO、Redis 等栈内数据 | 按官方升级提示先创建 backups | 多容器依赖和磁盘增长 |
| OneAPI | /data，SQLite 或 MySQL，环境变量 | 备份数据库，确认 SESSION_SECRET | 初始密码、SQL_DSN、日志表 |
备份频率按业务损失倒推。n8n 官方建议 nightly backups；PostHog 文档也提示升级前创建 backups。独立 SaaS 后台至少每天一次，升级前一次，迁机前一次。只要涉及支付、线索、用户事件或 API token，备份不能只靠云厂商快照。
什么时候该拆到第二台机器？
第一个信号是内存常驻超过 70%。n8n 工作流执行、ClickHouse 查询、Kafka 和 Postgres 都会抢内存，swap 只是拖延问题。第二个信号是磁盘增长不可预测，尤其是事件分析和执行历史没有保留期。第三个信号是恢复路径变长：你已经说不清哪几个目录能还原服务。
拆机顺序可以很简单，把 PostHog 拿出去；再把 Plausible CE 和轻后台分开；最后把 n8n / OneAPI 的数据库拆成托管 PostgreSQL 或 MySQL。轻后台同机不是问题，重型事件分析同机才是问题。