n8n を VPS でセルフホストする完全ガイド——公式ドキュメントで確かめた必要スペック・構築手順・運用の勘所

業務自動化ツール n8n（エヌエイトエヌ）を自分のサーバーで動かす「セルフホスト」は、実行回数を気にせず使えて、扱うデータを社外に出さずに済む。一方で、検索して出てくる解説の多くは「最低でもメモリ2GBが必要」と書いているが、これは n8n が公式に示している数字ではない。この記事では、n8n の公式ドキュメントと各社の公式料金表だけを根拠に、必要なスペックの実際・ライセンスで許される範囲・Docker を使った構築手順・そして「セルフホストをやめておいたほうがいい人」の条件までを整理する。読み終えるころには、自社が Cloud とセルフホストのどちらを選ぶべきか、根拠を持って判断できるはずだ。

セルフホストで何が変わるのか——実行回数とデータの置き場所

n8n には、n8n 社が運用する「n8n Cloud」と、自分でサーバーを用意して動かす「セルフホスト」の 2 つの使い方がある。両者の決定的な違いは料金の構造だ。n8n Cloud はワークフローの実行回数で課金される。公式の料金ページによると、Starter プランは年払いで月あたり 20 ユーロ、含まれる実行回数は月 2,500 回。Pro プランは月あたり 50 ユーロで月 10,000 回となっている（いずれも年払い時の月額表示）。

対してセルフホストは、サーバー代を払えば実行回数に上限はない。5 分おきに動くワークフローを 1 本回すだけで月 8,640 回、これを 3 本動かせば月 2 万回を超える。定期実行のワークフローを何本も抱える使い方では、実行回数の壁に先にぶつかる。ここがセルフホストを検討する最大の理由になる。ツール選定そのものを迷っている段階なら、n8n・Zapier・Make の比較記事を先に読むと前提が揃う。

もうひとつの理由がデータの置き場所だ。セルフホストなら、ワークフローが処理する顧客データや請求データは自分のサーバーの中だけを通る。取引先との契約で「データを国外のサービスに置かない」と定めているケースや、社内規程で外部 SaaS へのデータ送信を制限しているケースでは、この点が効いてくる。

ライセンスの確認——社内利用は無料、他社への提供は不可

セルフホストを始める前に、必ずライセンスを確認しておきたい。n8n は一般的なオープンソースライセンスではなく、Sustainable Use License（サステナブル・ユース・ライセンス） という独自の条件で公開されている。公式ドキュメントによれば、利用は「内部的な業務目的（internal business purposes）」または「非商用・個人利用」に限られる。

整理すると、自社の業務を自動化するために自社サーバーで動かす分には無料で使える。顧客の業務を支援するコンサルティングや導入支援も明示的に許可されている。一方、n8n を載せたサーバーを他社に貸して月額課金する、いわゆる再販型のサービスは許可されていない。自社利用と受託開発の線引きが曖昧な場合は、ライセンス原文を確認したうえで n8n 社に問い合わせるのが確実だ。

必要なスペックの実際——「メモリ2GB以上」は公式の数字ではない

ここが本記事で最も伝えたい部分だ。「n8n のセルフホストには最低 2 vCPU・メモリ 2GB が必要」という記述は各所で見かけるが、n8n の公式ドキュメントを探してもこの数字は出てこない。公式がサイジングの目安を示しているのは、OEM 提供者向けの前提条件ページだけで、そこに書かれている数字はむしろ小さい。

公式はあわせて 3 つの重要な注記を置いている。ひとつ、「n8n は CPU 集約的ではないため、小さなインスタンスでもたいていの用途には十分」。ふたつ、「メモリの要件が CPU の要件に優先する」ため、リソースを足すならメモリから。みっつ、これらの数字は n8n Cloud の実績にもとづく「例示にすぎない（for illustrative purposes only）」もので、実際の必要量は利用者数・ワークフローの中身・実行量で変わる。アイドル状態の n8n Cloud インスタンスの使用メモリは約 100MB という記載もある。

先に結論——セルフホストをやめておいたほうがいい人

n8n の公式ドキュメントは、セルフホストの手順ページの冒頭で、めずらしくはっきりとした警告を出している。「セルフホストには、サーバーとコンテナの設定、リソース管理と規模の拡張、サーバーとアプリケーションの安全確保、n8n の設定といった技術的な知識が必要」であり、「n8n はセルフホストを熟練した利用者に推奨する。ミスはデータ損失・セキュリティ問題・停止につながる。サーバー管理の経験がなければ n8n Cloud を推奨する」と明記している。ツールの提供元が自社の無料版を勧めない、という点は重く受け止めたい。

特に見落とされがちなのが「止まったときに誰が直すのか」という論点だ。セルフホストした n8n が深夜に落ちれば、朝まで請求処理も通知も止まる。バックアップを取っていなければ、ワークフローと認証情報がまとめて消える。この責任を自社で引き受けられないなら、Cloud のほうが総保有コストは安い。

VPS の選び方と、意外と効くアプリイメージの有無

VPS（仮想専用サーバー。1 台の物理サーバーを分割し、専用サーバーのように使える借り方）を選ぶとき、n8n 用途で見るべき点は多くない。メモリ、SSD の容量、そしてn8n のアプリイメージが用意されているかの 3 点だ。アプリイメージとは、サーバー作成と同時に指定したソフトウェアの構築まで済ませてくれる仕組みで、これがあると初回構築の手間が大きく減る。

国内の VPS では、エックスサーバー株式会社の XServer VPS が公式に n8n のアプリイメージ（ubuntu 22.04 ベース）を提供している。同社の OS・アプリイメージ一覧を見ると興味深い事実がわかる。同じ AI ツール枠に並ぶ Claude Code、Codex CLI、Dify、Gemini CLI の各イメージには「※メモリ4GB以上のプランで利用可能です」という制限が付いているのに対し、n8n のイメージにはこの制限が付いていない。前述の「n8n は CPU 集約的ではない」「メモリは 320MB から」という公式の記述と整合する。

上表は XServer VPS の公式料金表にもとづく 2GB プラン（vCPU 3 コア、NVMe SSD 50GB、初期費用 0 円）の通常価格である。同社はしばしば期間限定の割引を実施しており、その時期は上表より安くなる。割引は時期で変わるため、申し込み前に必ず公式の料金ページで最新の金額を確認してほしい。なお、前回の記事で扱った Codex CLI のイメージを使いたい場合は、前述のとおりメモリ 4GB 以上のプランが必要になる点に注意する。

構築手順1——まず手元で動かして感触をつかむ

いきなり本番用のサーバーを借りる前に、手元のパソコンで動かしてみるのが遠回りに見えて速い。Docker（アプリを「コンテナ」という箱に閉じ込めて動かす仕組み）が入っていれば、公式ドキュメントの手順はこれだけだ。

# データを保存する場所（ボリューム）を作る
docker volume create n8n_data

# n8n を起動する（タイムゾーンは自分の環境に合わせて置き換える）
docker run -it --rm 
 --name n8n 
 -p 5678:5678 
 -e GENERIC_TIMEZONE="Asia/Tokyo" 
 -e TZ="Asia/Tokyo" 
 -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true 
 -e N8N_RUNNERS_ENABLED=true 
 -v n8n_data:/home/node/.n8n 
 docker.n8n.io/n8nio/n8n

起動したらブラウザで http://localhost:5678 を開く。n8n_data というボリュームを /home/node/.n8n に割り当てているため、コンテナを作り直してもワークフロー・認証情報・実行履歴は消えない。ここで見落としやすいのが 2 つのタイムゾーン設定だ。TZ はコンテナ全体の時刻を、GENERIC_TIMEZONE はスケジュール実行のノードが使う時刻を決める。公式の Docker 起動例では両方を同じ値にそろえており、とりわけ定期実行の基準になる GENERIC_TIMEZONE は Asia/Tokyo にしておく。設定しない場合の既定値はニューヨーク時間である。

構築手順2——VPS 上で HTTPS 付きの本番構成にする

本番で使うなら、独自ドメインと HTTPS（通信の暗号化）が要る。外部サービスから n8n に通知を送る Webhook を使う場合、暗号化なしの通信では実用にならないからだ。公式が案内している構成は、n8n のコンテナと、証明書の取得と振り分けを担当する traefik（トラフィック。リバースプロキシと呼ばれる、外からの通信を受けて内部に渡す役割のソフト）のコンテナを、Docker Compose で 2 つ同時に動かすというものだ。

手順の骨格は 4 つ。まず、使いたいサブドメイン（たとえば n8n.example.com）の A レコードを VPS の IP アドレスに向ける。次に設定値をまとめた .env ファイルを作る。続いて compose.yaml を置き、最後に起動する。

# 1. 作業用のディレクトリと、n8n がファイルを読み書きする場所を作る
mkdir n8n-compose && cd n8n-compose
mkdir local-files

# 2. .env に設定値を書く
cat > .env <<'EOF'
DOMAIN_NAME=example.com
SUBDOMAIN=n8n
GENERIC_TIMEZONE=Asia/Tokyo
SSL_EMAIL=admin@example.com
EOF

# 3. compose.yaml を配置したうえで起動する
sudo docker compose up -d

compose.yaml の中身は公式ドキュメントに全文が掲載されている。要点だけ押さえておくと、n8n 側のポート公開が "127.0.0.1:5678:5678" と、サーバー自身からしか触れない形に絞られているところが肝だ。外部からの接続はすべて traefik が 443 番ポートで受け、証明書を Let's Encrypt から自動取得し、HTTP でのアクセスは HTTPS へ転送する。結果として、公式が書くとおり「n8n には安全な HTTPS でのみ到達でき、平文の HTTP では到達できない」状態になる。

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"   # 外部に直接開かない
    environment:
      - N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - N8N_RESTRICT_FILE_ACCESS_TO=/files
    volumes:
      - n8n_data:/home/node/.n8n
      - ./local-files:/files

WEBHOOK_URL は、リバースプロキシの内側にいる n8n が「外部サービスに伝えるべき受け口の URL」を正しく組み立てるための設定だ。ここが実際の公開 URL と食い違うと、n8n の画面に表示される Webhook の URL が誤ったものになり、外部サービス側の設定ミスにつながる。N8N_RESTRICT_FILE_ACCESS_TO=/files は、n8n がサーバー上の任意のファイルを読み書きできないよう範囲を絞る安全設定である。

運用で効いてくる 3 つの設定

データベースは SQLite のままでよいか

n8n を素直に立てると、データは n8n_data ボリュームの中の SQLite（1 つのファイルで完結する軽量なデータベース）に保存される。公式は PostgreSQL（本格的なデータベース。DB_TYPE=postgresdb で切り替える）にも対応しており、MySQL と MariaDB はバージョン 1.0 で非対応になった。なお公式ドキュメントは、本番環境でどちらを使うべきかを明示的には述べていない。実行履歴が積み上がって SQLite のファイルが肥大化してきたら移行を検討する、という順序で問題ない。

メモリ不足は「JavaScript heap out of memory」で現れる

セルフホストで注意しておきたい障害のひとつがメモリ切れだ。公式は「n8n は各ノードが取得・処理するデータ量を制限しない」と明記しており、大きなファイルや大量の行を一度に扱うと、ノードの実行が止まって「n8n may have run out of memory while executing it」というメッセージが出る。対処としては、NODE_OPTIONS 環境変数に --max-old-space-size=SIZE を渡して割り当てを増やす方法が案内されている。ただし物理メモリを超えて割り当てることはできないため、根本的にはプランの増強か、ワークフローを分割してデータを小分けに処理する設計が要る。

バックアップは自分で用意する

セルフホストにおいて、バックアップは誰も代わりに取ってくれない。守るべきは n8n_data ボリュームで、ここにワークフロー、認証情報、そして認証情報を復号するための暗号化キーが入っている。暗号化キーを失うと、バックアップからワークフローを戻せても各サービスへの接続情報は復元できない。定期的にボリュームをまるごと退避し、復元手順を一度は実際に試しておく。この「復元の練習」を省くと、必要なときに動かない。

無料のセルフホストで使えない機能

セルフホストの Community edition（無料版）は、ほぼすべての機能が使える。実際に業務で困る場面は少ないが、有料ライセンスが必要な機能は把握しておきたい。公式によれば、SSO（一度のログインで複数サービスを使う仕組み。SAML / LDAP）、ワークフローと認証情報の共有、プロジェクト単位の管理、Git によるバージョン管理、外部シークレット管理、バイナリデータの外部保存、ログのストリーミング配信、複数の主系を並べる multi-main mode が有料版限定となる。

一方で、負荷分散のための queue mode（キューモード）は無料版でも使える。またメールアドレスを登録するだけで、フォルダによる整理、編集画面でのデバッグ、実行データへのメモ付けの 3 機能が無料で解放される。少人数のチームで自社の業務を回すだけなら、無料版の範囲でほぼ完結する。実際の使い方の広がりとしては、請求書を読み取って仕訳（経理で取引を借方・貸方に振り分ける作業）の起票までつなげる例が請求書 OCR の自動化記事に、案件ごとの採算を追う例が利益率管理の自動化記事にまとまっている。

まとめ

• セルフホストの利点は実行回数の上限がないことと、データを自社サーバー内に留められること。n8n Cloud は実行回数で課金される（Starter は年払いで月20ユーロ・月2,500回）
• ライセンスは Sustainable Use License。社内の業務目的なら無料。他社へのホスティング提供や白ラベルでの再販は不可
• 公式のサイジング目安はメモリ 320MB〜2GB、データベース 512MB〜4GB。「最低2GB必要」は公式の数字ではなく、公式は「CPU 集約的ではない」「メモリが CPU に優先する」と述べている
• 本番構成は Docker Compose で traefik + n8n の2コンテナ。n8n 側は 127.0.0.1 に絞り、HTTPS のみで公開する
• 公式例にならい TZ と GENERIC_TIMEZONE をそろえる。定期実行の基準は GENERIC_TIMEZONE で、未設定時の既定はニューヨーク時間
• バックアップ対象は n8n_data ボリューム。暗号化キーを失うと認証情報は復元できない
• 公式は「サーバー管理の経験がなければ n8n Cloud を推奨」と明記している。運用を引き受けられないなら Cloud のほうが安い

セルフホストは「安く済ませる手段」ではなく、実行回数とデータの管理を自分の手に取り戻す代わりに、運用の責任を引き受ける選択である。この交換条件に納得できるなら、構築の手順そのものは公式ドキュメントに沿って進められる。ただし所要時間は、DNS の反映待ちやサーバーの初期設定、Docker の導入状況によって大きく変わる。判断に迷ったら、まず手元の Docker で動かして、自社のワークフローがどれだけメモリを使うかを見てから決めればよい。