広告を含みます。料金、仕様、キャンペーンは公式ページで確認してください。
n8nをDockerで更新・再起動したあとに「データが消えた」「registration pageへ戻った」「Credentialが復号できない」となった時は、記事を読む人が一番焦るところです。
ただし、最初にやるべきことは「消えた」と決めることではありません。まず、今のコンテナがどのvolume、どのDB、どのN8N_ENCRYPTION_KEYを見ているかを確認します。SNS調査でも、ここがn8n self-hostingの強いペインとして繰り返し出てきました。
n8n公式Docsでは、Docker Compose構成でn8n_data:/home/node/.n8nを使い、この場所にSQLite DBや暗号化キーが保存されると説明されています。つまり、更新後に違うvolumeを見れば空に見えますし、DBが残っても暗号化キーが違えばCredentialは読めません。
初回登録画面が出た状態で慌てて進めると、旧データの位置確認が後回しになります。まず停止、退避、volume/DB/key確認、復元テスト、Webhook確認の順に進めます。
まず結論
| 症状 | まず疑う場所 | 確認するもの | 避けたい判断 |
|---|---|---|---|
| Docker更新後に初回登録画面へ戻る | 別のDB/volumeを見ている可能性 | n8n_data、/home/node/.n8n、database.sqlite、composeのvolume名 | すぐに新規登録して上書き運用を始めること |
| Workflowは見えるがCredentialが復号できない | N8N_ENCRYPTION_KEYの不一致 | .env、settings、旧環境の~/.n8n、worker側の環境変数 | Credentialだけ手で入れ直せば終わり、と扱うこと |
| 再起動するたびに古い状態へ戻る | SQLite/volumeの参照ズレ | docker volume ls、Mountpoint、コンテナ内のDBタイムスタンプ | ログにエラーがないから正常、と決めること |
| Webhook URLや実行履歴が戻らない | 復元対象不足 | DB、volume、compose、.env、暗号化キー、外部接続先メモ | workflow exportだけをバックアップ扱いにすること |
料金だけで選ぶより、Docker volume、DB、バックアップ、監視、復元手順を残しやすいVPSを選ぶ方が、あとで効きます。
消えたように見える時にまず見るもの
n8nのDocker更新で怖いのは、原因がひとつに見えないことです。volumeが違う、DBが違う、暗号化キーが違う、Webhook URLが変わる、どれでも「壊れた」ように見えます。
| 見る順番 | 確認ポイント | なぜ重要か | メモ |
|---|---|---|---|
| 1. 現在のvolume | docker inspectやdocker volume inspectで、実際のMountpointを確認する | composeファイルを直したつもりでも、別volumeで起動していると新規環境のように見えます。 | 更新前後でvolume名が変わっていないかを見る |
| 2. DBファイル | /home/node/.n8n/database.sqliteまたはPostgreSQLのDBを確認する | n8nのWorkflow、Credential、実行履歴の多くはDB側にいます。 | SQLiteならタイムスタンプ、PostgreSQLならdump/接続先も確認 |
| 3. 暗号化キー | N8N_ENCRYPTION_KEYまたは~/.n8nの設定を確認する | DBが戻っても、暗号化キーが違うとCredentialが読めません。 | queue modeならworkerにも同じキーが必要 |
| 4. composeと.env | docker-compose.yml、compose.yaml、.envの差分を見る | WEBHOOK_URL、timezone、volume名、DB接続先が変わると挙動も変わります。 | 更新前のファイルを必ず残す |
| 5. 外部到達と監視 | Webhook、HTTPS、通知先、Error workflow、実行履歴を確認する | 起動していても、自動化が本当に復帰したとは限りません。 | Uptime Kumaや外部監視へつなぐ |
バックアップで残すもの
workflow exportは大切ですが、それだけではn8nの本番環境は戻りません。Credential、実行履歴、Webhook、暗号化キー、DB、composeを別物として見ます。
| 残すもの | 含まれるもの | 復元時に困る例 | 扱い方 |
|---|---|---|---|
n8n_data volume | SQLite DB、settings、暗号化キーが入る構成が多い | volume名を変えて起動し、空のn8nに見える | volume名とMountpointを記録し、更新前にsnapshotを取る |
| PostgreSQL DB | Workflow、Credential、実行履歴など | DBだけ古い、または別DBへ接続している | dump、接続先、ユーザー、DB名をセットで残す |
.env | ドメイン、timezone、DB接続、暗号化キー、Webhook URL | WEBHOOK_URLが変わり、連携先のURLを直す羽目になる | パスワードを含むため、公開せず安全な場所へ保管する |
docker-compose.yml | image、ports、volumes、networks、restart設定 | 更新後に別volumeや別networkで起動する | 更新前後の差分を残す |
| Workflow export | 処理の形、ノード構成 | Credential、Webhook、環境変数、実行履歴までは戻らない | 補助バックアップとして使い、DB/volumeの代わりにしない |
| 復元手順メモ | 停止、退避、起動、確認、ロールバックの順番 | 障害時に何から戻すか分からない | 小さな検証環境で一度戻しておく |
N8N_ENCRYPTION_KEYはどこで効くか
n8n公式Docsでは、初回起動時にランダムな暗号化キーを作り、Credential保存前の暗号化に使うと説明されています。復元時の「Credentialが読めない」は、ここがズレた時に起きやすいです。
| 場面 | N8N_ENCRYPTION_KEYで起きること | 確認する場所 | 判断 |
|---|---|---|---|
| 初回起動 | n8nは初回起動時に暗号化キーを作り、Credential暗号化に使います。 | ~/.n8n、settings、または.env | 本番では明示的に固定し、バックアップ対象に入れる |
| Docker更新 | DBは残っていても、キーが変わるとCredentialを復号できません。 | N8N_ENCRYPTION_KEY、旧volume、旧設定 | Workflowが見えるだけでは復旧完了にしない |
| queue mode | workerごとにキーが違うと、実行時にCredentialで詰まります。 | main、worker、環境変数、secret管理 | 全workerへ同じキーを渡す |
| 移行/復元 | DB、volume、暗号化キーがそろって初めてCredential復旧の可能性が高まります。 | 移行元と移行先の.env、DB、volume | キーだけ、DBだけ、workflow exportだけでは不十分 |
更新前にやる順番
更新前にn8nを止め、現在のcompose、.env、volume、DB名を記録します。
volume snapshot、DB dump、.env、compose、暗号化キーを同じ日付で残します。
imageだけでなく、volume名、DB接続先、WEBHOOK_URLが変わっていないか見ます。
ログイン、Workflow、Credentialテスト、Webhook外部到達、Error workflowを確認します。
HTTP 200だけでなく本文エラー、失敗通知、実行履歴、外部監視へつなげます。
/healthが200でも復旧完了ではない
後続Waveでは、/health が200でもWebhookや依存先まで戻っているとは限らない、というペインが強く出ました。n8nの復旧確認は「起動しているか」だけで終わらせず、DB、Credential、Workflow実行、Webhook、通知まで層に分けて見ます。
| レイヤー | 200や起動確認だけで見落とすこと | 確認するもの | 復旧完了の目安 |
|---|---|---|---|
| コンテナ | n8nコンテナが起動していても、別volumeや別DBを見ていることがあります。 | docker ps、container logs、compose、volume名 | 更新前と同じvolume/DBへ接続している |
| DB | 画面が開いても、Workflowや実行履歴が旧状態・空状態のことがあります。 | SQLite/PostgreSQL、DB名、dump、タイムスタンプ | 更新前のWorkflow、実行履歴、設定が見える |
| Credential | Workflowが見えても、暗号化キーが違うとCredentialは使えません。 | N8N_ENCRYPTION_KEY、worker環境変数、Credential test | 主要Credentialの接続テストが通る |
| Webhook | /health が200でも、WebhookのDNS、HTTPS、外部到達、URL変更は別問題です。 | WEBHOOK_URL、DNS、TLS、reverse proxy、外部からのPOST | 外部サービスから本番Webhookへ到達する |
| Workflow実行 | 手動実行は成功しても、Cron、queue、依存API、権限で失敗することがあります。 | 実行履歴、Error workflow、retry、外部API応答 | 本番に近い入力で成功し、失敗通知も動く |
| 通知 | エラーは起きていても、メールだけ、同じVPS内だけだと気づけないことがあります。 | Discord/Slack/メール、外部監視、通知テスト | 障害時にも見る場所へ通知が届く |
VPSは料金だけでなく復元しやすさで選ぶ
n8nを自宅PCや一時検証で動かすだけなら、細かい復元手順を後回しにしがちです。本番Webhookや顧客連携を置くなら、VPS選定時点でバックアップ、監視、通知、DBの場所を決めておきます。
| 用途 | 見るポイント | 候補 | 選ぶ理由 |
|---|---|---|---|
| n8nを小さく検証して本番へ育てる | Docker、HTTPS、バックアップ、監視、プラン変更 | ConoHa VPS | 自動化やAI系の検証を小さく始め、必要に応じて構成を見直しやすい候補です。 |
| Docker/DB/Webhookを自分で組む | volume、SSH、snapshot、内部リンク先の記事との組み合わせ | XServer VPS | Docker、Webhook、PostgreSQL、監視まで自分で設計する読者に合わせやすい候補です。 |
| Linux運用を丁寧に詰める | compose管理、バックアップ、国内リージョン、運用メモ | さくらのVPS | サーバー運用を自分で管理しながら、復元手順まで整えたい人の比較対象になります。 |
VPS、Docker、DB、Webhookを自分で組み合わせ、内部リンク先の記事群とも相性がよい候補です。
XServer VPSを確認する
FAQ
| 質問 | 答え |
|---|---|
| Docker更新後にregistration pageへ戻ったらデータは消えていますか？ | すぐに消えたと決めず、まず別volumeや別DBを見ていないか確認します。n8n公式のDocker Compose例でもn8n_data:/home/node/.n8nが重要です。 |
| Workflowは残っているのにCredentialが復号できない時は？ | N8N_ENCRYPTION_KEYの不一致を疑います。DBが残っていても、暗号化キーが違うとCredentialは読めません。 |
| workflow exportだけ残しておけば復元できますか？ | 処理の形は戻しやすいですが、Credential、実行履歴、Webhook URL、環境変数、DBまでは別です。DB/volume/.env/composeをセットで見ます。 |
| SQLiteとPostgreSQLではどちらが安全ですか？ | 小規模ならSQLiteでも始められますが、復元と監視を考えるならDBの場所、dump、接続先、バックアップ手順を明確にできる構成が重要です。 |
| 復元できたかどうかは何で確認しますか？ | ログイン、Workflow表示、Credentialテスト、Webhook外部到達、Error workflow、実行履歴、通知先まで見ます。n8nが起動しただけでは完了にしません。 |
| /healthが200なら復旧完了ですか？ | 完了ではありません。コンテナの起動確認と、DB、Credential、Webhook、Workflow実行、通知到達は別レイヤーです。特にWebhook DNS failureやCredential復号不能は、/healthだけでは拾えないことがあります。 |
参照した公開情報
この記事では、SNS調査で拾った実ペインを本文の入口にし、公式Docsとn8n Communityの事例で技術的な確認点を補強しています。
- n8n Docs: Docker Compose
- n8n Docs: Set a custom encryption key
- n8n Community: Credentials could not be decrypted
- n8n Community: Docker update and lost data
- n8n Community: Workflows lost after docker restart
- n8n Community: Losing all data after restarting docker
確認日: 2026年6月30日。SNS側Priority A調査で収集された、Docker更新後のregistration page、データ消失に見える症状、Credential復号不能、N8N_ENCRYPTION_KEY、volume参照ズレを本文へ反映。公式仕様はn8n Docs、実ペインはn8n CommunityおよびX/Reddit/SNS調査ログを、validated / needs_date / needs_url / hypothesisで分類して扱っています。