n8n 自托管的成本账：什么量级才值得自己跑
数据截至 2026-07，价格与限额以各官网为准。
n8n 自托管真正省下来的不是”软件钱”，而是”执行次数”这个计价维度——云版按流程跑了多少次收钱，自托管按你的服务器能扛多少收钱。所以这笔账的分水岭不在你有没有技术能力，而在你每月的执行量有没有大到让”按次计价”这件事本身变得不划算；量不够的时候自己跑，省下的订阅费大概率被你自己的运维时间吃回去。
先承认一个很常见的误解：很多人看到”n8n 是开源的、自托管不收授权费”，就直接推出”自托管 = 免费”。这个推论在授权这一项上没错，但它漏掉了后面三笔钱——服务器要租、要备份、要升级，出故障时得有人半夜爬起来看日志，工作流里调的大模型接口按 token 单独计费，一分不少。把这些加回去之后，很多小团队会发现自己算的”省钱”其实是把现金支出换成了时间支出。这篇就把这几笔账一项项摊开。
如果你还没搭过 n8n、不确定它是干什么的，建议先看 n8n 中文入门：搭第一个 AI 自动化工作流，那篇讲的是”怎么跑起来”，这篇讲的是”值不值得自己跑”。
先把成本拆成四笔，别混在一起算
绝大多数关于”自托管省不省钱”的争论，都是因为双方算的根本不是同一笔账。开始比价之前，先把 n8n 这类工作流平台的支出拆成四块：
第一笔：软件授权费。 n8n 自托管本身没有授权费，这一点是明确的。另外它还提供面向企业的授权自托管版本，附带 SSO、版本控制、高级权限管理这类企业功能，那个版本是要付费的。所以严格讲，“n8n 自托管”其实有两种：不花钱的那种，和为了合规与权限管理而花钱的那种。团队规模一上来、开始有”谁能改哪条工作流""上线前要不要走审批”这类需求时，第二种才进入视野。
第二笔：基础设施。 服务器（或者自家机房的一台机器）、存储、带宽、数据库、备份空间。这笔钱是持续的、不随你用不用而消失的固定支出。它的特点是：量小的时候它是纯亏损——你每月跑 200 次工作流，服务器照样 7×24 小时空转计费。
第三笔：运维人力。 这是最容易被漏掉、实际占比却最高的一笔。包括初次部署、升级版本、处理容器起不来、排查内存打满、配置反向代理和证书、做数据备份和恢复演练、以及最要命的——流程半夜挂了没人知道，第二天客户先发现。这笔钱不会出现在任何账单上，但它真实存在。
第四笔：模型调用费。 无论你用云版还是自托管，工作流里只要接了大模型节点，token 就得单独付。自托管完全省不掉这一项。开源平台自托管免费，指的是平台本身，服务器成本与大模型接口调用费都是另计的。很多人算账时把这一块混进”自托管省下的钱”里，结论自然是错的。
把四笔分开之后，一个直觉结论就出来了：自托管把第一笔压到零，把第二、三笔提高，第四笔完全不变。所以它是否划算，取决于第一笔在你这里到底有多大。
云版为什么会”突然”变贵
n8n 云版的计价核心是执行次数。第三方评测的一致观察是：云版低档位的执行次数上限比较紧，高频自动化会很快变贵。 这句话听起来平淡，实际用起来的体感是断崖式的。
原因在于工作流的执行量不是线性增长的，而是阶跃的。举几个真实会发生的场景：
- 你把一条”新邮件进来就处理”的流程从内部试用推给全公司，触发源从 1 个邮箱变成 30 个。
- 你给一条流程加了个每 5 分钟轮询一次的定时触发器，用来”看看有没有新数据”。这一个改动，一个月就是八千六百多次执行，而其中绝大多数次跑完什么也没干。
- 一条主流程里嵌套调用了三条子流程，你以为是 1 次执行，计费口径上可能远不止。
也就是说，云版的账单不是随着业务缓慢爬升的，而是被某一次”顺手加个轮询”直接推上一个台阶。这也是自托管最有说服力的卖点：服务器不在乎你跑了 1 万次还是 10 万次，只在乎那一刻的 CPU 和内存扛不扛得住。 一条空跑的轮询在自托管上几乎是零成本，在按次计价的云版上就是实打实的账单。
反过来说，这个卖点只对”执行次数多、单次很轻”的场景成立。如果你的流程是每次都要跑几分钟的重活，自托管的服务器一样会被压垮，你还得升配，那时候省下的订阅费又贴回去了。
什么量级才值得自己跑
这是本文标题的问题，先给一个参考坐标，再说这个坐标该怎么用。
有第三方测算称：在每月 10 万次以上操作的量级下，自托管相比云版每年可以省下约 3,000 到 5,000 美元。这是第三方评测口径的估算，不是官方定价，具体价格与额度请以 n8n 官网当前定价页为准。
这个数字的用法不是”照抄”，而是当量纲参考。它至少告诉我们两件事：
第一，省下来的钱是”几千美元一年”这个数量级，不是几万。 换算成月度，大概是几百美元的月度差额。你可以拿这个数字去对照：一台够用的服务器月租多少？你的团队里有人为这套东西付出的时间，折算成人力成本每月又是多少？如果两者加起来已经接近甚至超过那个差额，自托管在纯财务上就没有意义了。
第二，10 万次/月不是一个小数字。 拆成日均是三千多次，拆成每小时是一百多次。绝大多数中小团队的真实自动化量，离这个数量级有相当距离——除非你有前面说的那种高频轮询流程在空跑，那种情况下应该先做的是优化触发方式（比如把轮询换成 Webhook 推送），而不是急着迁移部署方式。
所以更实用的判断顺序是这样的：
- 先去后台看你上个月真实的执行次数，而不是凭感觉估。
- 看这些执行里，有多大比例是”跑完什么也没干”的空转。先砍掉这部分。
- 砍完之后再看剩余量级，如果仍然稳定顶着套餐上限、并且还在增长，自托管才开始有讨论价值。
- 就算到了这一步，也还要过下一节那一关。
比钱更硬的三个非财务理由
实践中，真正让团队下决心自托管的往往不是省钱，而是下面这三条。它们的共同点是：在云版上花再多钱也解决不了。
数据不能出内网。 工作流里流过的是客户名单、合同、财务明细、内部工单，公司规定这些数据不能进第三方 SaaS。这是最常见、也最不需要论证的自托管理由——它根本不是成本问题，是能不能用的问题。
要接内网系统。 你的 ERP、数据库、内部 API 只在办公网或专线里可达，公有云上的工作流引擎连不进来。自托管一台在同一个网络里的实例，这个问题就不存在了。
要深度定制。 n8n 自带四百多个集成（Slack、HubSpot、PostgreSQL、Google Sheets、HTTP 请求等等），还提供原生的 JavaScript 和 Python 代码节点，三者相比，它在扩展性上的空间是比较大的一个。如果你需要写自定义节点、跑自己的脚本、装非官方社区节点，自托管的自由度明显更高。
反过来，如果这三条你一条都不占，纯粹是想省钱，那就老老实实回到上一节的执行量对照表，别给自己加戏。
自托管的隐性账单：运维时间
这一节请认真读，因为它是最多人翻车的地方。
n8n 的可视化画布上手不难，但整体是有学习曲线的，非开发者独立驾驭起来会比较吃力——这一点在第三方评测里是共识。而”部署并长期维护一个自托管实例”比”会拖节点”要难一个量级，它至少包含：
- 部署与网络：容器编排、反向代理、HTTPS 证书、Webhook 需要的公网可达地址。Webhook 尤其容易卡住新手：本机跑得好好的，外部服务回调打不进来。
- 持久化与备份：工作流定义、执行历史、凭据都要落库。凭据丢了意味着所有集成要重连一遍。备份不是配了就完事，得真的演练过恢复。
- 升级：开源项目迭代快，长期不升级会积累安全隐患；升级又可能踩到不兼容。谁来做、多久做一次、出问题怎么回滚，都得有说法。
- 监控与告警：这条最容易被跳过，也最容易出事。自动化流程的特点是”平时你根本不看它”，所以它悄悄挂掉三天你可能都不知道。至少要有一条”流程失败就通知到人”的兜底路径。
- 资源规划：并发上来之后内存和数据库连接会成为瓶颈。具体需要什么配置，以官方部署文档当前给出的要求为准，别照抄网上几个月前的帖子。
把这些折成时间：初次部署顺利的话是小时级，不顺利可能是好几天；之后每个月还要有稳定的维护投入。按你团队的人力成本折算一下，再和上一节那个”几千美元一年”的差额比。很多团队做完这一步就想明白了：他们缺的不是钱，是那个愿意长期负责这台机器的人。
具体怎么用 Docker 把 n8n 跑起来、怎么接 MCP 扩展工具，可以参考 n8n + MCP 本地部署搭 AI Agent（含汉化），那篇是操作层面的详细步骤。
别为了省钱把架构搞复杂
算成本的时候还要看一眼选型本身有没有选对，因为”用错平台”造成的浪费，通常比订阅费高得多。
三个平台的定位其实不重叠：n8n 是工作流自动化平台，触发器启动流程、节点处理数据、连接器搬运数据，AI 只是流程中的一环；Dify 是围绕大模型构建的，主场景是 chatbot 和 RAG 应用；Coze 专注对话式 AI，做聊天机器人和虚拟助手，几乎不写代码就能上线，但扩展性局限在对话场景。
对应到选型：自动化从一个事件开始、AI 只是其中一步，选 n8n；要做大模型优先的应用（chatbot、agent、RAG），选 Dify；要快速无代码上线一个对话 agent，选 Coze。
自托管难度上也有明显差别：Dify 和 n8n 都被评价为非常适合自托管，而 Coze 的自托管版本要复杂得多。如果你的诉求是”自己跑一套”，前两者的路径要顺畅得多。
还有一个值得注意的组合：第三方评测里被反复提到的生产级搭配是两者并用——n8n 负责集成与路由，Dify 负责 AI 推理。这个组合的成本含义是，你可能需要维护两套自托管服务，运维负担翻倍，但换来的是各司其职、不用在一个平台里硬扛它不擅长的活。值不值得，取决于你的场景是不是真的两头都重。三者的横向差异，Coze vs Dify vs n8n 怎么选？数字员工平台横评里拆得更细。
顺带说 Dify 这边的成本结构：它的自托管社区版是完全免费的，因为它接的是你自己的模型 API key，成本纯按你的实际用量走；云版有免费档，付费档的起价在第三方评测里有提及，但那不是官方定价，具体请以 Dify 官网当前定价页为准。想先跑通再算账的，可以看 Dify 教程。
模型调用这一头，还有个前提要说清楚
自托管解决的是”工作流引擎跑在哪”，解决不了”大模型从哪来”。你的 AI 节点最终还是要去调某家厂商的接口，这里有两件事得诚实面对：
一是费用。token 消耗跟部署方式完全无关，自托管一分也省不掉。如果你的成本压力主要来自模型调用而不是平台订阅，那迁移部署方式基本是白折腾——该优化的是提示词长度、调用次数、模型档位选择。
二是可达性。主流的几家海外模型厂商官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，具体以各自官网当前的地区政策页为准。市面上确实存在第三方中转服务，但其合规性与稳定性风险由使用者自行承担，本文不提供也不背书任何具体渠道。做技术选型时把这个前提摆在前面，比做到一半才发现流程跑不通要好。
如果你的工作流里要接知识库检索，n8n RAG 知识库那篇讲了具体搭法，那类流程的模型调用量通常比纯自动化流程高不少，算账时要单独估。
诚实说局限
这篇文章里的量级参考来自第三方评测的测算，不是官方口径，也不可能覆盖你的具体情况。真实成本受几个变量影响很大：你在哪买服务器、你的流程单次跑多久、你的人力成本怎么折算、你要不要为合规买企业版功能。所以本文给的是算账的框架，不是一个能直接套用的结论数字。
另外，价格和额度是会调的。任何一篇写于某个时间点的对比文章，其中的具体金额都有过期风险——包括这一篇。真正下决定之前，请打开各家官网当前的定价页自己看一眼，用你上个月的真实执行量代进去算。
最后一句提醒：不要把”自托管”当成一个不可逆的决定。相当多的团队走的是”先用云版把流程跑顺、量级和价值都验证了，再迁到自托管”的路径。反过来，一上来就自建、结果流程只跑了三条、服务器空转半年的团队也不少见。先把业务价值验出来，再谈省钱，顺序别搞反。
小结
自托管 n8n 不收授权费，但服务器、运维人力、模型调用这三笔钱一分不少，其中运维时间是最容易被低估的一项。云版按执行次数计价，低档额度紧，高频自动化会阶跃式变贵，这才是自托管最实在的省钱点。第三方测算给出的参考门槛在每月十万次操作以上的量级，年省额是几千美元的数量级——先去后台看真实执行量再对照，别凭感觉。数据不出内网、要接内网系统、要深度定制，这三条比省钱更硬，占了任意一条就不用纠结成本。没到量级、也不占这三条的话，把订阅费花掉、把时间省下来做业务，通常是更划算的选择。