自托管 n8n 替代方案对比：许可证、内存与备份

n8n 的替代方案

在 VPS（虚拟专用服务器）上自行托管时，值得考虑的 n8n 替代方案包括 Activepieces、Windmill、Node-RED、Automatisch 和 Huginn。Activepieces 最接近大多数人使用 n8n 的方式，其核心组件采用 MIT 许可证。Windmill 适合更愿意编写 Python 或 TypeScript，而不是在画布上拖拽模块的团队。Node-RED 规模较小，完全不需要数据库。

许多读者其实无需迁移。n8n 的许可证允许内部业务使用，因此如果您只为自己的公司运行工作流，许可证不是问题。迁移也并不简单。此列表中的任何工具都无法读取 n8n 导出文件，因此您必须手动重建每个工作流，并重新输入每个凭据。n8n 本身的安装是另一项工作，详见 在 VPS 上使用 Docker 和 HTTPS 安装 n8n；n8n 与 Zapier 和 Make 的对比介绍了这类工具与托管服务的整体差异。

为什么人们寻找可自行托管的 n8n 替代方案

原因主要有两个。

第一个原因是许可证。n8n 采用 Sustainable Use License v1.0 发布，项目方将其称为 fair-code，而不是开源软件。该许可证规定，软件只能“用于您自己的内部业务，或用于非商业或个人用途”，并禁止以商业方式向其他人提供该软件。名称中包含 .ee 的文件和目录受单独的 n8n Enterprise License 约束。如果您希望代表付费客户运行自动化，这就是一个硬性限制。如果您属于内部运营团队，则不会改变日常使用方式。

第二个原因是内存。n8n 是一个 Node.js 进程，工作流运行期间，工作流数据会驻留在内存中。n8n 文档列出了相关原因：JSON 数据量、二进制数据大小、工作流中的节点数量、Code 节点、手动执行（编辑器会再次复制数据），以及同时运行的其他工作流。文档建议的解决方案不是更换产品，而是使用队列模式和独立的 worker 进程，并使用 Postgres 代替默认的 SQLite 文件（位于 ~/.n8n/database.sqlite）。大型任务还需要进行批处理，因为向子工作流传递数据的 Loop Over Items 节点，每次只会将一部分数据保留在内存中。在将六十个工作流迁移到其他平台之前，先尝试这种方案。

仍在维护的自托管 n8n 替代方案有哪些

许可证文本易于阅读，因此人们通常都会比较许可证。项目的维护状态却很容易被忽略。本比较包含 6 个项目，下面列出每个项目截至 4 August 2026 发布的最新标记版本。

[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.33.3",
    "released": "2026-07-31",
    "days_since_release": 4
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.86.3",
    "released": "2026-07-17",
    "days_since_release": 18
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.778.0",
    "released": "2026-08-04",
    "days_since_release": 0
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.4",
    "released": "2026-07-30",
    "days_since_release": 5
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 361
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2022.08.18",
    "released": "2022-08-18",
    "days_since_release": 1447
  }
]

有两行会改变候选名单。Automatisch 最近一次标记发布版本是在 v0.15.0，距今已有 361 天；其默认分支自 15 January 2026 起没有提交。Huginn 最近一次标记发布版本是在 1447 天前，但其提交日志本月仍然活跃。这正好相反：代码在持续更新，但没有发布版本，因此运行它就意味着运行未标记的镜像。

在信任任何比较结果之前，包括本比较，请先自行核实。打开该项目在 GitHub 上的 releases 页面，然后查看其默认分支的提交列表。发布版本较新但提交日志很安静的项目，说明维护活动可能已经停滞。提交持续更新但多年没有发布版本的项目，则意味着你需要运行一段没有人正式切出版本的代码。

Activepieces：最接近的选择，核心采用 MIT 许可证

Activepieces 是功能最接近的选择。它是一个可视化构建器，使用触发器和步骤来编排流程，并将步骤称为 pieces。README 声称目前提供超过 280 个 pieces。每个 piece 也都作为 MCP（模型上下文协议）服务器提供，因此 LLM（大语言模型）客户端可以将相同的连接器作为工具调用。其核心采用 MIT 许可证。packages/ee/ 和 packages/server/api/src/app/ee 两个目录采用商业许可证；在自己的服务器上使用其中的内容需要签署付费协议。

迁移前应先了解这种拆分，因为它比大多数 MIT 项目更严格。Activepieces 的定价页面将 Community Edition 描述为“开源、永久免费，运行次数、用户数和流程数均不设上限”，但将 Agents and Chat、Projects、API 访问以及完整的管理层排除在外，其中包括单点登录、用户角色、审计日志、密钥管理器、品牌设置和 Git 同步。因此，Community Edition 是一个流程数和用户数均不受限的完整自动化引擎，但不是一个可以通过 API 驱动的平台。如果您计划以编程方式生成流程，就需要相应的许可证。

其运行时架构包括一个应用容器、一个或多个工作器容器、Postgres 和 Redis。AP_DB_TYPE=POSTGRES 和 AP_REDIS_TYPE=STANDALONE 是默认配置。它还提供单容器模式，其中包含内置数据库和进程内队列（AP_DB_TYPE=PGLITE 与 AP_REDIS_TYPE=MEMORY），文档明确说明该模式“仅用于个人使用或测试”。请按此说明使用这些模式。它们无法运行多个实例，因此从这些模式扩展出来时需要执行迁移，而不是修改一个标志。

Windmill：代码优先，实际负载比表面更重

Windmill 可以运行 Python、TypeScript、Go、Bash 和 SQL 脚本，然后将它们组合成流程。如果您的自动化主要由代码构成，只需要少量胶水逻辑，那么它比任何节点画布都更合适。

许可协议需要仔细确认。未启用 enterprise feature flag 编译时，源代码采用 AGPLv3。ghcr.io/windmill-labs/windmill 发布的镜像属于 Community Edition，其中包含不属于开源范围的代码，并且可在配额内免费使用。Windmill 的定价页面将配额设为 50 个用户、3 个 workspace 和 10 GiB 的 workspace 对象存储，执行次数不限。对于一个人或一个小团队来说，这个上限通常很难达到，因此实际需要关注的不是配额，而是您运行的二进制文件并不是 AGPL 构建版本。

另一个需要考虑的因素是资源占用。Windmill 自带的 docker-compose.yml 包含一个 Postgres 16 数据库、一个服务器、3 个默认 worker，每个 worker 的内存限制为 2048M，以及一个 native worker 和一个 Caddy 代理。文档给出的经验规则是“每 1vCPU 配置 1 个 worker，并分配 1-2 GB RAM”。在配置较小的服务器上，您可以减少副本数量。但应明确这是主动减少了副本，因为真正执行作业的是这些 worker。

Windmill 的 AI 功能文档将其定位为构建时辅助功能，包括代码生成、流程构建、聊天和表单填充。您必须先在 workspace 设置中添加 model provider resource。如果您需要的是一个按计划运行并调用工具的 agent 步骤，n8n 的 AI Agent 节点仍然更直接；在 n8n 中构建 AI agent介绍了这种用法。

Node-RED：轻量方案，完全不使用数据库

Node-RED 采用 Apache 2.0 许可证，是本次比较中限制最少的许可证。它只是一个 Node.js 进程，使用 /data 卷。不需要 Postgres，也不需要 Redis。将其固定为 nodered/node-red:5.0.4，这是当前版本。

Node-RED 起源于 IoT（物联网）流程编排，因此它以事件为核心，而不是以连接器为核心。第三方服务的节点来自社区库，质量不一；这是选择小型部署规模所需付出的代价。它没有内置的 AI agent 步骤。对于处理 webhook 和消息队列流量的小型 VPS，这是本列表中能够正常工作的最轻量方案，并且可在数秒内启动。

Huginn 和 Automatisch：先检查提交日志

Huginn 采用 MIT 许可证，使用 Ruby on Rails 编写，需要 MySQL 或 PostgreSQL。它以 agent 为核心：监视数据源并发出事件。这与流程画布是不同的模型，而且没有 LLM 相关能力。代码仍在提交更新，但最近一次带标签的版本发布于 2022 年 8 月。因此，运行它意味着使用从默认分支构建的 ghcr.io/huginn/huginn 镜像。只有在 agent 模型符合您的问题时才选择它，不要把它当作通用的 n8n 替代方案。

Automatisch 除 .ee 文件外采用 AGPL-3.0 许可证，看起来像一个更简单的 n8n：使用 Postgres、Redis，以及一个规模较小的应用目录。许多单机部署教程都在推荐它。发布历史表明应当等待。一年没有发布版本、半年没有提交，如果您已经在运行它，不足以构成恐慌理由；但这足以说明不应在它之上启动新的生产部署。

Activepieces 堆栈实际需要多少 RAM

无法替您发布服务空闲和运行时的实测内存，因为这取决于您自己的流程及其处理的数据量。您能参考的是各供应商建议预留的资源。Activepieces 给出了以下配置，旁边的说明比数字更重要：“并发数为 1 的 worker 会在整个流程执行期间处于忙碌状态（最长 10 min），因此应根据并发流程数而不是触发频率进行规划。”

[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

一个 worker 使用 0.5 个 vCPU 和 1 GB 内存，并且一次只运行一个流程。Postgres 按 4 GB 规划。项目自带的 compose 文件会启动 5 个 worker 副本，因此按该配置计算，在流程实际处理任务之前，代码仓库中的堆栈就需要大约 11 GB 内存。单工具教程会直接复制这个文件，然后称其为小型部署。

在 4 GB VPS 上运行 2 个 worker，让 Postgres 保持在同一个 compose 项目中，然后进行测量。docker stats --no-stream 会为每个容器输出一行实际常驻内存，这比供应商或博客发布的任何数据都更可靠。如果某个容器的内存持续增长且没有上限，请为其设置限制；Docker Compose 中的内存限制介绍了具体语法。

单台 VPS 上用于 Activepieces 的 compose 文件

固定版本标签。latest 表示下一个 docker compose pull 可能会在没有警告的情况下修改数据库架构。根据项目截至 4 August 2026 在其自有 compose 文件中固定的版本，0.86.3 是应使用的版本。

先生成两个密钥，并使用文档规定的长度。

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

将 .env 写入 compose 文件所在目录：

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=false

AP_FRONTEND_URL 必须是公开的 HTTPS 地址，否则 Activepieces 在生成 webhook URL 时会尝试使用您的公网 IP 地址。您提供给第三方的每个 webhook 都会根据该值生成。因此，如果该值仍指向 localhost，您粘贴到其他服务中的 URL 就无法到达服务器。

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

该文件基于项目自有的 compose 文件，并做了四项修改：worker 数量从 five 降为 two；发布端口绑定到 127.0.0.1，而不是所有网络接口；删除固定容器名称，因为使用副本的服务不能使用固定名称；删除显式网络配置，因为 compose 会自动创建网络。

docker compose up -d
docker compose ps

每个服务都应显示 Up，其中包括两个 worker 容器。循环重启的容器会在 docker compose logs worker 中输出原因，因此先查看该信息，再进行任何修改。端口绑定意味着，在前面配置带 TLS（传输层安全）的反向代理之前，外部请求无法访问应用。在多个 compose 应用前运行 Traefik对此有说明。将 .env 的权限保持为 mode 600，并按照在 compose 环境文件中管理密钥的方式将其排除在 git 之外。

遗漏在所有指南中的备份

所有这些工具都会加密存储的凭据，因此单独备份数据库转储文件并不构成备份。您需要同时备份转储文件和用于解密它的密钥。问题在于，这些工具大多会自动生成密钥，而且不会明确提示您；它们还会将密钥存放在您没有备份的位置。

n8n 是最典型的例子。如果您从未设置 N8N_ENCRYPTION_KEY，n8n 会“在首次启动时自动创建一个随机加密密钥，并将其保存到 ~/.n8n 文件夹”，然后使用该密钥在凭据写入数据库前对其进行加密。您将 Postgres 转储恢复到使用新卷的新容器后，工作流会恢复，但所有凭据都会变成无人能够读取的密文。请显式设置该变量；以队列模式运行时，请在每个 worker 上设置相同的值。

Node-RED 的情况相同。凭据存储在单独的加密文件中，密钥位于 settings.js 的 credentialSecret 中。如果您没有设置密钥，运行时会生成一个随机密钥，并将其保存到自身设置存储中的 /data 下的 _credentialSecret。默认设置文件明确说明了后果：“一旦设置此属性，请勿更改它；否则 node-red 将无法解密现有凭据，这些凭据将丢失。”请备份整个 /data 卷，而不只是 flows 文件。

Activepieces 将 AP_ENCRYPTION_KEY 保存在您的 .env 中，文档将其定义为“用于加密连接的 32-character (16-byte) hexadecimal key”。Huginn 将 APP_SECRET_TOKEN 保存在其环境中。Automatisch 有 3 个此类变量：ENCRYPTION_KEY、WEBHOOK_SECRET_KEY 和 APP_SECRET_KEY。在每种情况下，密钥都存储在环境文件中，因此环境文件也是备份的一部分。

值得注意的是，Windmill 是个例外。它使用工作区专用的对称密钥加密变量和密钥，并将该密钥存储在自己的数据库中，因此单个 Postgres 转储同时包含密文和密钥。这便于恢复，但也意味着仅凭转储文件就能读取所有密钥，因此应像保护这些密钥本身一样保护该文件。

对于上面的 Activepieces 堆栈，备份包含 2 个文件：

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

然后验证备份确实有效，因为未经测试的备份只是猜测。将转储恢复到临时 compose 项目中，并在其中故意使用不同的 AP_ENCRYPTION_KEY；然后运行一个使用已保存连接的工作流。该工作流会失败，因为数据库中的密文是使用另一个密钥生成的。使用 .env 中的真实密钥再次恢复后，同一个工作流即可运行。这两次运行是唯一能证明您的备份确实可用的证据。请按计划将这两个文件发送到服务器之外，并使用 来自 VPS 的 restic 备份，因为存放在同一磁盘上的备份会随磁盘一起丢失。

何时继续使用 n8n

如果工作仅供您自己的公司内部使用，就可以继续使用，因为这正是 Sustainable Use License 允许的范围。如果您依赖功能广度，也可以继续使用：n8n 声称支持超过 1500 个集成；其基于 LangChain 构建的 AI Agent 节点，在现成代理步骤方面也是这里其他方案无法匹敌的。使用 Claude 驱动 n8n 工作流展示了实际使用方式。

如果您希望自动化核心采用宽松许可证，并且整个技术栈都可读懂，可以迁移到 Activepieces。如果您的流程本质上是套着用户界面的代码，可以迁移到 Windmill。如果设备规模较小，工作以事件处理为主，可以迁移到 Node-RED。不要因为某项基准测试称 n8n 资源占用较高就迁移。先测量您自己的实例，再阅读2026 年值得自行托管的内容并一次性做出选择，因为第二次迁移的成本与第一次相同。

FAQ

哪个自托管 n8n 替代方案与 n8n 最接近？

Activepieces。它们的理念相同：通过可视化构建器创建流程，由触发器启动流程，每个步骤调用一个服务，并提供大量连接器。其核心采用 MIT 许可证，在 Docker 中使用 Postgres 和 Redis 运行，其 pieces 还可作为 LLM 客户端的 MCP 服务器。需要注意的是，API 访问和代理功能属于商业版企业目录，因此 Community Edition 实例需要通过 Web 界面操作，而不能通过编程方式驱动。

Activepieces 真的是开源的吗？

核心部分是，采用 MIT 许可证。packages/ee/ 和 packages/server/api/src/app/ee 两个目录采用商业许可证，在自己的服务器上使用其中的功能需要付费许可证。供应商的定价页面显示，Agents and Chat、Projects、API 访问、单点登录、用户角色、审计日志、密钥管理器、品牌定制和 Git 同步均不属于 Community Edition，但运行次数、用户数和流程数不设上限。因此，它在构建和运行自动化方面是真正开源的，但团队和治理层不是开源的。

Activepieces 在 VPS 上需要多少 RAM？

Activepieces 的文档建议每个 worker 使用 0.5 vCPU 和 1 GB，每个 app 容器使用 1 vCPU 和 1 GB，Postgres 使用 4 GB，Redis 使用 1 GB。一个 worker 在某个流程的整个运行期间一次只处理一个流程，因此应根据峰值并发流程数，而不是根据触发器触发频率进行配置。仓库中的 compose 文件会启动五个 worker，按文档配置计算约为 11 GB。对于 4 GB VPS，先运行两个 worker 是合理的做法；流程运行期间使用 docker stats --no-stream 可确认实际用量。

要备份哪些内容，才能确保恢复真正有效？

数据库转储和加密密钥必须同时备份。对于 Activepieces，需要备份 activepieces 数据库的 pg_dump，以及保存 AP_ENCRYPTION_KEY 的 .env 文件。对于 n8n，需要备份数据库和 N8N_ENCRYPTION_KEY；如果从未自行设置该文件，n8n 会在 ~/.n8n 目录中为您生成它。对于 Node-RED，应备份整个 /data 卷，因为凭据文件和用于解密凭据的密钥都位于其中。Windmill 是例外：其工作区密钥位于自身的 Postgres 数据库中，因此转储包含全部内容，必须像保护密钥本身一样妥善保护。

可以将 n8n 工作流导入其他工具吗？

不可以。这些项目只能导入和导出自己的流程格式，不能导入 n8n 的格式。迁移意味着在新的构建器中重新创建每个流程，并根据原始服务重新创建每个凭据。这是切换工具的实际成本，因此应在决定前统计流程数量。12 个流程通常一个下午即可完成。200 个流程则是一项正式迁移项目；与全部重建相比，通常通过 queue mode 和 Postgres 修复 n8n 的内存使用问题更划算。