n8n × Self-Hosted で構築する社内自動化基盤2026

この記事でわかること

n8n を Self-Hosted で構築する際のアーキテクチャ選定基準
セキュリティ・ユーザー管理・バックアップを含む本番運用設計
中級者が SaaS 版から Self-Hosted に移行する際の判断ポイント

結論

2026年Q2時点で n8n の Self-Hosted は「社内データを外に出さない自動化基盤」を比較的低コストで構築できる現実解です。中級開発者が Docker + PostgreSQL + リバースプロキシの最小構成で運用に乗せられる一方、ユーザー管理・バックアップ・アップデート運用を雑に扱うと事故が必ず起きるので、本記事のチェックリストを満たしてから業務クリティカルな自動化に投入してください。Sustainable Use License の制約も踏まえ、商用配布や SaaS 提供を考える場合は Enterprise エディションの検討が必要です。

本題

Self-Hosted の典型アーキテクチャ

中級者が現実的に組む構成は次のレイヤです。

コンテナ層: n8n 公式 Docker イメージ
DB: PostgreSQL（SQLite はテスト用）
キュー実行: Redis + worker コンテナ（中規模以上）
リバースプロキシ: Caddy / Traefik / nginx
TLS: Let's Encrypt 自動更新
ストレージ: バイナリデータ用に S3 互換ストレージ

小規模なら docker compose 一式で十分、規模が大きくなったら Kubernetes に載せ替える流れがベタです。

最小構成の docker-compose 例

本番想定の最小例（執筆時点の標準的な構成）。

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_HOST: ${N8N_HOST}
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://${N8N_HOST}/
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
    depends_on: [postgres]
volumes:
  pg_data: {}

N8N_ENCRYPTION_KEY は credentials の暗号化に使われるキーで、後から変更すると全 credentials が読めなくなります。最初に決めて鍵管理ツール（Vault / 1Password 等）で厳重に保管してください。

セキュリティの肝

中級者が見落としがちなセキュリティ項目:

公開範囲: 社内VPN 配下に置く / Cloudflare Access 等の前段認証を入れる
ユーザー管理: Email + パスワードだけでなく SSO（SAML / OIDC）を有効化
MFA: 管理者アカウントは必ず MFA 必須化
Webhook 認証: 外部公開 Webhook は HMAC 署名検証を別ノードで挟む
secrets: 環境変数経由で渡す。ワークフロー内に直書きしない

特に Webhook は「公開URL=誰でも叩ける」状態になりがちなので、認証を入れる/IP制限する/トークンを必須化するの3点を最低限実装してください。

バックアップ戦略

n8n のデータは大きく3種類: PostgreSQL、暗号化された credentials、ワークフロー JSON。バックアップ対象とリストアテストは次のように設計します。

DB: pg_dump を日次で取得、世代管理（最低14日）
暗号化キー: 上記とは別の保管場所に冗長保存（無くしたら credentials 全滅）
ワークフロー: 別途 JSON エクスポートを Git リポジトリにバージョン管理
リストア訓練: 四半期に1回、別環境で実際に復元できることを確認

特に4は地味ですが、バックアップを取っているだけで「リストアできるか」を試していない運用は本番事故時に詰みます。

バージョンアップ運用

n8n はリリース頻度が高いプロダクトです。中級者の運用パターン:

タグ固定: latest ではなく n8n:1.x.y のように固定し、計画的に更新
ステージング環境: 同じ docker-compose をステージング用に複製、新バージョンを先行検証
メジャー更新時の breaking changes 確認: リリースノートに必ず目を通す
DB マイグレーション: 自動だが、初回は時間がかかる場合あり、メンテ時間を確保

「動いているから触らない」を続けると、半年後に5メジャー飛ばした更新で詰むので、月1ペースで更新する運用が結局安全です。

SaaS 版から Self-Hosted への移行判断

中級者が SaaS 版を使っていて Self-Hosted を検討する典型的な理由:

機密データを外に出せない要件が出てきた
ユーザー数増加で SaaS の月額が積み上がった
カスタムノードや特殊な統合が必要になった
ネットワーク的に分離された環境（オンプレ / プライベートクラウド）からの実行

逆に Self-Hosted のままで困るのは「アップタイム責任を自分で持つ」「DB スケールを自分で見る」「セキュリティパッチ追従」の3点。社内に運用工数を出せるなら Self-Hosted、出せないなら SaaS のままが現実解です。

よくある質問（FAQ）

Q1: 個人利用でも Self-Hosted する意味はありますか？

A1: あります。データを外に出したくない用途や、SaaS のクレジット消費を気にせず大量に動かしたい用途では Self-Hosted の方が快適です。ただし運用工数（バックアップ・更新）を自分で背負う前提で、その時間に見合うかは個人事情次第です。

Q2: Self-Hosted のライセンス上の注意点は何ですか？

A2: n8n は執筆時点で Sustainable Use License を採用しており、内部用途・自社向け業務利用は無償で可能ですが、第三者向けに n8n をホスティング提供（SaaS 化）するような用途は Enterprise ライセンスが必要になります。商用配布を考えるなら必ず最新ライセンス文書を原本確認してください。

Q3: Workers を分離するべき規模感はどれくらいですか？

A3: 体感では「1日数千実行」を超えるあたりからキュー方式 + Worker 分離が必要になります。それ未満ならメインコンテナ単体で十分回ります。CPU/メモリの張り付き具合と実行待ち時間を観察して判断してください。

まとめ

n8n Self-Hosted は中級開発者にとって、社内自動化基盤を低コストで構築できる強力な選択肢です。docker-compose の最小構成から始めつつ、セキュリティ（前段認証・MFA・Webhook 認証）、バックアップ（DB・暗号化キー・ワークフローJSON）、バージョンアップ運用（タグ固定・ステージング検証）の3点を最初から仕組み化しておくと、本番運用に乗せた後も事故を最小化できます。執筆時点ではライセンス条項やリリースペースが活発に動く領域なので、ライセンスとリリースノートは四半期ごとの確認を運用に組み込んでおくのが安全です。