n8nをVPSへセルフホストする方法｜Docker・HTTPS・バックアップまで解説

n8nをVPS（仮想専用サーバー）へセルフホストするときは、Dockerで永続ボリュームを分離し、暗号化キーとタイムゾーンを固定し、reverse proxy（前段に置く中継サーバー）でHTTPSを終端してからwebhookの公開URLを明示的に指定します。そのうえでイメージのバージョンを固定し、バックアップからの復元を試して、再起動や更新後も復旧できる状態を作ります。

セルフホストで最も多い事故は、サーバーが落ちることではなく「動いてはいるが元に戻せない」状態です。この記事では、必須環境変数の一覧、docker composeの最小構成、そして実際に復元まで試すチェックリストを軸に、常時稼働に必要な設定だけを順番に解説します。AI Agentノードの作り込みは「n8nでAI Agentを作る」の領域なので、ここでは扱いません。

情報確認日：2026年7月28日（日本時間）

結論：暗号化キーと公開URLを先に決め、復元テストまでを1セットにする

この記事の結論

データは /home/node/.n8n に集まる。ここを永続ボリュームにしないと更新のたびに消える
N8N_ENCRYPTION_KEY を明示指定して控えを取る。これを失うとcredentialを復号できない
タイムゾーンは TZ と GENERIC_TIMEZONE の2つを設定する
HTTPSはreverse proxyで終端し、n8n自身は127.0.0.1にだけ公開する
reverse proxyの背後では WEBHOOK_URL とproxy段数を明示し、生成されたURLを検証する
バックアップは「取得できた」ではなく「別環境で復元してworkflowが動いた」で完了とする
ライセンスはfair-code系のSustainable Use License。用途によっては別契約が必要になる

n8nをセルフホストする前の判断

Cloud版とVPS版の責任範囲

同じn8nでも、Cloud版とセルフホストでは自分が負う範囲がまったく違います。セルフホストを選ぶということは、インフラの用意と維持、つまりOS更新、証明書の更新、バックアップ、障害時の復旧をすべて自分で持つという意味です。公式ドキュメントもセルフホスト利用者について、インフラの提供と管理、そして保守を自分の責任として説明しています。

もう1つ、機能面の線引きも先に把握しておくべきです。無償のCommunity Editionはn8nのほぼ全機能を含みますが、公式ドキュメントによれば次の機能は含まれません。

Custom Variables（独自変数）、Environments（環境の切り替え）、External secrets（外部シークレット管理）
バイナリデータの外部ストレージ、Log streaming（ログの外部転送）
Multi-main mode（キューモード自体は利用可能）、Projects（プロジェクト単位の管理）
SSO（SAML、LDAP）、workflowとcredentialの共有（インスタンス所有者と作成者のみアクセス可能）
Gitによるバージョン管理

無償のライセンスキーを登録するRegistered Community Editionでは、Folders、Debug in editor、Custom execution dataに加えて、24時間分のWorkflow historyが使えるようになります。解放機能は将来変更される可能性があるため、導入判断の前にCommunity Editionの機能表と料金ページを確認してください。

ライセンスの前提を先に確認してください。n8nのソースコードはSustainable Use Licenseで公開されています。これはfair-code（ソースを公開しつつ利用範囲に制限を置く方針）に沿ったライセンスで、利用・改変は自社の内部業務目的または非商用・個人利用、他者への配布は非商用かつ無償、表示の改変・削除は禁止という制限があります。一方、公式FAQは、n8n関連の有償コンサルティング、workflow構築、顧客企業の社内サーバーへの設置・保守を許可例として明示しています。ホワイトラベル化して販売する、n8nをホストして利用料を取るなど、価値が実質的にn8nの機能から生じるサービスは許可されない例です。受託そのものを一律に不可とせず、顧客がn8nへ直接アクセスするか、n8n自体をサービスとして販売するかまで含めて公式FAQと条文で判断してください。

必要なCPU・メモリ・ディスクの考え方

n8nは推奨スペックを一律の数字で示していないため、自分のworkflowの性質から逆算します。見るべき軸は3つです。

同時実行数：webhookトリガーが多いほど、同時に立ち上がる実行の数が増えます。ノードの処理内容によってCPUとメモリのどちらもボトルネックになり得ます
1実行あたりのデータ量：API応答をそのまま次のノードへ渡す設計では、中間データがメモリに乗ります。数万件のレコードを1回のworkflowで扱うなら、件数を分割する設計のほうが増設より効果的です
ファイルの扱い：PDFや画像を経由させるworkflowでは、バイナリデータがディスクとメモリの両方を消費します

ディスクについては、データベースの選択が効いてきます。DB_TYPE の既定値は sqlite で、SQLiteのファイルは /home/node/.n8n の中に置かれます。実行履歴が増えるほどこのファイルが育つため、履歴の保持期間を決めずに運用するとディスクが先に埋まります。PostgreSQLへ切り替える場合は DB_TYPE=postgresdb にしたうえで DB_POSTGRESDB_HOST、DB_POSTGRESDB_PORT（既定5432）、DB_POSTGRESDB_DATABASE（既定n8n）、DB_POSTGRESDB_USER（既定postgres）、DB_POSTGRESDB_PASSWORD、DB_POSTGRESDB_SCHEMA（既定public）を指定します。なおMySQLとMariaDBのサポートはv1.0で非推奨になっています。

SQLiteを使い続ける場合は DB_SQLITE_POOL_SIZE を0より大きい値にするとWALモードで動作します。公式ドキュメントはWALモードについて「rollback journalモードより大幅に高速で信頼性が高い」と説明しています。

Dockerでn8nを起動する

永続ボリュームと環境変数を設定する

公式のDocker手順は、先に名前付きボリュームを作り、そこを /home/node/.n8n にマウントする流れです。

docker volume create n8n_data

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:2.30.5

起動後は http://localhost:5678 でエディタに接続できます。ただしこの例の --rm は終了時にコンテナを削除する指定なので、動作確認向けです。常時稼働させるならコンテナを残し、再起動ポリシーを付けた構成に置き換えます。2.30.5 は情報確認日時点のstableです。導入時は最新のstableとリリースノートを確認し、検証した固定タグへ置き換えてください。

マウント先の /home/node/.n8n が持つ意味は重要です。公式ドキュメントは、PostgreSQLを使う場合はSQLiteのデータベースファイルこそ不要になるものの、このディレクトリには暗号化キー、インスタンスのログ、source control機能の資材といった重要なデータが引き続き置かれると説明しています。つまりPostgreSQLに移しても、このボリュームをバックアップ対象から外してはいけません。

セルフホストで最低限押さえたい環境変数を一覧にします。設定例は「n8n.example.com で公開する」前提で書いています。

環境変数	役割	既定値	設定例
`N8N_ENCRYPTION_KEY`	データベース内のcredential（接続情報）を暗号化する鍵	n8nが生成するランダムな鍵	自分で生成した長い文字列
`GENERIC_TIMEZONE`	Schedule系ノードが使うタイムゾーン	—	`Asia/Tokyo`
`TZ`	システムのタイムゾーン。`date` などコマンドの返り値を左右する	—	`Asia/Tokyo`
`N8N_HOST`	n8nが動作するホスト名	`localhost`	`n8n.example.com`
`N8N_PORT`	n8nが待ち受けるHTTPポート	`5678`	`5678`
`N8N_PROTOCOL`	n8nへ到達するために使うプロトコル（httpまたはhttps）	`http`	`https`
`N8N_EDITOR_BASE_URL`	利用者がエディタへアクセスする公開URL。n8nが送信するメールやSAML認証のリダイレクト先にも使われる	—	`https://n8n.example.com/`
`WEBHOOK_URL`	エディタ上に表示し、外部サービスへ登録するwebhook（外部からの通知を受け取る入口）のベースURL	—	`https://n8n.example.com/`
`N8N_PROXY_HOPS`	n8nの前段にある信頼するproxyの段数	`0`	`1`
`N8N_LISTEN_ADDRESS`	n8nが待ち受けるIPアドレス	`::`	既定のまま
`N8N_PATH`	n8nを配置するパス	`/`	既定のまま
`N8N_SECURE_COOKIE`	cookieをHTTPS経由でのみ送信する	`true`	既定のまま
`N8N_BLOCK_ENV_ACCESS_IN_NODE`	`true` にすると、式やCodeノードから環境変数を読めなくなる	v2.0系は`true`	`true`
`N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES`	`true` で `.n8n` ディレクトリと利用者定義の設定ファイルへのアクセスを遮断する	`true`	既定のまま
`N8N_RESTRICT_FILE_ACCESS_TO`	ファイルアクセスを許可するディレクトリを限定する。複数はセミコロン区切り	空	`/files`
`N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS`	設定ファイルの権限を0600に設定し、所有者だけが読み書きできるようにする	`false`	`true`
`DB_TYPE`	使用するデータベースの種類（`sqlite` または `postgresdb`）	`sqlite`	`postgresdb`

この表以外にも、二要素認証機能を有効にする N8N_MFA_ENABLED（既定 true）、cookieのSameSite挙動を決める N8N_SAMESITE_COOKIE（既定 lax）などがあります。変数の既定値や名称はメジャーバージョンで変わるため、使う固定タグのドキュメントと起動ログを確認してください。

タイムゾーンと暗号化キーを固定する

タイムゾーンを2つ設定する理由は、担当範囲が違うからです。公式ドキュメントの説明では、TZ はシステムのタイムゾーンを設定して date のようなスクリプトやコマンドが返す値を制御し、GENERIC_TIMEZONE はスケジュール指向のノードに正しいタイムゾーンを設定します。片方だけ設定すると、UIに表示される時刻と実際にトリガーが発火する時刻がずれ、原因の特定に時間を取られます。

暗号化キーはさらに重要です。N8N_ENCRYPTION_KEY は、既定ではn8nがランダムに生成した鍵が使われ、データベース内のcredentialを暗号化するために用いられます。ここを明示指定せずに運用すると、生成された鍵は永続ボリューム側にだけ存在することになります。データベースだけをバックアップして鍵を持たずに復元すると、workflowは復元できてもcredentialが復号できない状態になります。

したがって、最初の起動より前に自分でキーを生成し、パスワードマネージャなどworkflowとは別の場所に保管してから起動してください。すでに稼働中のインスタンスで単純に値を変更すると、既存のcredentialが読めなくなります。鍵のローテーション機能は、N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION を全main・workerで有効にする一方向の変更です。公式ドキュメントは、実施前にデータベース全体をバックアップし、有効化後は設定を外さないよう警告しています。単なる環境変数の差し替えとして扱わず、対象バージョンの手順に従ってください。

API keyそのものの持ち方や、漏れたときの止め方は「AI APIキーの管理方法」で整理しています。

ドメインとHTTPSを設定する

reverse proxy経由で公開する

公式ドキュメントは、SSLの設定方法としてTraefikのようなreverse proxyやネットワークロードバランサーをn8nの前段に置くことを推奨しています。代替として N8N_SSL_CERT と N8N_SSL_KEY に証明書と鍵のファイルを指定して、n8nへ直接証明書を渡す方法もありますが、この場合は証明書を自分で更新し続ける必要があると注意されています。

n8n公式のhostingリポジトリには、PostgreSQL、PostgreSQL＋Redis＋worker、SSL付きのsubfolder、Caddyを使う構成例があります。コピーするときはREADMEだけでなく、同じディレクトリにある初期化スクリプトや設定ファイルも含めて取得し、利用するn8nの版と構成を揃えてください。reverse proxyの証明書保存先、n8nの /home/node/.n8n、PostgreSQLのデータは、それぞれ永続化とバックアップが必要です。

ここでは、すでにnginxやCaddyを運用しているサーバーへ載せる想定の最小構成を示します。n8n側のポートを127.0.0.1に絞っているのがポイントで、こうしておくと同じホスト上のreverse proxy以外からは5678番へ到達できません。

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:2.30.5
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://n8n.example.com/
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Asia/Tokyo
      - TZ=Asia/Tokyo
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_RUNNERS_ENABLED=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

N8N_ENCRYPTION_KEY の値をcompose本体へ直接書かず ${...} で外に出しているのは、compose.yamlをバージョン管理へ入れても鍵が一緒に入らないようにするためです。秘密値を置くファイルはバージョン管理から除外し、権限を絞り、暗号化した別媒体にも保管します。サポートされる変数では _FILE 形式やDocker secretsも検討してください。

この構成は単一コンテナで始める最小例です。CodeノードのJavaScriptやPythonを実行するtask runnerは、productionではn8n本体とプロセスを分離するexternal modeが公式推奨です。Codeノードを使う本番環境では、同じバージョンの n8nio/runners を別コンテナで起動し、N8N_RUNNERS_MODE=external、共有認証トークン、Docker内部だけで到達できるbrokerを設定します。編集権限は信頼できる管理者に限定し、runner側へ不要な秘密値やホストのソケットを渡さないでください。

webhook URLを正しく生成させる

reverse proxyの背後にn8nを置くと、n8nが内部で使うポート（5678）とproxyが外部へ公開するポート（443）が食い違うため、URLの自動構成が正しく働きません。公式ドキュメントはこの状況について、n8nがエディタUIに正しいURLを表示し、外部サービスへ正しいwebhook URLを登録できるように WEBHOOK_URL を設定すると説明しています。

変数名は WEBHOOK_URL です。N8N_WEBHOOK_URL はn8n本体の有効な設定名ではありません。既存記事や別アプリの変数名と混同せず、n8nのコンテナ内に WEBHOOK_URL が設定されていることを確認してください。proxyは X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Proto を転送し、N8N_PROXY_HOPS は実際に信頼するproxyの段数へ合わせます。大きすぎる値を推測で入れると、信頼してはいけない転送ヘッダーを採用するおそれがあります。

export WEBHOOK_URL=https://n8n.example.com/
export N8N_PROXY_HOPS=1

設定後は、Webhookノードを1つ置いて表示されるProduction URLが https:// から始まる公開ドメインになっているかを目視で確認します。ここが http://localhost:5678/... のままなら、外部サービス側に登録しても通知は届きません。あわせて、proxy側でリクエストヘッダーを転送する設定と、webhookに必要な待ち時間（タイムアウト）が十分かも確認してください。

認証・更新・秘密情報を守る

管理画面へのアクセスを制限する

n8nのユーザー管理は既定で有効で、最初にowner（所有者）アカウントを作成します。環境変数でownerを管理する場合は N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true に加え、メールアドレス、氏名、bcryptで事前にハッシュ化したパスワードを一式で設定します。平文パスワードを入れるとログインできません。また有効中は起動のたびに値が再適用され、UIからの変更はロックされます。

ただし、ログイン画面があること自体は「誰も到達できない」ことを意味しません。VPSに置く以上、エディタのURLは世界中から叩ける状態にあります。次の3層で考えてください。

ネットワーク層：5678番をホスト外へ公開しない。管理画面へのアクセス元IPをproxy側で制限できるなら、それが最も確実です
認証層：長く固有のパスワードを使い、各ユーザーが二要素認証を有効にします。共有アカウントを避け、Community EditionにないProjectsや共有機能が必要なら有償プランとの境界を確認します
公開範囲：webhookのエンドポイントは認証なしで到達できる前提で設計し、workflow側で受信内容を検証します

更新は、リリースノートとbreaking changesを確認し、復元可能なバックアップを取ってから、compose.yamlの固定タグを検証済みの版へ変更します。その後 docker compose pull と docker compose up -d を実行し、起動ログ、migration、エディタ、代表workflow、webhookを確認します。latest の自動追従は、いつ内容が変わったか追えないため常時稼働には向きません。タグを前の値へ戻すだけで必ず切り戻せるわけでもありません。データベースmigrationが走った場合に備え、更新前のDBとボリュームをセットで復元する手順まで用意してください。main・worker・runnerを分ける構成は全コンポーネントを同じn8nバージョンへ揃えます。

credentialとログを外へ出さない

セルフホストで守るべき秘密情報は、credential、暗号化キー、そして実行ログの3つです。実行ログにはAPIの応答がそのまま残ることがあるため、個人情報や外部サービスのトークンが含まれていないかを一度確認してください。

設定で締められる範囲は次のとおりです。v2.0系では N8N_BLOCK_ENV_ACCESS_IN_NODE が既定で true になり、式やCodeノードから環境変数を読めない方向へ変わりました。過去構成から移行するときも false に戻さず、秘密値はcredentialとして渡します。ファイルアクセスは N8N_RESTRICT_FILE_ACCESS_TO で許可ディレクトリを限定し、N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES で .n8n ディレクトリと利用者定義の設定ファイルへのアクセスを遮断します。さらに n8n audit を定期実行し、危険なノード、保護されていないwebhook、古いバージョンを確認します。

外部APIを呼ぶworkflowでは、鍵の管理に加えて呼び出し回数そのものが問題になります。無限ループやリトライの設計を誤ると、想定外の請求につながります。この観点は「AI APIのコスト管理」で扱っています。

バックアップと障害復旧を試す

DB・設定・暗号化キーを保存する

バックアップ対象を「n8nのデータ」と一括りにすると、必ず何かが抜けます。次の4系統に分けて考えてください。

永続ボリューム：n8n_data（/home/node/.n8n）。暗号化キー、インスタンスのログ、source control機能の資材が入り、SQLite利用時はデータベースファイルも含まれます
データベース：PostgreSQLを使っている場合は、そのダンプ。SQLiteの場合は1に含まれます
構成と秘密値：compose.yaml と環境変数の項目一覧。実値と暗号化キーはアクセス制御したsecret保管先に分離し、通常のバックアップフォルダやGitへ平文で混ぜません
論理エクスポート：workflowとcredentialのJSON。ボリュームごと壊れたときの最後の砦になります

4番目にはn8nのコマンドラインが使えます。次はcomposeのサービス名が n8n で、論理バックアップも永続ボリューム内へ一時出力する例です。出力後はボリュームのスナップショットや暗号化した外部保管へ移します。

# workflowをまとめて書き出す
docker compose exec -T -u node n8n \
  n8n export:workflow --backup --output=/home/node/.n8n/backups/workflows/

# credentialを書き出す（暗号化されたまま）
docker compose exec -T -u node n8n \
  n8n export:credentials --all --output=/home/node/.n8n/backups/credentials.json

# 復元する
docker compose exec -T -u node n8n \
  n8n import:workflow --separate --input=/home/node/.n8n/backups/workflows/
docker compose exec -T -u node n8n \
  n8n import:credentials --input=/home/node/.n8n/backups/credentials.json

export:credentials には --decrypted という指定もありますが、全credentialが平文でファイルへ残ります。通常のバックアップでは使わず、別の鍵へ移行するなど避けられない場合だけ、暗号化された一時領域、最小権限、短い保持期限、確実な破棄を先に設計してください。SQLiteファイルやボリュームを物理バックアップする場合は、稼働中ファイルの単純コピーでは整合性を保証できません。n8nを停止してスナップショットを取るか、利用するストレージ／データベースの整合性あるバックアップ手順を使います。

別環境へ復元してworkflowを実行する

ここが本題です。バックアップは、隔離した別環境で復元し、安全なテストworkflowが動いたところまで確認して初めて有効といえます。復元したDBにはactiveなworkflowも含まれるため、公開前の起動でもScheduleや外部API呼び出しが動く可能性があります。DNSと受信ポートだけでなく外向き通信も制限し、本番の相手へ副作用を出さない環境で、四半期に一度など頻度を決めて次のチェックリストを実行します。

段階	実施内容	確認項目
1. 取得	整合性あるボリューム／DBバックアップ、compose.yaml、環境変数の項目一覧、workflow／credentialのJSONを世代管理する	秘密値と暗号化キーを別の保護された場所から復旧できるか
2. 隔離	本番とは別のホストまたはネットワークに、同じ固定タグの空のn8nを用意する	外部公開と本番向けの外向き通信を遮断しているか
3. 復元	環境変数を先に投入し、ボリュームまたはDBダンプを戻す	`N8N_ENCRYPTION_KEY` が本番と同一か
4. 起動	隔離状態のまま復元先を起動し、ログとmigrationを確認してエディタへログインする	予期しないtriggerや外部通信が発生していないか
5. credential	credentialを1件開き、接続テストを行う	復号できているか（鍵が違うとここで失敗する）
6. 実行	外部へ副作用を出さないworkflowを1本、手動実行する	期待どおりの出力が返るか
7. 時刻	Scheduleノードの次回実行時刻を確認する	日本時間で表示されているか
8. webhook	Webhookノードの本番URLを確認する	公開ドメインのHTTPSになっているか
9. 記録	所要時間と詰まった箇所を手順書に反映する	次回、同じ手順で再現できるか
10. 破棄	復元先を確実に停止・削除する	二重にトリガーが動いていないか

6番で「外部へ副作用を出さないworkflow」を選ぶのは、復元テスト中の実行が本番と同じ相手にメールを送ったりレコードを作ったりしないようにするためです。テスト専用のworkflowをあらかじめ1本用意し、credentialの接続テスト先もsandboxへ切り替えます。10番も忘れないでください。復元した環境を放置すると、ネットワーク制限を外した時点で同じスケジュールが二重に動くおそれがあります。

よくある失敗

暗号化キーを控えずにサーバーを作り直す

最も痛い失敗です。N8N_ENCRYPTION_KEY を明示していないと、n8nが生成した鍵は永続ボリュームの中だけに存在します。DBのバックアップだけを持って新しいサーバーに移ると、workflowは戻ってもcredentialが復号できず、全接続を登録し直すことになります。最初の起動より前に鍵を決め、n8nとは別の場所へ保管してください。

webhook URLを設定せず外部連携が届かない

reverse proxyの背後では、n8nが表示するURLと外部から到達できるURLが一致しないことがあります。正しい変数 WEBHOOK_URL と N8N_PROXY_HOPS を設定し、proxyの転送ヘッダー、Production URL、OAuthのredirect URLを実際に確認してください。N8N_WEBHOOK_URL はn8n本体の設定として認識されません。

バックアップを取っただけで復元を試さない

「毎晩バックアップしている」状態と「復旧できる」状態は別物です。実際に試すと、暗号化キーが対象から漏れていた、環境変数が手元に残っていない、イメージのバージョンが違って起動しない、といった問題がまとめて見つかります。障害の当日に初めて試すのが最悪の選択です。

よくある質問

SQLiteのままでも本番運用できますか？

小規模で同時実行が少ない用途なら動作します。ただし実行履歴が増えるとファイルが育ち、ディスクとバックアップ時間の両方を圧迫します。DB_TYPE の既定は sqlite で、PostgreSQLへ切り替える場合は DB_POSTGRESDB_* の各変数を設定します。切り替えても /home/node/.n8n には暗号化キーなどが残るため、ボリュームのバックアップは引き続き必要です。

暗号化キーは後から変更できますか？

単純に値を差し替えると既存のcredentialが復号できなくなります。ローテーション機能は全main・workerで有効にする一方向の変更で、実施前のDB全体バックアップが必要です。対象バージョンの公式手順どおりに行い、有効化後は設定を外さないでください。

自宅サーバーでも同じ手順で動きますか？

Dockerの起動手順やバックアップの考え方は同じです。違うのは外部からの到達性で、固定IPがなくてもDNS更新や安全に構成したtunnelで公開できる場合はあります。ただし外部サービスが到達できる安定したHTTPS URLが必要です。ルーターで直接ポートを開放すると自宅ネットワークが攻撃面に入るため、ネットワーク分離、受信制御、更新、監視まで含めて判断してください。

受託案件で顧客用のn8nを立てても問題ありませんか？

受託であることだけを理由に別契約が必要とは限りません。公式FAQは、有償のworkflow構築、n8nに密接する機能開発、顧客企業の社内サーバーへの設置・保守を許可例にしています。一方、ホワイトラベル版を販売する、n8nをホストしてアクセス料を取るなどは不可の例です。顧客がn8nを直接使う提供形態や埋め込みは条件が変わるため、公式FAQを確認し、不明ならn8nへ問い合わせてください。

まとめ

n8nのセルフホストは、Dockerで起動するところまでなら数分で終わります。難しいのはその後で、暗号化キーの管理、公開URLの明示、reverse proxyでのHTTPS終端、そしてバックアップと復元という4点を押さえられているかどうかで、半年後の運用が変わります。特に N8N_ENCRYPTION_KEY は最初の起動より前に決め、n8nの外へ控えを取ってください。

設定を終えたら、この記事の10項目のチェックリストで実際に別環境へ復元し、credentialの接続テストとworkflowの手動実行まで通してください。ここまで確認できて初めて、常時稼働させる準備が整ったといえます。環境変数の詳細やライセンスの条件はバージョンによって変わるため、構成を固定する前に必ず公式ドキュメントで最新の内容を確認してください。