著者 セルフホスト型n8n代替製品5選を比較
Activepieces、Windmill、Node-RED、Automatisch、Huginnをn8nと比較します。ライセンス、RAM、データベース、AI処理、復元に失敗するバックアップの注意点を確認できます。
n8n の代替として使えるもの
VPS（virtual private server）で利用する価値があるセルフホスト型の n8n 代替製品は、Activepieces、Windmill、Node-RED、Automatisch、Huginn です。Activepieces は、多くのユーザーが n8n を利用する方法に最も近い代替製品で、コア部分には MIT License が適用されています。Windmill は、キャンバス上でボックスを移動するよりも Python や TypeScript を記述したいチームに適しています。Node-RED は小規模で、データベースも必要ありません。
移行せず、現在の環境を使い続けるべき読者も多いでしょう。n8n のライセンスでは社内業務での利用が認められているため、自社向けにフローを実行している場合、ライセンスは問題になりません。移行にもコストがかかります。この一覧にある製品は n8n のエクスポートを読み込めないため、すべてのフローを手作業で作り直し、すべての認証情報を再入力する必要があります。n8n 自体のインストールは別の作業であり、VPS に Docker と HTTPS を使って n8n をインストールする方法で説明しています。また、n8n と Zapier、Make の比較では、このカテゴリ全体とホスト型サービスの違いを説明しています。
セルフホスト型の n8n 代替製品が求められる理由
理由として繰り返し挙がるものは 2 つあります。
1 つ目はライセンスです。n8n は Sustainable Use License v1.0 の下でリリースされており、プロジェクトではオープンソースではなく fair-code と呼んでいます。このライセンスでは、「ソフトウェアを自社の内部業務目的、または非商用もしくは個人用途に限り使用または変更する」権利が認められています。一方、ソフトウェアを他者へ商用提供することは禁止されています。名前に .ee が含まれるファイルとフォルダーには、別の n8n Enterprise License が適用されます。料金を支払う顧客に代わって自動化を実行したい場合、ここが大きな制約になります。社内の運用チームで利用する場合、日常の業務には影響しません。
2 つ目はメモリです。n8n は Node.js プロセスとして動作し、ワークフローの実行中はデータをメモリ上に保持します。n8n のドキュメントでは、原因として JSON データの量、バイナリデータのサイズ、ワークフロー内のノード数、Code ノード、手動実行時の処理（エディター用にデータが再度コピーされます）、同時に実行される他のワークフローを挙げています。公式に示されている対策は、別の製品へ移行することではありません。別々の worker process を使う queue mode と、デフォルトの ~/.n8n/database.sqlite にある SQLite ファイルの代わりに Postgres を使うことです。大規模なジョブではバッチ処理も有効です。Loop Over Items ノードから sub-workflow へデータを渡す構成にすると、データの一部だけを一度にメモリへ保持できます。別の場所で 60 個のフローを作り直す前に、まずこの方法を試してください。
セルフホスト型の n8n 代替製品で、現在も保守されているもの
ライセンスの説明は読みやすいため、誰もがライセンスを比較します。一方、プロジェクトの健全性は確認を省略しがちです。この比較対象は 6 件のプロジェクトです。各プロジェクトで 2026 年 8 月 4 日時点の最新のタグ付きリリースを示しています。
The data behind this chart
[
{
"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
}
]ショートリストを変える行が 2 つあります。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 の 2 つのディレクトリには商用ライセンスが適用されており、その中のコードを自分のサーバーで使用するには有償契約が必要です。
移行前に、このライセンスの分離を確認してください。一般的な MIT プロジェクトよりも分離範囲が広いためです。Activepieces の料金ページでは、Community Edition を「オープンソースで、永久に無料であり、実行回数、ユーザー数、フロー数に上限がない」と説明しています。一方、Agents and Chat、Projects、API アクセス、および管理機能全体（シングルサインオン、ユーザーロール、監査ログ、Secret manager、ブランディング、Git 同期）は Community Edition の対象外です。したがって Community Edition は、フロー数とユーザー数に制限のない完全な自動化エンジンですが、API から操作できるプラットフォームではありません。プログラムでフローを生成する計画だった場合、その計画にはライセンスが必要です。
実行構成は、1 つのアプリケーションコンテナ、1 つ以上のワーカーコンテナ、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 でスクリプトを実行し、それらを組み合わせてフローを構成します。自動化の大部分がコードで、周辺に少量の接着処理がある構成なら、ノードキャンバス型のツールより適しています。
ライセンスには注意が必要です。エンタープライズ機能フラグを付けずにコンパイルした場合、ソースコードは AGPLv3 です。ghcr.io/windmill-labs/windmill で公開されているイメージは Community Edition で、オープンソースではないコードを含み、クォータ内で無料利用できます。Windmill の料金ページでは、クォータを 50 ユーザー、3 ワークスペース、10 GiB のワークスペースオブジェクトストレージ、実行回数無制限と定めています。1 人または小規模チームであれば、この上限に達する可能性は低いため、実際の問題はクォータではありません。実行するバイナリが AGPL ビルドではないことが問題です。
もう 1 つの考慮事項は、必要なリソース量です。Windmill の docker-compose.yml には、Postgres 16 データベース、1 台のサーバー、各 2048M のメモリ上限が設定されたデフォルトワーカー 3 個、ネイティブワーカー、Caddy プロキシが含まれます。公式ドキュメントの目安は「1vCPU あたり 1 ワーカー、RAM 1-2 GB」です。小規模なホストではレプリカ数を減らせます。ただし、ワーカーが実際にジョブを実行するため、数を減らしていることを把握しておく必要があります。
Windmill の AI 機能は、ビルド時の支援機能として説明されています。コード生成、フロー構築、チャット、フォーム入力が該当します。利用するには、まずワークスペース設定でモデルプロバイダーのリソースを追加する必要があります。スケジュールに従って実行し、ツールを呼び出すエージェントステップが必要なら、n8n の AI Agent ノードの方が直接的です。n8n で AI エージェントを構築するでは、その構成を説明しています。
Node-RED: 小規模構成で、データベースは一切不要
Node-RED は Apache 2.0 で、この比較対象の中で最も制限の少ないライセンスです。/data ボリュームを使用する単一の Node.js プロセスで動作します。Postgres は不要です。現在のリリースである nodered/node-red:5.0.4 に固定してください。
Node-RED は IoT（internet of things）向けの接続処理から発展したため、コネクター中心ではなくイベント中心の構成です。サードパーティーサービス用のノードはコミュニティーライブラリから提供されますが、品質にはばらつきがあります。これは、軽量な構成と引き換えに受け入れる点です。AI エージェント用の専用ステップはありません。Webhook とメッセージキューのネットワークトラフィックを処理する小規模な VPS では、動作する選択肢の中で最も軽量で、数秒で起動します。
Huginn と Automatisch: 最初にコミットログを確認する
Huginn は MIT ライセンスで、Ruby on Rails で書かれており、MySQL または PostgreSQL が必要です。ソースを監視してイベントを生成するエージェントを中心に構成されるため、フローカンバスとは異なるモデルです。LLM への対応もありません。コードには引き続きコミットがありますが、最後のタグ付きリリースは 2022 年 8 月です。そのため、実行時にはデフォルトブランチからビルドされた ghcr.io/huginn/huginn イメージを使用することになります。エージェントモデルが要件に合う場合に選択してください。汎用的な n8n の代替として選ぶものではありません。
Automatisch は .ee ファイルを除き AGPL-3.0 で、より単純な n8n のように見えます。Postgres、Redis、少数のアプリケーションカタログで構成されます。単一デプロイのチュートリアルで繰り返し推奨されているツールです。ただし、リリース履歴を見る限り、導入は待つべきです。すでに運用している場合、1 年間リリースがなく、半年間コミットがないことだけで慌てる必要はありません。一方、新しい本番環境へのデプロイを開始する理由にもなりません。
Activepieces スタックに実際に必要な RAM
アイドル時と稼働時のメモリ使用量は、各自のフローや処理するデータ量に依存するため、一律の数値を示すことはできません。確認できるのは、各ベンダーが見積もるよう案内している値です。Activepieces は以下の構成を文書化しています。数値より重要なのは、その横にある次の説明です。「concurrency-1 の worker は、フローの実行中（最大 10 分）は全時間にわたって使用中になるため、trigger rate ではなく同時実行フロー数を基準にサイズを決めます。」
The data behind this chart
[
{
"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
}
]1 worker は 0.5 vCPU と 1 GB を使用し、同時に実行できるフローは 1 つだけです。Postgres には 4 GB が必要です。プロジェクトの compose file では worker の replica が 5 つ起動するため、この見積もりでは、フローが本格的に処理を始める前から、リポジトリのスタックにおよそ 11 GB が必要になります。単一ツール向けのチュートリアルでは、この file をそのままコピーして、小規模なデプロイと説明しています。
4 GB の VPS では worker を 2 つにし、Postgres を同じ compose project で実行して、実測してください。docker stats --no-stream は各 container の実際の resident memory を 1 行ずつ表示します。これはベンダーやブログが公開しているどの数値よりも信頼できます。container の使用量が無制限に増える場合は上限を設定してください。Docker Compose のメモリ制限に構文を示しています。
1 台の VPS で Activepieces 用の compose ファイルを作成する
タグを固定します。latest のままでは、次の docker compose pull で警告なしにデータベーススキーマが変更される可能性があります。バージョン 0.86.3 は、2026 年 8 月 4 日時点でプロジェクトが独自の compose ファイルに固定しているものです。
まず、ドキュメントで指定されている長さを使って、2 つの Secret を生成します。
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=falseAP_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 にしています。レプリカを使用するサービスでは固定コンテナ名を指定できないため、固定コンテナ名を削除しています。また、compose がネットワークを自動的に作成するため、明示的なネットワークブロックも削除しています。
docker compose up -d
docker compose psすべてのサービスに Up を指定します。worker コンテナも2つ含まれます。コンテナが再起動を繰り返している場合、その理由が docker compose logs worker に出力されるため、変更する前に確認してください。ポートバインドだけでは、TLS（トランスポート層セキュリティ）対応のリバースプロキシを前段に置くまで、外部からアプリにアクセスできません。複数の compose アプリの前段で Traefik を実行するでこの構成を説明しています。.env の権限を mode 600 に設定し、git の管理対象外にしてください。compose の env ファイルで Secret を扱うと同じ方法です。
ガイドで省略されがちなバックアップ
これらのツールは保存された認証情報を暗号化するため、データベースのダンプだけではバックアップになりません。ダンプと、それを復号するキーの両方が必要です。問題は、多くのツールがそのキーを自動的に生成し、利用者に知らせず、バックアップ対象外の場所に保存することです。
n8n が最も分かりやすい例です。N8N_ENCRYPTION_KEY を一度も設定していない場合、n8n は「初回起動時にランダムな暗号化キーを自動生成し、~/.n8n フォルダーに保存」してから、そのキーで認証情報をデータベースへ保存する前に暗号化します。Postgres をダンプし、新しい volume を使う新しいコンテナへ復元すると、ワークフローは戻ります。しかし、すべての認証情報は誰にも読めない暗号文になります。変数を明示的に設定し、queue mode を使用する場合はすべての worker に同じ値を設定してください。
Node-RED も同じ構成です。認証情報は専用の暗号化ファイルに保存され、キーは settings.js 内の credentialSecret です。キーを設定しない場合、runtime がランダムなキーを生成し、/data 内の独自の settings store にある _credentialSecret の下へ保存します。標準の settings ファイルには、結果が次のように記載されています。「このプロパティを設定した後は変更しないでください。変更すると、node-red は既存の認証情報を復号できなくなり、認証情報は失われます。」flows ファイルだけでなく、/data volume 全体をバックアップしてください。
Activepieces は .env 内に AP_ENCRYPTION_KEY を保持します。これは「接続の暗号化に使用する 32 文字（16 バイト）の 16 進数キー」と説明されています。Huginn は環境変数内に APP_SECRET_TOKEN を保持します。Automatisch には ENCRYPTION_KEY、WEBHOOK_SECRET_KEY、APP_SECRET_KEY の 3 つがあります。いずれの場合も Secret は環境ファイルに保存されるため、環境ファイルもバックアップ対象です。
知っておく価値のある例外が Windmill です。Windmill の変数と Secret は workspace 固有の対称キーで暗号化され、そのキーは Windmill 自身のデータベースに保存されます。そのため、1 つの Postgres ダンプに両方が含まれます。復元は簡単ですが、ダンプだけで全 Secret を読み取れることも意味します。ダンプファイルは Secret 自体と同じように保護してください。
前述の 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次に、バックアップが機能することを検証してください。テストしていないバックアップは推測にすぎません。意図的に異なる AP_ENCRYPTION_KEY を使用する scratch compose project にダンプを復元し、保存済みの接続を使用する flow を実行します。データベース内の暗号文は別のキーで生成されているため、実行は失敗します。.env にある実際のキーを使って復元を繰り返すと、同じ flow が実行できます。この 2 回の実行だけが、バックアップが実際に機能することの証拠です。VPS からの restic バックアップを使用して、両方のファイルをスケジュールに従ってサーバー外へ送信してください。同じディスク上のバックアップは、ディスク障害とともに失われるためです。
n8nを使い続ける場合
業務が自社内に限定されるなら、使い続けてください。これは、Sustainable Use Licenseがまさに許可している利用形態です。対応範囲の広さを重視する場合も、使い続ける価値があります。n8nは1500以上の統合機能を提供しているためです。また、LangChainを基盤とするAI Agentノードを活用する場合も同様です。すぐに使えるエージェント用ステップという点で、ここで比較している他の製品には同等のものがありません。Claudeでn8nワークフローを駆動するでは、実際の利用方法を確認できます。
自動化コアに寛容なライセンスを求め、スタック全体を確認できる構成を望むなら、Activepiecesへ移行してください。フローの実体がユーザーインターフェースを備えたコードであるなら、Windmillへ移行してください。小規模な環境で、処理がイベント中心なら、Node-REDへ移行してください。ベンチマークでn8nが重いと判定されたからという理由だけで移行しないでください。まず自分のインスタンスを測定してください。そのうえで2026年にセルフホスティングする価値があるものを読み、移行先を一度で決めてください。2回目の移行にも、1回目と同程度のコストがかかるためです。
FAQ
n8n に最も近いセルフホスト型の n8n 代替製品はどれですか？
Activepieces です。考え方は同じで、ビジュアルビルダーでトリガーからフローを開始し、各ステップでサービスを呼び出します。コネクターのカタログも豊富です。コア部分は MIT ライセンスで、Docker 上で Postgres と Redis を使用して動作します。各 piece は LLM クライアント向けの MCP サーバーとしても機能します。注意点は、API アクセスとエージェント機能が商用の enterprise ディレクトリに含まれていることです。そのため、Community Edition のインスタンスはプログラムからではなく、Web インターフェース経由で操作します。
Activepieces は本当にオープンソースですか？
コア部分は MIT ライセンスです。ただし、packages/ee/ と packages/server/api/src/app/ee の 2 つのディレクトリは商用ライセンスであり、これらの機能を自分のサーバーで使用するには有料ライセンスが必要です。ベンダーの料金ページでは、Agents and Chat、Projects、API access、single sign-on、user roles、audit logs、secret managers、branding、Git sync が Community Edition の対象外とされています。一方、runs、users、flows には上限がありません。したがって、自動化の構築と実行については正真正銘のオープンソースですが、チーム管理とガバナンスの層はオープンソースではありません。
VPS で Activepieces を実行するには、どの程度の RAM が必要ですか？
Activepieces のドキュメントでは、worker 1 個につき 0.5 vCPU と 1 GB、app container に 1 vCPU と 1 GB、Postgres に 4 GB、Redis に 1 GB を必要としています。worker は、対象フローの実行が完了するまで、そのフローを一度に 1 つ処理します。そのため、トリガーの発生頻度ではなく、ピーク時の同時実行フロー数を基準にリソースを決めます。リポジトリの compose ファイルでは worker が 5 個起動するため、公表されているサイジングでは約 11 GB になります。4 GB の VPS で worker 2 個から始めるのが現実的です。実行中に 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 のメモリ使用量を改善するほうが安価です。