2026 用 VPS 自建 n8n 自动化：把「月费 SaaS」变成固定成本

延伸阅读

更多相关攻略推荐：Ollama AI系列(2)：VPS上的AI推理与API应用、Ollama AI系列(2)：VPS上的AI推理与API应用、ARM / Ampere 席卷 VPS：性价比真香还是兼容陷阱？、【VPS 硬件选型指南 (内存 篇) 02】大内存 VPS 能干嘛？、2026 独立站 PCI-DSS 自查清单：SAQ A 还是 A-E。

引子：被 Zapier / Make 账单劝退之后

做自动化的人，大概率是被账单劝退的。你本来只想让系统每天把订单同步到表格、把新用户塞进邮件组、把退款自动建工单，结果 Zapier 告诉你「这个月跑了 2 万次 task，超量了，加钱」；Make 告诉你「operation 用超了，下个档位」。最离谱的是，工作流每多一步、每多跑一次，账单就跟着翻倍——你省钱省效率的初衷，最后变成了给 SaaS 续命。

这就是为什么越来越多人转去看 n8n。n8n 是一个开源的可视化工作流引擎，节点式画布、原生支持 JavaScript/Python 代码节点和 AI 节点，能接任意开放 API。最关键的一条：它的社区版（fair-code 许可）完全免费，无限工作流、无限执行次数。你付出的是一台 VPS 的钱，换来的是「跑多少都不加价」的固定成本。本文就站在一个想省钱又怕踩坑的大陆用户视角，把自建 n8n 的账算明白。

n8n 自托管到底省在哪

要理解省在哪，得先看清 SaaS 的计费逻辑。Zapier 按 task（动作数）计费，Make 按 operation（操作数）计费。一个「查条件 → 富化数据 → 更新 CRM」的三步流程，在它们那里就是 3 个计费单元；如果这条流程一天跑 1000 次，就是 3000 个单元。流程越复杂、跑得越勤，账单越贵，而且你几乎没法预测月底多少钱。

n8n 自托管是另一套逻辑：软件免费，你只付服务器。无论你建 5 个还是 50 个工作流、无论每个跑 100 次还是 10 万次，VPS 月费不变。这就把「可变成本」变成了「固定成本」。对做外贸独立站、出海 SaaS、内容分发的人来说，这种确定性本身就是钱——你不用再因为怕超量而砍掉本该自动化的环节。

当然，免费指的是软件授权。服务器、维护、你的时间都要花钱，这一点我们后面单独算，不给你画大饼。但结论是稳的：同等自动化体量下，自托管 n8n 的边际成本接近于零，而 SaaS 的边际成本随用量直线上升。

先算账：月费十几块真能跑无限工作流吗

很多人第一反应是「十几块哪够」。我们拿公开测评的三档配置说话（具体以商家页面为准，这里给的是行业常见区间）。

你看，最便宜的一档就是 5–8 美元（约几十块人民币），2 GB 内存 + SQLite 跑个人自动化绰绰有余。就算上到小业务生产档，12–25 美元也就能覆盖绝大多数中小团队。对比一下 SaaS：Zapier Professional 69 美元/月只给 2000 tasks，跑到 5 万 tasks 就要 448 美元/月以上；Make Teams 5 万 ops 约 82–105 美元/月。有公开案例把 23 条 Make 场景从 348 美元/月迁到一台约 12 美元/月的 VPS 上，工具费直接砍到零头。

所以「月费十几块跑无限工作流」不是口号，是真实可达的档位——前提是你愿意自己运维。这里的关键词是「无限执行次数」：同样一台 VPS，跑 100 次和跑 10 万次，账单一模一样。

常驻内存别省：1–2 GB 是底线

标题里特意写「常驻内存 1–2 GB 起」，因为这是新手最容易翻车的地方。n8n 基础进程空闲时大约占 300–500 MB 内存，看起来很小，但这是「静默」状态。一旦工作流真正跑起来、同时并发几个执行、或者你用了 AI 节点/Puppeteer 浏览器自动化，内存会快速往上窜。

各家与官方共识很一致：最低 2 GB RAM 才稳。用 1 GB 的机器，真实负载下会被系统的 OOM killer（内存溢出杀手）直接干掉进程，表现就是「n8n 莫名其妙挂了」。如果你要用 Puppeteer/Chromium、AI 节点或处理大文件，立刻要 4 GB。这不是商家劝你升配，是工程现实。

判断自己要不要 4 GB，看三件事：① 工作流里有没有浏览器自动化（截图、爬页面）；② 有没有大量 AI 调用（上下文缓存吃内存）；③ 单次处理的数据量大不大（几万行的 CSV、大 PDF）。命中任意一条，直接上 4 GB，别犹豫。RAM 是 n8n 最该花钱的地方，比 CPU 重要。

数据库怎么选：SQLite 还是 Postgres

n8n 默认用 SQLite，零配置，数据就藏在数据卷里，适合少量工作流、月几千次执行的阶段。但 SQLite 有个本质弱点：它是单写者（single-writer）模型。当多个执行并发写入时，它会锁表，表现就是「工作流随机失败，看着像节点 bug，其实是数据库在排队」。

所以迁移到 Postgres 的时机很明确：当月执行量到几千~几万、或者你跑多用户/并发工作流时，就该切了。切法不复杂，靠环境变量告诉 n8n 用 Postgres 即可：

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=改成你的强密码

下面是两者的取舍，照着对号入座：

一个小提醒：从 SQLite 换 Postgres，数据库不会自动搬数据，记得先导出工作流，再迁移或重新导入。别等到负载爆了才换，那时候锁表失败会让你很难受。

三款便宜 VPS 怎么挑

本文相关的三家是 Contabo、RackNerd、Vultr，都适合跑 n8n，但性格不同（价格以商家页面为准）。

怎么选：想最省心且内存大，看 Contabo；想用支付宝、个人测试起步便宜，看 RackNerd（注意年付促销机内存小，跑 AI 节点要升档）；想要按小时计费、随时销毁不浪费，看 Vultr（但别买 2.5 美元那档，它没有 IPv4，n8n 反代会麻烦）。对大陆用户来说，RackNerd 支持支付宝最友好，先 72 小时测一轮再决定留不留。

一小时上手：Docker 部署与反代 HTTPS

n8n 官方推荐 Docker 部署，v3.0（预计 2026 年 10 月）起甚至会取消 npm 安装方式，只留 Docker。所以直接走 Docker 是最稳的路。最小起手（SQLite 默认）一条命令：

docker volume create n8n_data
docker run -d --name n8n -p 5678:5678 \
    -e GENERIC_TIMEZONE=Asia/Shanghai \
    -e TZ=Asia/Shanghai \
    -v n8n_data:/home/node/.n8n \
    docker.n8n.io/n8nio/n8n

跑起来后访问 http://你的IP:5678 就能进编辑器。但生产环境千万别把 5678 裸奔到公网——webhook 端点带着真实业务数据，而且浏览器在纯 HTTP 下会限制部分 UI。正确做法是在前面套一层反代（Caddy 最简单，两条配置就能自动签发 Let's Encrypt 证书；Nginx + certbot 也行），把 n8n 放到 HTTPS 后面。

反代之外，给 n8n 一个公网地址这件事要提前想好：你需要一个域名，解析一个子域（比如 automation.你的域名.com）指向这台 VPS。后面「生产三处必填」会讲为什么这个地址至关重要。

生产环境三处必填

这一节是血泪经验，三处漏掉任何一处都会在生产环境出诡异问题。

第一处：WEBHOOK_URL。 外部服务（Stripe、CRM、各类 API）回调你的 webhook 时，用的地址是 n8n 通过 WEBHOOK_URL 生成的。如果你没设，n8n 会用内网地址（比如 http://localhost:5678/...）生成 webhook，测试时编辑器里的测试 URL 能通，一上生产外部根本调不到——工作流「测试好好的，上线静默不触发」。这是自托管 n8n 头号坑。设法：

WEBHOOK_URL=https://automation.你的域名.com/

第二处：执行日志清理。 n8n 默认会一直堆执行历史，几个月后能把手磁盘撑爆，然后整个实例变慢。务必配保留天数，比如只留两周：

EXECUTIONS_DATA_MAX_AGE=336

第三处：凭据加密密钥。 n8n 把所有账号凭据用一把密钥加密，这把密钥就在数据卷里。你必须在一开始用 N8N_ENCRYPTION_KEY 显式指定一把强密钥，并离线保存（比如密码管理器）。钥匙丢了，所有凭据恢复不出来；钥匙只存在服务器上，服务器重置就全没。生成示例：

N8N_ENCRYPTION_KEY=用 openssl rand -hex 24 生成的密钥并离线保存

备份与升级：别让一次更新丢全部凭据

备份最容易犯的错：只备份数据库，忘了数据卷。n8n 的官方文档明确说，数据卷里除了工作流，还装着凭据加密密钥。如果你只恢复了数据库、没恢复那把密钥，工作流是回来了，但每个凭据都锁死，等于白恢复。正确做法：整个数据卷一起备。

docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine \
    tar czf /backup/n8n_backup.tar.gz -C /data .
# 如果你用 Postgres，再加一条 pg_dump

升级也讲规矩：生产环境把镜像 tag 钉到具体版本（别用 latest），升级前先手动快照，再拉新镜像、重建容器、看日志。社区里「升级翻车」的，几乎都是没先备一份新鲜快照就直接拉 latest。另外建议每月做一次恢复演练，确认备份真能还原——很多人第一次恢复是在出事那天，结果发现备份是坏的。

自己动手验证：跑通第一个 webhook 工作流

部署完别急着接业务，先跑通一个小验证：建一个「Webhook 触发 → 写一行日志 / 发个通知」的工作流，用 curl 打一下你的公网 webhook 地址，确认能收到。这一步同时验证了三件事：反代 HTTPS 通不通、WEBHOOK_URL 生成的对不对、数据卷权限正不正常。

还要验证常驻内存够不够：在编辑器里手动并发触发几次重活（比如一个大循环），同时 ssh 到机器上 watch 一下 free -m，看内存余量。如果余量长期低于 200 MB，说明你该升 4 GB 了，别等 OOM killer 半夜叫醒你。最后用 ip addr / curl ifconfig.me 确认你的 VPS 公网 IP 是你以为的那个，避免反代配错网卡。

风险提示：免费≠零成本

必须说句实话，免的是软件，不是全部。自托管 n8n 的隐藏成本有两块。

一是维护时间：每月 2–4 小时用来更新、备份、看监控，这是定价页不写的。如果外包出去，折算约 80–200 美元/月。问题是，绝大多数人低估了这部分，等到第一次更新翻车、第一次磁盘写满才意识到。

二是安全风险：自托管把 perimeter（边界）交给你自己。编辑器如果裸在 5678、密码还复用，就是最典型的被攻破姿势。基础三件套不能省：SSH 密钥登录、防火墙只开必要端口、n8n 开启用户管理、登录路由加限流、全程 TLS。一句话：一个你忘记打补丁的自托管实例，比一个你吐槽贵的 Zapier 订阅更危险。

还有版本趋势要记着：n8n v3.0 起取消 npm 安装，必须 Docker。如果你现在还想用 npm 方式，趁早切 Docker，别到时候被动。

结语：把可变成本变成固定成本

回到开头那个被账单劝退的你。自建 n8n 的本质，不是「又学一个工具」，而是把自动化从「用一次贵一次」的 SaaS 焦虑，变成「一台十几块月付 VPS 跑无限工作流」的固定成本。它要你付出运维时间和一点学习曲线，但换回来的是：无限工作流、无限执行、数据握在自己手里、不再看 SaaS 的脸色。

落地建议很朴素：先用 RackNerd 这类支持支付宝的便宜机器，2 GB 起步跑通个人自动化；等真的上业务、并发起来了，升 4 GB 并切 Postgres；永远记得三件事——WEBHOOK_URL、执行日志清理、凭据密钥离线保存。把可变成本钉成固定成本，你就赢了 SaaS 那套计费游戏。