Make vs n8n：部署方式、许可证与计费模式对比

Make.com 和 n8n 都是工作流自动化平台，经常被放在一起比较。但它们最关键的差别不在“谁的功能更多”，而在几个更基础的问题：平台由谁托管、软件按什么许可证使用、出问题时由谁维护、按什么方式计费，以及哪些功能需要更高计划。

这篇对比不做“二选一”的能力排名。下面给出的是判断条件；具体功能、额度与价格会随时间变化，请以各自官方页面为准。

这篇适合谁

这篇适合正在为个人、小团队或公司选择自动化平台的人，尤其是已经知道需要“把多个系统连起来”，但还在 Make 和 n8n 之间权衡的人。

你真正要判断的是：团队有没有能力自托管并长期维护；运行环境和数据流向是否需要自己控制；以及你更希望买一个托管服务，还是自己运维一套软件。

先厘清两个常见误解

误解一：n8n 是开源软件。 按照 n8n 官方文档的说明，n8n 的源码公开，但采用 Sustainable Use License（fair-code 模式），并明确表示：因为该许可证对使用场景有限制，不符合 Open Source Initiative（OSI）对开源的定义，所以 n8n 不把自己称为开源软件。该许可证把“使用、修改”和“再分发”分开限制：使用或修改仅限自己的内部业务目的，或非商业、个人用途；把软件分发或提供给别人时，必须免费且用于非商业目的；同时不得删除、隐藏或改动许可证、版权等声明。白标后向客户收费、或托管 n8n 并向他人收费访问，属于官方举出的不被允许示例；而付费的咨询、工作流搭建，以及在内部服务器上部署和维护等支持性服务，在官方 FAQ 中明确属于允许范围。若用途超出许可范围，需要与 n8n 另行签署商业协议。覆盖范围也不是整个仓库：主仓库 master 分支的源码适用该许可证，其他分支的内容以及文件名包含 .ee. 的文件不在此列，后者适用 n8n Enterprise License。

误解二：自托管一定更安全、更省钱。 自托管意味着把运行环境、更新、备份和安全维护交给自己。n8n 官方文档把自托管的基础设施称为“你的责任”，并提醒用户自行完成 TLS、静态数据加密、安全审计和数据删除等工作。许可证可能免费，但服务器、监控、更新和人员投入都是真实成本；安全水平取决于你自己的运维实践，而不是“自托管”这个选择本身。

核心差异一览

维度	Make.com	n8n
部署方式	云端 SaaS，由 Make 托管	可选择 n8n Cloud（由 n8n 托管），或自托管在自己的基础设施上
许可证与商业模式	商业 SaaS 托管服务，按订阅使用，具体条款以官方为准	源码公开，采用 Sustainable Use License（fair-code）；部分文件另受 Enterprise License；官方明确不称自己为 OSI 开源
维护责任	托管平台的基础设施由 Make 运维和更新；你的工作流、连接与账号配置仍由自己负责	云端由 n8n 运维基础设施；自托管由你负责运行环境、更新、备份与安全
计费方式	基于 credit 的用量计费	云端按工作流执行次数计费；自托管 Community 版不收许可费，但需自付基础设施与维护
功能与额度门槛	部分功能和额度取决于所购套餐	功能随部署方式、自托管版本（edition）或 Cloud 计划不同，具体包含项以适用定价页为准
更适合	想快速上手、接受厂商托管平台基础设施、以可视化方式搭建	有技术团队、希望自行控制运行环境与部署，并愿意承担维护责任

表格只描述模式差异，不承诺任何当前价格、额度或功能清单；这些以官方定价页和文档为准。

许可证：不要把它简单称为“开源”

对许多团队来说，许可证是选型时最容易被忽略、事后却最麻烦的一项。

n8n 的官方许可证说明给出了几个明确边界：

覆盖范围：Sustainable Use License 覆盖主仓库源码，但不包括非 master 分支的内容，以及文件名含 .ee. 的源码；其中 .ee. 文件适用 n8n Enterprise License。企业客户也可另行签署商业许可。
使用与修改：仅限自己的内部业务目的，或非商业、个人用途。
再分发：把软件分发或提供给别人时，必须免费且用于非商业目的；不得删除、隐藏或改动许可证、版权等声明。
常见边界：白标后收费、或托管并向他人收费访问不被允许；官方 FAQ 明确允许付费咨询、工作流搭建和内部部署维护等支持性服务。
官方立场：虽然源码公开，但不声称自己是 OSI 开源；fair-code 描述的是一种源码可见、但对商业用途有限制的模式。

Make 是商业 SaaS 服务，你购买的是托管服务的使用权，需要遵守其服务条款和定价约定。

如果许可证合规对你的组织很重要，应直接阅读官方许可证原文并咨询法务，而不是只依赖任何对比文章（包括本页）的转述。

自托管到底意味着什么

自托管的核心价值是对运行环境的控制权：你可以决定部署位置、网络边界、运行配置和自定义程度。但这同时也意味着责任转移。

按 n8n 官方文档，自托管用户需要额外处理的事情包括：配置反向代理和 TLS、保证静态数据加密、运行安全审计、评估社区节点的风险、按需禁用高风险节点，以及自行承担数据删除等义务。官方文档还明确指出，维护（maintenance）在自托管模式下是用户自己的责任。

需要特别区分“运行环境”和“数据流向”：自托管让你控制 n8n 自身的运行环境，但不保证经过它的数据一定留在你的基础设施内。只要工作流调用外部 SaaS、AI API 或发出其他出站请求，相关数据就可能发送到这些服务；数据驻留与合规取决于你对每个连接和网络出口的实际配置，而不是“自托管”这个选择本身。

因此：

如果你需要控制运行环境或部署位置，并已逐项评估连接服务的数据流向，自托管可能值得投入。
如果你没有持续运维能力，云端托管通常能减少基础设施层面的负担。
“把 n8n 放在自己服务器上”不等于“经过流程的数据一定不离开自有基础设施”，也不等于“自动满足安全或合规要求”；这些取决于实际配置、连接服务和流程。

计费与额度

两个平台的计费思路不同，而且都会随计划变化，所以这里只讲模式：

Make 采用基于 credit 的用量计费：非 AI 应用通常 1 次操作计 1 credit，部分 AI 和高级功能会按 token、文件大小或运行时间等动态消耗，因此不同模块和功能的 credit 消耗可能不同（见 Make 帮助中心：Credits）；官方定价页会列出免费计划和各付费计划的当前额度。
n8n Cloud 按工作流执行次数计费；自托管的 Community 版不收许可费，但你需要自己承担服务器、监控、更新等成本。
两边的免费、试用条件、额度上限和功能门槛都可能调整，选型时应看自己的实际账户能否满足需求，而不是只看宣传页上的数字。

适合 Make 的情况

当下面这些条件更符合你的团队时，Make 通常更容易落地：

你希望使用由厂商托管的云平台，不想自行维护服务器和更新。
团队以非技术或低技术背景成员为主，希望用可视化方式搭建流程。
你更看重快速上手，并接受由厂商托管平台基础设施；具体的工作流、集成和支持范围仍以你的套餐和官方条款为准。
你没有必须自行控制运行环境的要求。

需要说明的是，n8n Cloud 同样提供由厂商托管的基础设施；托管与自托管之间的区别并不是 Make 独有的特点。这里列出的是“是否接受托管”这一条件。

适合 n8n 的情况

当下面这些条件更符合时，n8n 更值得评估：

你有技术团队，能够部署、更新并监控一套自托管服务。
需要自行控制运行环境、部署位置或网络边界（并逐项评估连接服务的数据流向）。
你需要深度定制、自定义节点或更贴近代码的控制方式。
你接受“许可免费不等于总成本为零”，并把运维成本纳入预算。

同时使用两者也是一种可选做法：例如用其中一个负责流程编排，用另一个处理特定场景。它不是必须的，本页也不对团队采用频率做统计；选型的关键是哪一个的责任划分和成本结构更适合你。

决策变量

判断时可以依次问四个问题。

1. 谁来维护这套平台？

如果没有人愿意长期负责更新、备份和安全，云端托管通常更稳妥；如果有明确的运维负责人，自托管才具备现实可行性。

2. 运行环境和数据流向是否必须由自己控制？

如果只是希望控制 n8n 的运行环境，自托管提供了这种能力；但如果目标还包括数据不离开自有基础设施，就必须同时审查每个工作流调用的外部服务和出站请求，因为自托管本身并不阻止数据流向第三方 SaaS 或 AI API。

3. 许可证限制是否影响你的使用方式？

如果你打算把平台作为产品的一部分提供给你的客户，或做白标、托管收费这类用途，就必须先确认许可证是否允许；n8n 的官方许可证对这类用途有明确限制，而付费咨询、工作流搭建和内部部署维护通常属于允许范围。

4. 你按什么方式付费？

按 credit 还是按执行次数，会直接影响不同工作负载的成本。应使用官方定价页和实际用量估算，而不是依赖对比文章里的价格数字。

3 个场景

场景一：小团队想快速把表单接到表格和通知

没有专职运维、只想尽快跑通并有人托管时，云端平台通常更省事。先确认所选计划的额度能否覆盖你的运行频率。

场景二：技术团队要自行控制运行环境

有开发和运维能力、且希望自行控制运行环境和部署位置时，自托管更合适。此时应把更新、备份、TLS、访问控制和合规责任一并纳入计划，并逐项确认工作流调用的外部服务会接收哪些数据——自托管只控制运行环境，不会自动阻止数据流出。

场景三：准备把自动化能力嵌入自己的产品

这已经涉及许可证和商业模式。应先阅读官方许可证，确认“内部业务目的”的边界；如果不确定，直接联系厂商确认，而不是按对“开源”的直觉假设。

常见错误

错误一：把“源码可见”当成“可自由商用”

n8n 的官方许可证对商业用途有限制，并明确不称自己是 OSI 开源。做产品化、白标或托管收费前必须先确认许可范围；但也不要因此以为所有付费服务都被禁止——咨询、工作流搭建和内部部署维护在官方 FAQ 中属于允许范围。

错误二：以为自托管自动更安全

自托管的防护水平取决于你的配置和运维。官方文档明确要求用户自行完成加密、审计和数据删除等工作。

错误三：以为自托管就等于数据不会离开

自托管只控制运行环境；只要工作流调用外部 SaaS 或 AI API，数据就可能流出。有数据驻留要求时，必须审查每个连接和出站请求的实际配置，而不是只看部署方式。

错误四：只看许可证是否免费，忽略总成本

自托管省下许可费，但会增加服务器、监控、更新和人员成本；这些都应计入总拥有成本。

错误五：用对比文章里的价格和额度做预算

价格、额度和功能门槛会变化，应直接以官方定价页和账户内的实际限制为准。

错误六：忽略功能门槛

有些功能需要更高计划或付费许可，而且包含项会随部署方式、自托管版本或 Cloud 计划不同。选型时要对照适用的官方定价页，核对“你需要的那几项”在目标部署和计划里是否可用。

下一步

如果你仍不确定，可以这样收敛：

先写下谁负责运维、运行环境和数据流向是否需要自己控制、是否涉及对外提供自动化能力。
再对照官方许可证和定价页，确认目标部署与计划包含你真正需要的功能和额度。
如果倾向自托管，先在一个低风险流程上完成部署、更新和备份演练，并确认它的外部调用会把数据发往哪里，再逐步扩大范围。
如果倾向托管服务，先用免费或试用计划验证工作流和集成是否满足需求。

关于本页的说明

本页只描述两个平台的部署方式、许可证模式和计费思路，不逐条断言当前的连接器数量、价格、额度或某个计划的具体功能；这些会随产品更新和账户、部署方式与计划变化。

Make 的当前计划、额度和功能，请以 Make 官方定价页为准；credit 的计费单位和消耗差异见 Make 帮助中心：Credits。
n8n 的云端与自托管选择、许可证和功能差异，请以 n8n 官方文档：如何选择使用方式、n8n 官方定价页和 Sustainable Use License 说明为准。
自托管的维护与安全事项，请参考 n8n 官方隐私与安全文档。