n8nをVPSへ
移行する方法
止める・移す・戻す

結論：旧環境を消さず、書込みを止めてから移す

安全な順序は、棚卸し、旧環境の書込み停止、バックアップ、移行先への復元、手動実行、外部連携確認、DNS切替、監視、旧環境の保留。先にVPSを解約すると、credential、実行履歴、Webhookのどこで失敗したかを切り分けにくい。

移行中は新旧n8nを同時に本番稼働させない。同じSchedule TriggerやWebhookが両方で動くと、メール送信、顧客登録、請求処理が二重実行される。停止時間を取れない構成は、単一VPSのファイル移行ではなく、データベースと実行方式を含む別設計が必要。

当サイトで実測した範囲

n8n 2.33.7、SQLite、固定workflow、外部credentialなしの隔離環境で、旧データvolumeの実行、停止後バックアップ、異なる移行先volumeへの復元と再実行、旧volumeの再実行による切戻しを確認した。3段階すべてPASS。公開サマリーは移行・切戻し実測JSON、条件と限界は実測レポートに固定した。

3段階PASSは、本番移行成功率や無停止を示さない。同一バージョン・SQLite・直列CLI実行だけの復元確認。実環境ではDB、binary data、community node、外部API、時刻依存処理を追加で検証する。

移行前に7項目を棚卸しする

1. n8nバージョン：移行元と移行先を同じ固定バージョンから始める。移行とアップデートを同時に行わない。
2. データベース：SQLiteかPostgresか、接続先、容量、バックアップ方式、実行履歴を移すかを記録する。
3. 暗号化キー：N8N_ENCRYPTION_KEYまたは~/.n8n内の設定を安全に保管する。公開リポジトリへ置かない。
4. binary data：filesystem、S3などの保存方式と実体を確認する。DBだけ移して完了にしない。
5. 拡張：community node、環境変数、外部ファイル、ライセンス、task runner設定を一覧化する。
6. 公開経路：ドメイン、A・AAAAレコード、TLS、reverse proxy、Firewall、公開ポートを記録する。
7. 外部連携：Webhook送信元、OAuth callback、IP許可リスト、固定IP依存、Schedule Triggerを一覧化する。

移行先VPSの容量は、現在の平均だけでなくピークと復元時間から決める。1GB・2GB・4GBの限定負荷結果はn8n VPSの必要メモリ実測、月額と保守時間はn8n向けVPS比較に分けた。

手順1：停止前バックアップと戻り道を作る

まず通常稼働中のバックアップを取得し、復元できるか別環境で試す。次に移行時間を告知し、Schedule Triggerと外部からの書込みを止める。最後の書込みが終わった後、n8nを停止して最終バックアップを取得する。

DockerのSQLite構成では、~/.n8n/database.sqliteだけでなく、暗号化キーを含む設定とbinary dataを含めて永続volumeを扱う。稼働中のSQLiteファイルを単純コピーせず、n8n停止後の整合したバックアップを使う。

Postgres構成では、Postgres側の整合したバックアップと~/.n8nの永続データを分けて保管する。外部ストレージへbinary dataを置いている場合、その保存先とアクセス権も移行対象。

DB種別を変える場合

n8nのServer CLIはexport:entitiesとimport:entitiesでSQLiteとPostgres間の移行に対応する。実行履歴のdata tableは既定でexport対象外。必要な場合だけ明示的に含め、容量と機密性を確認する。import先DBは空を前提にする。workflow・credential単位のimportでは同じIDの上書きへ注意する。

Server CLIはself-hosted環境でDBへ直接アクセスする運用者向け機能。n8n公式は、instance間でworkflowを新しく移す場合はn8n CLIのpackage機能を推奨している。ただしpackage機能はpreview。対象workflow、folder、project、参照関係と、移らない秘密情報を検証環境で確認してから使う。

export:credentials --decryptedは平文の秘密を出力する。同じ暗号化キーを安全に移せるなら使わない。異なるキーへの移行で避けられない場合も、出力先、閲覧権限、転送、削除を先に設計する。

n8n CloudからVPSへ移す場合

n8n Cloudのinstance ownerは、Cloud admin dashboardから直近backupのworkflowをdownloadできる。trial終了後も90日間はdownload可能と公式案内にあるが、期限まで待たず、解約前に取得・内容確認する。

workflow JSONにはcredential名とIDが含まれる場合があるが、workflow搬出だけで接続秘密を移行したことにはならない。移行先VPSでcredentialを安全に作り直し、workflowへ割り当て、OAuth callbackとscopeを再承認する。実行履歴、Cloud固有設定、利用中プランの機能差も別に確認する。

Cloudとself-hostedは管理権限と搬出経路が違う。self-hosted向けServer CLIでCloudのDBを直接backupできる前提にしない。重要workflowを1つずつimportし、sandbox credential、手動実行、Webhookの順で再接続する。

手順2：同じバージョンで移行先を復元する

1. 移行元と同じn8nイメージ・versionを固定する。
2. 移行先のn8nを本番公開せず、空の永続volumeまたは空DBを用意する。
3. 暗号化キーを秘密管理から設定し、バックアップを復元する。
4. binary data、community node、環境変数、外部ファイルを戻す。
5. 本番Triggerを発火させない状態で起動し、DB migrationとログを確認する。

credential名が見えるだけでは復号確認にならない。副作用の小さい検証用workflowで外部APIへ接続し、認証エラーがないか確認する。メール送信、顧客作成、決済などの本番操作を検証に使わない。

手順3：固定入力で重要workflowを再実行する

重要workflowごとに、入力、期待出力、許容時間、副作用の有無を固定する。成功表示だけでなく、件数、合計、分岐、重複、エラー履歴を比較する。時刻や外部API応答で結果が変わる部分は、テストデータかsandboxへ置き換える。

n8nのServer CLIは保存済みworkflowをn8n execute --id <ID>で実行できる。当サイトの隔離ラボもこの経路で移行元、移行先、切戻し後の同じ固定workflowを照合した。

手順4：DNS・HTTPS・Webhookを切り替える

1. 切替の24〜48時間前を目安にDNS TTLを下げる。現在値とproviderの下限に合わせる。
2. 移行先でTLS証明書、80・443、reverse proxy、Firewallを確認する。
3. N8N_WEBHOOK_URLへ外部公開URL、proxyが1段ならN8N_PROXY_HOPS=1を設定する。
4. 最後段のproxyからX-Forwarded-For、X-Forwarded-Host、X-Forwarded-Protoを渡す。
5. Aレコードと、利用中ならAAAAレコードを移行先へ向ける。
6. 外部からHTTPSとテストWebhookへ到達できることを確認する。

旧環境と同じhostnameを維持しても、Webhookの再登録が必要なサービスがある。n8n画面に表示されるProduction URLだけで判断せず、送信元サービスの履歴とn8nのexecutionを両方確認する。

手順5：OAuthとIP制限を再確認する

OAuth callbackのhostnameが同じでも、credentialのtoken、provider側のcallback登録、送信元IP制限、秘密鍵ファイルが移行後も有効とは限らない。読み取り専用またはsandboxの操作でcredentialごとに接続確認する。

VPS変更で送信元IPが変わる。Google Workspace、社内API、SFTP、データベース、Firewallで旧IPだけを許可している場合、新IPを先に追加し、移行完了後に旧IPを外す。追加と削除を同時に行わない。

手順6：切替後24〜48時間を監視する

• 失敗・待機・長時間実行の件数
• Webhookの到達数と送信元側の再試行
• Schedule Triggerの二重実行
• CPU、メモリ、ディスク、DB接続、backup成否
• TLS証明書、DNS A・AAAA、外部監視の到達

旧環境は停止したまま保持する。移行先で新しい本番データが作られた後、旧環境へ戻すとデータが分岐する。切戻し判断を遅らせず、必要な新規実行を再処理できる形で記録する。

切戻し手順を移行前に固定する

1. 移行先のSchedule Triggerと受信を止め、新しい書込みを凍結する。
2. 移行先で発生したexecutionと外部への副作用を一覧化する。
3. DNSのA・AAAAを旧IPへ戻し、TLSとproxyを確認する。
4. 旧環境を起動し、固定workflowとcredentialを再確認する。
5. 不足する外部処理だけをidempotency keyまたは記録から再実行する。

DBを自動で逆同期しない。新旧DBの差分を理解せず上書きすると、成功済み処理の再実行や実行履歴の欠落を起こす。書込み再開前に「どちらを正本にするか」を決める。

XServer VPSを移行先にする場合

XServer VPSはn8nアプリイメージとドメイン・SSLクイック設定を提供する。ConoHa VPSはn8nスタートアップスクリプトとCaddyによるHTTPSを提供する。どちらも初期構築は短縮できるが、既存データの復元、暗号化キー、Webhook、OAuth、切戻しは利用者側の作業。新規構築の順序はXServer VPSでn8nを始める手順、ConoHa VPSの画像付きセットアップで確認できる。

アプリイメージのn8nバージョンと移行元が違う場合、移行とversion updateを分ける。先に同versionで復元できる構成を作るか、複製環境で段階的なupdateを検証する。

よくある質問

n8nのworkflowだけexportすれば移行できる？

workflowだけでは不十分。credential、暗号化キー、DB、binary data、community node、環境変数、Webhook、OAuth、実行履歴の要否を別に確認する。

旧VPSと新VPSを同時に動かしてもよい？

本番Triggerを両方で有効にしない。Schedule TriggerやWebhookが二重実行される。移行先は外部公開とTriggerを止めた状態で検証し、切替時に正本を1つへ固定する。

DNSを戻せば完全にロールバックできる？

DNSだけでは完全に戻らない。移行先で発生したexecution、外部APIの副作用、DB書込みは旧環境へ自動反映されない。切戻し前に差分を記録し、重複なく再処理する。

移行とn8nアップデートを同時にしてよい？

分ける。移行元と同versionで復元と重要workflowを確認し、移行完了後に別の変更としてupdateする。障害原因を移行とversion差へ同時に増やさない。

公式情報

• n8n Server CLI：export・import・workflow実行
• n8n暗号化キー設定
• n8n reverse proxy・Webhook URL設定
• n8n SQLite・Postgres設定
• n8n Docker永続volume
• n8n Cloudからworkflowをdownload
• n8n workflowのexport・import

広告・更新履歴

本ページはアフィリエイト広告を含む。広告の有無で移行手順、検証範囲、切戻し条件を変更しない。申込み前に公式ページで最新料金、契約期間、支払総額、解約条件を確認する。

初稿・公式手順確認：2026-08-12 / Docker別volume移行・切戻し：PASS / DNS・TLS・Webhook・OAuth：未測定 / 次回更新：公開VPSでの切替試験後