VPS で n8n をセルフホストする。
自分の自動化エンジン、自分の認証情報、自分のマシン。

n8n はワークフロー自動化エンジンです。トリガー — Webhook、スケジュール、データベースの新しい行、キュー内のメッセージ — を、API を呼び出し、データを変換し、条件で分岐し、任意の JavaScript や Python を実行し、結果を次のノードに渡すノードの連鎖に配線するビジュアルキャンバスです。数百のインテグレーションノードが標準で同梱され、それ以外すべてをカバーする汎用の HTTP Request ノードもあります。1.x 系列以降は AI Agent ノードと LLM ノードも搭載しており、これが2026年に導入する人の多くが、古典的な ETL 配管ではなくエージェントを構築している理由です。

コマンドを1行でも打つ前に重要になるのはライセンスです。n8n は OSI の意味でのオープンソースではなく、その違いは机上の話ではありません。コアは Sustainable Use License の下で配布されています。社内業務目的、および個人利用・非商用利用のために、ソフトウェアを使用・複製・改変・配布する、非独占的かつロイヤリティフリーの世界的な許諾です。これが留保しているのは、n8n やその派生物について他者に課金する権利です — この条項が、有償の「マネージド n8n」製品をその上に構築することを排除しています。別途、名前に .ee. を含む、あるいはパスに .ee を含むファイルはこのライセンスから完全に除外され、有償の n8n Enterprise License が必要です。

率直に言えば、自社の業務、自分が提供するサービスとしてのクライアントの仕事、あるいは自分自身の私生活を自動化するために VPS 上で n8n を動かすことは、無償許諾の範囲内であり、これまでもずっとそうでした。n8n をホスティング製品として販売することはその範囲外です。インターネット上の「n8n は本当に無料か？」という議論のほとんどは、この線を挟んで互いにすれ違っている二人の会話です。

コスト面。 n8n Cloud は実行数に応じた課金です。Starter プランは年払いで月額€20、2,500回の実行まで。Pro は月額€50で10,000回まで。Business は月額€667で40,000回まで。セルフホストでは、実行数はそもそも課金項目ではなく、ボックスがどれだけの CPU とメモリを持つかで制限されるだけです。5分ごとに API をポーリングするワークフローは、それだけで月に8,640回の実行を消費します。Cloud ではこの1つのワークフローだけで既に Pro 階層を強いられますが、$3.90 の VPS ではアイドル CPU に対する誤差の範囲です。

クラウド料金は2026年8月時点で n8n.io に公開されている年払いの金額です。月払いはさらに高くなります。トレードオフは金銭面だけではありません — セルフホストでは、アップグレード、バックアップ、TLS の更新、稼働率の責任が自分の側に移ります。

パネルでは、Order → VPS → Sentinel、イメージは Debian 12 を選びます。アカウント開設にメールアドレスは不要、本人確認書類もどの時点でも求められず、請求は Monero、Bitcoin、Lightning、その他対応する資産で決済されます。拠点は自分自身への遅延ではなく、自動化するサービスへの遅延で選んでください — 自動化サーバーはあなたと話すよりもはるかに多く API と話します。

次に、サーバーに触る前に DNS レコードを作成します。n8n.example.com を VPS の IPv4 に向ける A レコード、IPv6 を使うなら AAAA レコードです。これを先に行う必要があるのは、スタックが起動した瞬間に Caddy が Let's Encrypt に証明書を要求するためで、解決しない名前への証明書リクエストは失敗し、その後バックオフし、サイトになぜアクセスできないのか20分悩む羽目になるからです。

DNS が伝播するまで少し待ち、続行する前に自分のマシンから確認してください:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

公開ポートで何かがリッスンを始める前に、最初の1時間のハードニングチェックリストを実行してください — 鍵認証のみの SSH、22・80・443 以外は許可しないファイアウォール、無人のセキュリティアップデートです。自動化サーバーは認証情報の金庫であり、その1時間をかける価値があります。

まずディレクトリを作成し、2つのシークレットを生成します。今すぐこの順番で生成し、生成しながら .env に貼り付けてください — 特に暗号化キーは、n8n の初回起動より前に存在している必要があります。

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

このファイルは即座にロックダウンしてください — インスタンスが今後保存するすべての認証情報の鍵を握っています:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

名前を挙げる価値のある2つの設計上の判断。 第一に、n8n はポートを公開しません。80と443をバインドするのは Caddy だけであり、n8n は Compose ネットワーク内部の5678番でリッスンしていて、ホスト外部からは到達できません。意外なほど多くのセルフホスト n8n インスタンスが、前段に TLS を置かないままポート5678でパブリックインターネットに露出しており、露出したサービスを探す検索エンジンにインデックスされています。第二に、PostgreSQL がワークフローを保持するようになった後も n8n のデータボリュームはマウントされたままです — そのディレクトリには依然としてインスタンス設定、ログファイル、ソースコントロール用のアセットが入っています。

起動する:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

起動してエディタが表示され、手動テストが動く n8n は、まだ機能している n8n とは言えません。静かに壊れているのは受信 Webhook であり、あたかもサードパーティのサービス側に問題があるかのように見える形で壊れます。

WEBHOOK_URL. これがないと、n8n は N8N_HOST と N8N_PORT から Webhook の URL を組み立て、http://localhost:5678/webhook/abc のようなものを渡してきます。これを Stripe や GitHub に貼り付けても、決して到達できません。上記の Compose ファイルは WEBHOOK_URL を公開の HTTPS ルートに設定しており、これがエディタに表示され、かつ外部が実際に呼び出せるものになります。

N8N_EDITOR_BASE_URL. n8n が送信するメール内のリンク — パスワードリセット、ユーザー招待 — に使う公開 URL です。ここが間違っていると招待リンクが localhost を指すことになり、それは連携の不具合ではなく同僚からのサポートチケットを生みます。

N8N_PROXY_HOPS. n8n は X-Forwarded-For からクライアント IP を読み取り、この数値が示すホップ数までしか信頼しません。前段にリバースプロキシが1つ — このスタックでは Caddy — ある場合、値は1です。Caddy の前に Cloudflare を置くと2になります。デフォルトの0のままにしておくと、すべてのリクエストがプロキシ自身から来ているように見えてしまい、レート制限やワークフロー内の IP ベースのロジックが静かに壊れます。

N8N_SECURE_COOKIE. デフォルトは true で、セッションクッキーが HTTPS 経由でしか送信されないことを意味します。これは正しい設定であり、このスタックはそれを満たしています。知っておく価値があるのは、素の http で最初に試したときの典型的な症状を説明するからです。ログインフォームがパスワードを受け付けた後、延々とログインフォームに戻され続けます。修正は TLS であって、このフラグを無効にすることではありません。

きちんとテストしましょう。Webhook ノードを持つワークフローを作成し、ワークフローをアクティブ化し、Production URL をコピーして、サーバーではないマシンから呼び出します:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

誰もが一度はつまずく違いです。Test URL は、エディタを開いて「Listen for test event」を有効にしている間だけリッスンします。Production URL は、ワークフローが Active に切り替えられているときにのみ存在します。エディタでは動くのに本番で404になる Webhook は、ほとんどの場合ワークフローが非アクティブなだけです。

デフォルトでは n8n はレギュラーモードで動作します。エディタを提供し Webhook を受信するのと同じプロセスがワークフローも実行します。これはシンプルで、1つの長時間ワークフローが他を待たせ始めるまでは正しく機能します。症状は明白です — 実行が何分も「running」のまま止まり、エディタが重くなり、本来200ミリ秒で応答するはずの Webhook が8秒かかるようになります。

キューモードは作業を分割します。メインインスタンスがエディタ、トリガー、Webhook エンドポイントを保持し、実行 ID を Redis に投入します。別のワーカープロセスがそれらを取り出し、PostgreSQL からワークフローを読み込んで実行し、Redis 経由で結果を報告します。このアーキテクチャからは3つのルールが導かれ、それを省略した人は全員痛い目に遭います。すべてのインスタンスが同じ PostgreSQL データベースを共有しなければならないこと、すべてのインスタンスが同じ N8N_ENCRYPTION_KEY を持たなければならないこと、そして SQLite はまったくサポートされないことです。

Compose ファイルへの追加分は、Redis サービスと1つのワーカーサービスです。ワーカーサービスは、worker コマンドで実行される同じ n8n イメージです:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

メインの n8n サービスにも EXECUTIONS_MODE=queue と QUEUE_BULL_REDIS_HOST=redis を追加してください — 両側でモードを一致させる必要があります。初日から設定しておく価値がある2つのオプションがあります。エディタで「Test workflow」を押してもメインプロセスを占有しないようにする OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true と、再デプロイ時にワーカーが現在のジョブを完了させるまでの許容時間を決める N8N_GRACEFUL_SHUTDOWN_TIMEOUT（デフォルトは30秒）です。ワークフローが日常的に30秒以上かかる場合は値を引き上げてください。さもないと、デプロイのたびに実行中の処理が強制終了されます。

ここから始めないでください。キューモードは2つの可動部分と、レギュラーモードにはそもそも存在しない種類の障害を追加します。キューが伸びているのが見える、あるいは1つのワークフローが他をブロックしているのが見えるまでは、レギュラーモードにとどまり、それから2台目のボックスを追加する前に、まず同じボックスにワーカーを1つ追加してください。この段階的な流れ — レギュラーモードの Sentinel、ワーカー1台の Garrison、3台の Ravelin — で、本当に大規模な展開を除くすべてをカバーできます。