自架 n8n 替代方案比較：授權、RAM 與 AI

n8n 的替代方案

在 VPS（virtual private server）上值得考慮的自架 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，而不是 open source。此授權允許「僅為自己的內部業務目的，或供非商業或個人用途使用或修改軟體」，並禁止以商業方式向他人提供軟體。名稱含有 .ee 的檔案與資料夾，則受獨立的 n8n Enterprise License 規範。如果你想代表付費客戶執行自動化，這項限制會直接阻止你這麼做。如果你是內部營運團隊，則不會影響日常使用。

第二個原因是記憶體。n8n 是 Node.js 程序，工作流程執行期間，工作流程資料會存放在記憶體中。n8n 文件列出的原因包括 JSON 資料量、二進位資料大小、工作流程中的節點數量、Code node、手動執行（編輯器會再次複製資料），以及同時執行的其他工作流程。文件建議的修正方式不是改用其他產品，而是啟用 queue mode 並使用獨立的 worker processes，另外以 Postgres 取代預設位於 ~/.n8n/database.sqlite 的 SQLite 檔案。大型工作也需要分批處理，因為由 Loop Over Items node 將資料送入 sub-workflow 時，記憶體一次只會保留一個資料片段。先採用這些方式，再決定是否要在其他平台重新建立 60 個工作流程。

哪些自架 n8n 替代方案仍在維護

授權條款容易閱讀，因此大家都會比較授權條款。專案健康狀況卻很容易被忽略。以下是本次比較中的 6 個專案，以及各專案截至 2026 年 8 月 4 日最新的標記版本。

[
  {
    "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 天，而且其預設分支自 2026 年 1 月 15 日起就沒有提交。Huginn 上次標記版本是在 1447 天前，但其提交記錄本月仍然活躍。這是相反的情況：程式碼持續變動，但沒有發布版本，因此執行它就代表執行未標記版本的映像。

在信任任何比較結果之前，包括本比較在內，都應自行確認。先在 GitHub 開啟該專案的 releases 頁面，再開啟其預設分支的提交清單。剛發布版本但提交記錄沉寂的專案，表示目前只是依賴既有成果運作。持續有新提交、但數年沒有發布版本的專案，等於要求你執行尚未有人切出版本的程式碼。

Activepieces：最接近的選擇，核心採用 MIT 授權

Activepieces 是功能最接近的選擇。它提供具備觸發程序與步驟的視覺化建構器，並將這些步驟稱為 pieces；README 宣稱提供超過 280 個 pieces。每個 piece 也會公開為 MCP（model context protocol）伺服器，因此 LLM（large language model）用戶端可以將相同的連接器當作工具呼叫。核心採用 MIT 授權。packages/ee/ 和 packages/server/api/src/app/ee 這兩個目錄採用商業授權；在自己的伺服器上使用其中內容，需要付費協議。

移轉前請先確認這項授權區分，因為它比多數 MIT 專案更廣。Activepieces 的定價頁面將 Community Edition 描述為「開放原始碼、永久免費，執行次數、使用者或流程均無上限」，並將 Agents and Chat、Projects、API 存取權，以及完整的管理層（single sign-on、使用者角色、稽核日誌、secret managers、品牌設定、Git sync）排除在外。因此，Community Edition 是具備不限流程與使用者的完整自動化引擎，但不是可透過 API 操作的平台。如果你的計畫是以程式產生流程，就需要取得授權。

其執行架構包含一個應用程式容器、一個以上的 worker 容器、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 指令碼，再將它們組合成流程。如果你的自動化工作大多是程式碼，只需要少量串接邏輯，Windmill 會比任何節點畫布更適合。

授權條款需要特別留意。在未啟用 enterprise feature flag 編譯時，原始碼採用 AGPLv3。發布於 ghcr.io/windmill-labs/windmill 的映像檔是 Community Edition，其中包含非開放原始碼的程式碼，且可在配額內免費使用。Windmill 的定價頁面將配額設定為 50 位使用者、3 個工作區及 10 GiB 的工作區物件儲存空間，執行次數不限。對單一使用者或小型團隊而言，通常不會接近這個上限，因此實際問題不在配額，而在於你執行的二進位檔不是 AGPL build。

負載是另一項考量。Windmill 自家的 docker-compose.yml 會提供 Postgres 16 資料庫、1 台伺服器、3 個預設 worker（每個設有 2048M 的記憶體限制）、1 個 native worker，以及 Caddy proxy。文件提供的經驗法則是「每 1vCPU 配置 1 個 worker，並配置 1-2 GB RAM」。在小型主機上，你可以降低 replica 數量。但應清楚知道自己正在降低它，因為實際執行工作的是 workers。

Windmill 的 AI 功能文件將其定位為建置時的輔助工具，包括程式碼產生、流程建立、聊天及表單填寫。你必須先在工作區設定中新增 model provider resource。如果你要的是一個依排程執行並呼叫工具的 agent step，n8n 的 AI Agent node 仍是更直接的選擇，而 在 n8n 建立 AI agent 涵蓋了這種架構。

Node-RED：輕量方案，完全不需要資料庫

Node-RED 採用 Apache 2.0 授權，是這項比較中限制最少的授權。它只需執行一個 Node.js 程序，搭配 /data volume。沒有 Postgres，也沒有 Redis。將版本固定為 nodered/node-red:5.0.4，這是目前的版本。

Node-RED 源自 IoT（internet of things）配線，因此以事件為核心，而不是以連接器為核心。第三方服務的節點來自社群函式庫，品質各異；這是採用小型部署所需付出的取捨。它沒有原生的 AI agent 步驟。對於處理 webhook 與 message queue 流量的小型 VPS，這是其中最輕量且能正常運作的方案，啟動只需幾秒。

Huginn 與 Automatisch：先查看提交記錄

Huginn 採用 MIT 授權，以 Ruby on Rails 撰寫，並需要 MySQL 或 PostgreSQL。它以代理程式為核心，監控來源並產生事件。這與流程畫布是不同的模型，而且沒有 LLM 方案。程式碼仍有提交，但最近一次標記版本發布於 August 2022。因此，執行它代表使用以預設分支建置的 ghcr.io/huginn/huginn 映像檔。只有在代理程式模型符合問題需求時才選用它，不要把它當成通用的 n8n 替代方案。

Automatisch 除了 .ee 檔案外，採用 AGPL-3.0 授權，看起來像較簡化的 n8n：使用 Postgres、Redis，以及小型應用程式目錄。許多單次部署教學都推薦這項工具。發布歷史顯示目前應等待。若已在執行中，長達一年未發布版本、半年未提交程式碼並不代表需要恐慌；但這表示不應以它開始新的正式環境部署。

Activepieces stack 實際需要多少 RAM

無法替你提供 Activepieces stack 閒置及執行時的實際記憶體用量，因為這取決於你自己的 flow，以及 flow 所處理的資料量。你能參考的是各家供應商建議預留的資源。Activepieces 以下列出配置方式，而旁邊這句說明比數字更重要：「concurrency-1 worker 會在 flow 的整個執行期間保持忙碌（最長 10 min），因此應依同時執行的 flow 數量配置，而不是依 trigger 速率配置。」

[
  {
    "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 記憶體，而且一次只會執行一個 flow。Postgres 配置為 4 GB。該專案的 compose file 會啟動 5 個 worker replica，因此依此配置，repository 中的 stack 在 flow 開始處理實際工作前，就約需要 11 GB。單一工具的教學會直接複製這個 file，並將其稱為小型部署。

在 4 GB VPS 上執行 2 個 worker，讓 Postgres 保持在同一個 compose project 中，然後進行測量。docker stats --no-stream 會為每個 container 輸出一行，顯示實際常駐記憶體用量，比供應商或部落格發布的任何數字都可靠。如果 container 無限制成長，請為它設定上限；Docker Compose 的記憶體限制 說明設定語法。

單一 VPS 上的 Activepieces compose 檔案

固定 tag。latest 表示下一個 docker compose pull 可能在未通知的情況下變更資料庫結構。版本 0.86.3 是截至 4 August 2026，專案在自己的 compose 檔案中固定使用的版本。

先依照文件指定的長度產生 2 個 secret。

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

在 compose 檔案旁建立 .env：

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 檔案，包含 4 項變更：worker 數量從 5 降為 2、發佈的連接埠改為繫結至 127.0.0.1，而不是所有介面、移除固定的容器名稱（因為具有 replicas 的服務無法使用固定名稱），以及移除明確的 network 區塊（因為 compose 會自行建立 network）。

docker compose up -d
docker compose ps

每個服務都應顯示 Up，其中包括 2 個 worker 容器。容器持續重啟時，docker compose logs worker 會顯示原因，因此在進行任何變更前先查看該資訊。這項連接埠繫結設定表示，在前方放置使用 TLS（transport layer security）的反向代理之前，外部無法連線至應用程式。在多個 compose 應用程式前方執行 Traefik 說明了相關作法。請將 .env 的權限設為 mode 600，並如 處理 compose env 檔案中的 secret 所示，避免將其加入 git。

每份指南都省略的備份

這些工具都會加密儲存的憑證，因此單獨備份資料庫傾印檔並不算備份。你需要資料庫傾印檔，以及能解密該檔案的金鑰。問題在於，多數工具會自動產生這把金鑰，而且不會明確提示，還會將它儲存在你沒有備份的位置。

n8n 是最明顯的例子。如果你從未設定 N8N_ENCRYPTION_KEY，n8n「會在首次啟動時自動產生隨機加密金鑰，並將其儲存在 ~/.n8n 資料夾中」，接著使用該金鑰，在憑證寫入資料庫前先進行加密。將 Postgres 傾印後，還原至使用新 volume 的全新容器，工作流程會恢復，但所有憑證都會變成無法讀取的密文。請明確設定該變數；使用 queue mode 時，請在每個 worker 上設定相同的值。

Node-RED 也是相同的情況。憑證會儲存在個別的加密檔案中，而金鑰位於 credentialSecret 的 settings.js。如果你未設定金鑰，runtime 會產生隨機金鑰，並將其儲存在自身設定儲存區中的 _credentialSecret，該儲存區位於 /data 內。預設 settings 檔案明確說明後果：「設定此屬性後，請勿變更它；否則 node-red 將無法解密現有憑證，而這些憑證也會遺失。」請備份整個 /data volume，而不只是 flows 檔案。

Activepieces 會將 AP_ENCRYPTION_KEY 儲存在你的 .env 中，文件將其描述為「用於加密 connections 的 32-character (16-byte) hexadecimal key」。Huginn 會將 APP_SECRET_TOKEN 儲存在其環境中。Automatisch 有 3 個這類設定：ENCRYPTION_KEY、WEBHOOK_SECRET_KEY 和 APP_SECRET_KEY。在每個案例中，secret 都位於 environment file 中，因此該 environment file 也是備份的一部分。

Windmill 是值得了解的例外。它會使用 workspace 專用的對稱金鑰加密 variables 和 secrets，並將該金鑰儲存在自己的資料庫中，因此單一 Postgres 傾印檔同時包含兩者。這對還原很方便，但也表示只要有傾印檔，就足以讀取所有 secret，因此請將該檔案視同 secrets 本身加以保護。

對於上述 Activepieces stack，備份包含 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

接著驗證備份是否有效，因為未經測試的備份只是猜測。將傾印檔還原至 scratch compose project，並刻意使用不同的 AP_ENCRYPTION_KEY，然後執行使用已儲存 connection 的 flow。該 flow 會失敗，因為資料庫中的密文是使用另一把金鑰產生的。再次使用 .env 中的實際金鑰進行還原，並執行相同的 flow；這次應能成功執行。這兩次執行結果，是唯一能證明你的備份確實可用的依據。請依排程將這 2 個檔案傳送到伺服器外部，使用 來自 VPS 的 restic backups，因為儲存在同一顆磁碟上的備份，會隨磁碟故障一併遺失。

何時應繼續使用 n8n

如果工作範圍僅限於自家公司內部，應繼續使用 n8n，因為這正是 Sustainable Use License 所允許的用途。如果你重視整合廣度，也應繼續使用 n8n；n8n 宣稱支援超過 1500 個整合，並提供以 LangChain 建置的 AI Agent 節點。在現成的 agent 步驟方面，這裡沒有其他工具能與它相比。使用 Claude 驅動 n8n 工作流程 展示了實際運作方式。

如果你希望自動化核心採用寬鬆授權，並且能從頭到尾讀懂整個技術堆疊，請改用 Activepieces。如果你的流程本質上是套著使用者介面的程式碼，請改用 Windmill。如果主機資源有限，且工作以事件為核心，請改用 Node-RED。不要只因為 benchmark 顯示 n8n 很耗用資源就遷移。先測量自己的執行個體，再閱讀2026 年值得自行代管的項目並做出選擇，因為第 2 次遷移的成本與第 1 次相同。

FAQ

哪個自架的 n8n 替代方案最接近 n8n？

Activepieces。它採用相同概念：由觸發條件啟動流程，再由每個步驟呼叫服務，並提供大量連接器。其核心採用 MIT 授權，可在 Docker 下搭配 Postgres 和 Redis 執行，且其 pieces 也能作為 LLM 用戶端的 MCP servers。需要注意的是，API 存取和 agent 功能位於商業 enterprise 目錄中，因此 Community Edition 執行個體必須透過 Web 介面操作，而不是以程式方式操作。

Activepieces 真的是開放原始碼嗎？

核心部分採用 MIT 授權。packages/ee/ 和 packages/server/api/src/app/ee 這兩個目錄採用商業授權，在自己的伺服器上使用其中的功能需要付費授權。供應商的定價頁面將 Agents and Chat、Projects、API access、single sign-on、user roles、audit logs、secret managers、branding 和 Git sync 列在 Community Edition 之外，但 runs、users 和 flows 沒有上限。因此，Activepieces 確實是開放原始碼的自動化建置與執行工具，但團隊與治理層則不是開放原始碼。

Activepieces 在 VPS 上需要多少 RAM？

Activepieces 的文件指出，每個 worker 需要 0.5 vCPU 和 1 GB，每個 app container 需要 1 vCPU 和 1 GB，Postgres 需要 4 GB，Redis 需要 1 GB。worker 會在一個流程的完整執行期間一次處理一個流程，因此應依尖峰同時執行的流程數量估算，而不是依觸發條件的觸發頻率估算。儲存庫中的 compose file 預設啟動五個 worker，依公開的規格估算約需 11 GB。從 4 GB VPS 配置兩個 worker 是合理的起點，執行流程時使用 docker stats --no-stream 即可確認實際需求。

若要讓還原確實成功，必須備份哪些內容？

必須同時備份資料庫 dump 和 encryption key。對 Activepieces 而言，這包括 activepieces 資料庫的 pg_dump，以及存放 AP_ENCRYPTION_KEY 的 .env 檔案。對 n8n 而言，則是資料庫加上 N8N_ENCRYPTION_KEY；如果從未自行設定，n8n 會在 ~/.n8n 資料夾中為你產生該檔案。對 Node-RED 而言，請備份整個 /data volume，因為 credentials file 和用於解密該檔案的 key 都位於其中。Windmill 是例外：它的 workspace key 位於自己的 Postgres 資料庫中，因此 dump 已包含所有內容，但仍必須將其視同 secrets 本身加以保護。

可以將 n8n workflows 匯入其他工具嗎？

不行。這些專案只能匯入和匯出自己的 flow 格式，無法匯入 n8n 的格式。遷移時，必須在新的 builder 中重新建立每個 flow，並根據原始服務重新建立每組 credential。這才是切換工具的實際成本，因此決定前應先清點 flows。12 個 flows 只需一個下午。200 個 flows 就是一項專案；通常啟用 queue mode 和 Postgres 來改善 n8n 的記憶體使用量，會比全部重建更划算。