n8n無料セルフホスト版の制限・活用完全ガイド

2026年時点での無料プランの具体的制限項目

n8n のセルフホスト版はオープンソースとして無償提供されていますが、実際に運用できるリソースはサーバー環境や設定に依存します。本節では公式ドキュメント（2026 年 3 月時点）で明記されているデフォルト値と、一般的な運用上の目安をまとめます。数値は「デフォルト設定」→「変更可能性」の順に示し、根拠となるリンクも併記しています。

ワークフロー作成数上限

デフォルトでは ワークフロー数に明確な上限は設けられていません（公式ドキュメント）。
ただし DB の容量やコンテナの CPU / メモリが許容できる範囲であれば、数千件以上でも運用は可能です。

補足

• SQLite を利用する場合はファイルサイズ（デフォルト 2 GB）に注意。PostgreSQL や MySQL に切り替えると実質的に無制限になります。
• 大規模環境では インデックス設計 と 定期的なアーカイブ がパフォーマンス維持の鍵です。

実行回数・トリガー頻度

無料版でも 実行回数自体にハードリミットはありません（公式 FAQ）。
しかし CPU 使用率が高くなると遅延やタイムアウトが発生しやすくなるため、トリガー設計には工夫が必要です。

推奨設定例

• ポーリング系トリガーは 5 分以上の間隔 を基本とする。
• 1 秒未満の高頻度ポーリングは 外部キュー（Redis/Bull）やワーカースケールアウト で緩和します。

同時ジョブ数

デフォルトでは 同時実行可能なジョブが最大 5 件 に制限されています（EXECUTIONS_PROCESS=main の場合）。この上限は公式ドキュメントの「Execution Process」項目に記載されており、環境変数や外部キューで増加させることが可能です。
詳細は Execution Configuration を参照してください。

増加手段

データ保持期間

実行履歴は デフォルトで 30 日間 保存されます（EXECUTIONS_DATA_RETENTION_DAYS=30）。この設定は公式ドキュメントの「Execution Data Retention」項目に記載されています。
必要に応じて n8n cleanup コマンドや DB の TTL 設定で短縮・延長が可能です。

注意点

• 30 日以上保存したい場合はストレージ容量とコストを事前に見積もること。
• PostgreSQL を利用するとパーティショニングで大規模データ保持が容易になります。

バックアップとサポート範囲

ポイント：バックアップは自動化しないと人的ミスで失われやすくなるため、cron + docker exec で定期的に取得することをおすすめします。

有料プランとの機能比較と商用利用の可否

有料プランはクラウド版（n8n.cloud）とエンタープライズ向けセルフホスト版の二つが主流です。本節では 価格・リソース上限・商用利用条件 を表形式で比較し、導入判断に必要な情報を整理します。料金は変動する可能性があるため、最新情報は公式プライシングページ（https://n8n.io/pricing）をご確認ください。

料金・提供リソース比較表

*「実行上限」は公式が示す月間実行回数の上限です。
**同時ジョブ数はデフォルト値であり、Enterprise では契約に応じて無制限化可能です。

追加機能と商用利用条件

• 有料クラウド版 は UI テーマカスタマイズ、バックアップ自動化、SLA（99.9% 稼働保証）などを標準装備しています。
• Enterprise ライセンス（セルフホスト向け）は再販・マネージドサービス提供を許可する特別条項が付与されます。Apache‑2.0 のままではコードのそのまま販売は不可です。

ライセンス上の注意点

重要：企業向けに SaaS として提供する場合は必ず Enterprise ライセンス取得または公式パートナー契約を結ぶ必要があります。

無料版を最大活用する実務テクニック

無料セルフホスト版でも適切な設定と運用手順を踏めば、実務レベルの自動化が十分に可能です。本節では Docker/Compose の基本構築、外部キュー導入によるスケールアウト、そして リソース最適化・バックアップ戦略 を具体例とともに解説します。

Docker/Compose でのローカルデプロイ手順

以下は公式ドキュメントに沿ったシンプルな構成です。環境変数やボリューム設定を変更すれば本番環境へそのまま流用できます（Docker Deploy Guide）。

1. イメージ取得
   bash
docker pull n8nio/n8n:latest
2. docker‑compose.yml 作成（主要ポイントだけ抜粋）
   yaml
version: '3.8'
services:
n8n:
image: n8nio/n8n
restart: unless-stopped
ports:
- "5678:5678"
environment:
- DB_TYPE=sqlite # 小規模は SQLite、拡張時は PostgreSQL 推奨
- EXECUTIONS_PROCESS=main # デフォルトの同時ジョブ 5 件
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=securePassword123
- EXECUTIONS_DATA_RETENTION_DAYS=30
volumes:
- ./n8n_data:/home/node/.n8n # 永続化ディレクトリ
3. デプロイ
   bash
docker compose up -d

起動後は http://localhost:5678 で UI にアクセスし、すぐにフロー作成が可能です。

外部キュー（Redis / RabbitMQ）との連携によるスケーラビリティ向上

キューモードに切り替えると EXECUTIONS_PROCESS=queue が有効になり、ジョブは Redis や RabbitMQ に一時保存されてワーカーへ分配されます。これにより同時実行数はワーカー台数だけ拡張できます（公式キューページ参照）。

設定例（Redis）

ワーカースケールアウト例

ポイント：キュー導入後は EXECUTIONS_PROCESS=main を外すこと。キューモードではジョブが永続化されるため、突発的な負荷増にも耐えられます。

リソース最適化設定と定期バックアップ・ログ保持方法

コンテナ単位で CPU/メモリ制限を設け、かつログローテーションとデータバックアップを自動化すれば、運用コストと障害リスクを大幅に低減できます。

定期的に バックアップのリストアテスト を実施し、復旧手順が確実に機能するか確認しましょう。

具体的な活用事例

以下は無料セルフホスト版で実際に運用されているユースケースです。各シナリオでは 同時ジョブ数の調整、データ保持期間の最適化、外部キュー活用 がポイントとなります。

小規模マーケティング自動化（メール配信・リード管理）

Google Forms → Google Sheets → Mailchimp のフローで、月間数千件のリードを自動処理します。実行回数は無制限なのでコストがかからず、データ保持は 30 日で十分です。

1. ノード構成：Google Sheets (トリガ) → HTTP (Mailchimp API) → Delay
2. ポイント：EXECUTIONS_PROCESS=main のままで問題なし。
3. コスト削減策：実行履歴の TTL を 30 日に設定し、古いデータは自動削除。

社内通知と Slack 連携

毎朝のタスク一覧を社内 API から取得し、Slack の #daily‑tasks に投稿するフローです。キュー導入で同時ジョブ数を 10 に拡張しています。

1. ノード構成：Cron → HTTP (社内 API) → Slack
2. スケーラビリティ：EXECUTIONS_PROCESS=queue + Redis キュー、ワーカー 2 台で同時実行上限 10 件に設定。
3. 運用メリット：他の通知フローと競合せず、遅延なく配信可能。

CSV / Google Sheets データ集計

外部ベンダーが FTP にアップロードする CSV を毎晩取得し、必要項目だけを抽出して Google Sheets に追記します。CPU 集中型処理のためコンテナに CPU リミットを付与しています。

1. ノード構成：FTP → CSV Parse → Google Sheets Update
2. リソース最適化：--cpus="2" で CPU を固定、他フローへの影響を低減。
3. データ保持：集計結果は 90 日保持し、古い行は自動削除スクリプトでクリーン。

API 連携によるレポート生成

社内 DB の売上データを週次で取得し、Function ノードで集計・PDF 作成、メールで送信するフローです。無料版でも外部ライブラリ node-pdfkit をインストールでき、追加コストは発生しません。

1. ノード構成：HTTP (DB API) → Function (集計 + PDFKit) → Email
2. 実行環境：Docker コンテナに npm install pdfkit を事前に組み込み。
3. 保持期間：レポートは社内ストレージに保存し、n8n の実行履歴は 30 日で自動削除。

セキュリティとメンテナンスのベストプラクティス、そして有料への移行ガイド

運用を長期化するほど セキュリティ・アップデート・スケーラビリティ が重要になります。本節では HTTPS 化・認証設定、定期的なバージョン更新手順、そして有料プランへシームレスに移行するためのチェックポイントをまとめました。

HTTPS 化と認証設定

本番環境では必ず TLS 終端をリバースプロキシで実施し、Basic 認証や SSO でアクセス制御を行います。以下は開発用自己署名証明書の作成例です。

リバースプロキシ構成例（Traefik）

• Basic 認証は環境変数 N8N_BASIC_AUTH_* で有効化。
• OAuth2 / SSO は Keycloak 等の外部 IdP と連携し、ヘッダー情報を n8n に渡すことで実装可能です。

定期的なアップデート手順

ロールバックは直前のタグ（例：n8nio/n8n:2.3.0）に戻すだけで完了します。バックアップは必ず取得してから作業してください。

有料プランへスムーズに移行するタイミングとステップ

移行フロー

1. 要件整理：実行回数、同時ジョブ、バックアップ・保持期間を一覧化。
2. プラン選定：上記表から最適な有料オファーを決定（公式価格は常に最新ページ参照）。
3. データ移行：SQLite → PostgreSQL へ pg_dump/psql を使用し、テーブル構造・履歴もそのまま移行。
4. 環境切替：docker‑compose のイメージタグと環境変数を有料プラン用に変更し、再デプロイ。
5. 検証 & 本番ロールアウト：ステージングでフロー全体をテスト後、本番へスイッチ。

移行作業は ダウンタイム 10 分以内 に収められるよう、事前にバックアップとリハーサルを実施することが推奨されます。

まとめ

• 無料セルフホスト版は ワークフロー数・実行回数の上限がほぼ無制限であり、適切な設定すれば実務レベルの自動化が可能です。
• 同時ジョブ数やデータ保持期間などは公式ドキュメントに記載された デフォルト値 であり、環境変数・外部キューで柔軟に拡張できます（根拠リンク付き）。
• 有料プランは 価格・リソース上限・商用利用条件 が明確に定義されており、最新情報は公式プライシングページをご確認ください。
• Docker/Compose によるデプロイ、Redis キューでのスケールアウト、バックアップ自動化といったベストプラクティスを取り入れれば、運用コスト・障害リスクを最小限に抑えられます。
• 事業拡大や SLA が必要になった段階では、Enterprise ライセンスまたは Cloud Pro への移行が自然なステップです。

これらのポイントを押さえておけば、2026 年時点でも n8n の無料セルフホスト版で実務レベルの自動化を安全かつ継続的に運用できるでしょう。まずは公式ドキュメント通りに Docker 環境を構築し、紹介したシナリオを試してみてください。