SNS調査で出た「Workflowは見えるのにCredentialが読めない」痛みを入口に、公式Docsで仕様確認しています。
n8nのN8N_ENCRYPTION_KEYは、障害が起きてから探すものではありません。Credential復元で詰まらないために、最初に固定して、DB、volume、.env、docker-compose.ymlと同じ束で保管するものです。
Docker更新後に「workflowは見える」「ログインもできる」状態でも、Credentialが復号できなければOAuth、APIキー、Webhook、通知は戻っていません。この記事では、どこを見るか、何をバックアップするか、workflow exportと本番復元をどう分けるかを整理します。
n8n公式Docsでは、初回起動時に暗号化キーを作り、Credential保存前の暗号化に使うと説明されています。Docker Compose例ではn8n_data:/home/node/.n8nがSQLite DBと暗号化キーの保存場所として示されています。つまり、DBだけ、workflow exportだけ、composeだけでは足りません。
復旧時に「Credential could not be decrypted」と出てからキーを探しても、見つからないことがあります。構築時点でN8N_ENCRYPTION_KEYを固定し、復元テストでCredentialのテスト接続まで確認します。
まず起きている痛み
JSONやDB上のworkflowが残っていても、Credentialを復号できなければ本番連携は戻りません。
OAuth、APIキー、DB接続情報が復号できないと、Webhookや定期実行は見た目より深く止まります。
N8N_ENCRYPTION_KEYは障害後に探すものではなく、構築時に固定して保管するものです。
queue modeではmain、worker、webhook processorで同じキーを共有しないとCredentialに触れません。
復元単位を分ける
workflow exportは処理の形、DB/volume/Credential/keyは本番状態、Webhook URLと通知は外部到達です。ここを混ぜると、画面上は戻ったのに実行だけ失敗する状態を見落とします。
| 見えているもの | まだ別に確認するもの | 判断 |
|---|---|---|
| workflowが一覧に出ている | Credentialが復号できるか、参照Credential IDが残っているか。 | 処理の形が残っているだけで、本番復元完了ではありません。 |
| Credential名が表示される | OAuth、APIキー、DB接続、外部APIへのテスト接続。 | 名前だけ見えても、暗号化された中身を読めるとは限りません。 |
| コンテナが起動している | /health、DB接続、worker、queue、Error workflow、実行履歴。 | HTTP 200は入口であり、workflow実行成功の証明ではありません。 |
| Webhook URLが存在する | WEBHOOK_URL、reverse proxy、DNS、HTTPS、production/test URLの違い。 | URLが変わると外部サービス側の登録URLやOAuth redirect URIも壊れます。 |
| 通知先を設定している | Discord/Slack/メールに実際に届くか、障害時にも見る場所か。 | 復旧確認は通知到達まで含めます。 |
WEBHOOK_URLはWebhookだけの話ではない
WEBHOOK_URL はWebhookの本番URLだけでなく、OAuth redirect URIや外部サービス側の登録URLにも影響します。復元後にURLが変わった時は、n8n内の表示だけでなく、外側に登録した送信先まで見直します。
| 影響する場所 | 確認する値 | 壊れ方 |
|---|---|---|
| Webhook本番URL | WEBHOOK_URL、reverse proxy、HTTPS、DNS、production/test URL。 | n8n内では動いて見えても、外部サービスから本番Webhookへ届かなくなります。 |
| OAuth redirect URI | Google、Slack、Notionなど外部サービス側に登録したredirect URI。 | WEBHOOK_URLやドメインが変わると、OAuth再認証やcallbackで失敗します。 |
| 外部サービス側の登録URL | 決済、フォーム、Slack、GitHubなどが送信するWebhook送信先。 | 古いURLへ送られ続け、n8n側では待っていても何も来ません。 |
| 通知と失敗検知 | Error workflow、Discord/Slack/メール通知、実行履歴。 | HTTP 200やコンテナ起動だけを見て、実リクエスト失敗を見落とします。 |
N8N_ENCRYPTION_KEYはどこを見るか
| 見る場所 | 何が分かるか | 詰まりやすい点 | 残すもの |
|---|---|---|---|
.env / env_file | N8N_ENCRYPTION_KEYを明示しているか。 | composeは残っていても、読み込んでいる.envが別ファイルだとキーが変わります。 | 本番の.env、権限、保管場所、更新履歴。 |
~/.n8n / /home/node/.n8n | 初回起動時に作られたキーやSQLite DBが残っている可能性。 | Docker volume名が変わると、新しい空の/home/node/.n8nを見て初期化に見えます。 | n8n_data volume、DB、設定ファイル、mount先。 |
docker-compose.yml | environment、env_file、volume、DB接続先、WEBHOOK_URLの指定。 | イメージ更新時にcomposeを作り直し、volumeやenv_file参照が変わることがあります。 | compose、volume名、network、DBサービス名。 |
| secret manager / パスワード管理 | キーを平文ファイルに置かず、復元時に取り出せる設計か。 | 担当者だけが知っていて、障害時に取り出せないと復旧が止まります。 | 取り出し権限、更新手順、緊急時の連絡先。 |
| queue modeのmain / worker / webhook processor | すべてのプロセスで同じキーが渡っているか。 | mainでは動くのにworkerでCredential復号に失敗する、という形で出ます。 | 各プロセスの環境変数、Redis/queue設定、デプロイテンプレート。 |
n8n/Dify/Docker系は痛みが強い一方で、読者がすでにVPSを持っていることがあります。CTA前では、今すぐ契約する人には本番構成、既存VPSの人には復元テストとバックアップを案内します。
| 読者の状態 | CTA前に処理する不安 | 次の導線 |
|---|---|---|
| これからVPSを契約する | DB、volume、.env、N8N_ENCRYPTION_KEY、Webhook URLを戻せる構成か。 | Docker/バックアップ/監視まで見てXServer VPSなど本番向けVPSを比較する。 |
| すでにVPSを持っている | workflow exportだけで復元できると思っていないか。Credential復号、OAuth/APIキー、通知到達を確認する。 | 今のVPSで復元テストし、無理なら移行先VPSを検討する。 |
| 本番運用へ上げたい | /health 200だけで復旧完了と見なさず、Webhook実行、Credential復号、通知まで分けて見る。 | 監視・バックアップ・復旧チェックの記事へ内部リンクで戻す。 |
料金だけでなく、Docker volume、DB、.env、Credential、監視を残しやすい構成にしておくと、更新後の事故で詰まりにくくなります。
workflow exportと本番復元は違う
n8n公式DocsではworkflowをJSONとしてexport/importできると説明されています。ただし、JSONがあることと、Credentialを復号して外部サービスへ再接続できることは別です。復元後は外部API、Webhook、通知まで動かして確認します。
| 対象 | workflow exportだけで足りるか | 本番復元で見ること |
|---|---|---|
| Workflow JSON | 必要 | 処理の形は戻せます。ただしCredential値そのものが戻るとは限りません。 |
| Credential | 足りない | DB、暗号化キー、OAuth/APIキーの再接続、権限を別に確認します。 |
| DB | 足りない | Postgres/SQLiteのdump、volume、実行履歴、ユーザー情報を確認します。 |
| volume | 足りない | n8n_dataやbinary data、設定ファイルのmount先を確認します。 |
.env / compose | 足りない | N8N_ENCRYPTION_KEY、DB接続、WEBHOOK_URL、timezone、queue設定を戻します。 |
| Webhook / OAuth | 要テスト | WEBHOOK_URL、production/test URL、DNS、HTTPS、redirect URI、APIキーの有効性を実行テストで見ます。 |
復元で確認する順番
初回構築時にN8N_ENCRYPTION_KEYを.envや秘密管理に固定します。
キー、DB、volume、docker-compose.yml、.envを同じ日付で退避します。
別環境でCredential復号とOAuth/APIキーのテスト接続まで確認します。
Docker更新前に参照volume、DB、env_file、WEBHOOK_URLを記録します。
/health 200だけで終えず、Webhook実行と通知到達まで見ます。
| 確認層 | 見るもの | 復旧完了と言える状態 |
|---|---|---|
| 起動 | docker compose ps、ログ、/health | コンテナが起動し、基本ヘルスチェックが通る。 |
| DB | Postgres/SQLite接続、対象DB、volume参照 | 以前のworkflow、Credential、ユーザーが同じDBから見えている。 |
| Credential | Credential一覧、OAuth/APIキーのテスト接続 | 暗号化されたCredentialを復号でき、外部APIを呼べる。 |
| Webhook | WEBHOOK_URL、production/test URL、DNS、HTTPS、reverse proxy、実リクエスト | 外部から本番Webhookへ到達し、workflowが発火する。 |
| Workflow実行 | Error workflow、retry、実行履歴、依存API | 成功/失敗が履歴に残り、失敗時に気づける。 |
| 通知 | Discord/Slack/メールなどの通知先 | 障害時に普段見る場所へ届き、対応記録へつながる。 |
キーの扱いで決めること
| 判断 | おすすめ | 理由 |
|---|---|---|
| 新規構築 | 最初からN8N_ENCRYPTION_KEYを固定する | あとで探すより、復元時に同じ値を渡せる状態を作る方が安全です。 |
| 既存運用 | 現在のキーの所在を確認し、DB/volumeと同時にバックアップする | DBだけ戻してもキーが違うとCredentialが読めません。 |
| 複数プロセス | main、worker、webhook processorで同じキーを配る | queue modeではworkerもCredentialへアクセスします。keyだけでなくDB、Redis、WEBHOOK_URLも揃っているかを見ます。 |
| キー変更 | rotation機能の条件とバックアップを確認してから行う | n8nのrotationは通常の置換ではなく、DBバックアップや互換性確認が必要です。 |
queue modeはプロセスごとにenvを見る
queue modeではmainだけが正しくても足りません。workerやwebhook processor側でN8N_ENCRYPTION_KEY、DB、Redis、WEBHOOK_URLがずれると、片側だけCredentialを読めない、localhostへ戻る、jobを拾えないといった形で出ます。
| プロセス | N8N_ENCRYPTION_KEY | DB | Redis/queue | WEBHOOK_URL |
|---|---|---|---|---|
| main | Credential暗号化/復号の基準になる値を固定。 | 本番DBへ接続してworkflowとCredentialを読む。 | queue modeの接続先とprefixを確認。 | 画面表示やOAuth redirect URIに影響。 |
| worker | mainと同じ値を渡す。ここが違うとCredential復号で失敗。 | mainと同じDBへ接続して実行時のCredentialを読む。 | Redis接続先が違うとjobを拾えない、または別queueを見る。 | 外部URL生成がlocalhostへ戻らないか確認。 |
| webhook processor | Webhook経由の実行でも同じkeyを使える状態にする。 | Webhook実行が本番DBのworkflow/Credentialへ触れるか。 | queueに流す構成ならRedis接続を揃える。 | production URL、reverse proxy、HTTPSを揃える。 |
VPS選定に戻すならここを見る
n8nの復旧力は、CPUやメモリだけでは決まりません。docker-compose.yml、.env、n8n_data volume、Postgres dump、監視通知を残しやすい運用にできるかを見ます。
compose、volume、DB、監視を自分で設計し、内部リンク先の記事と合わせて運用しやすい候補です。
XServer VPSを確認する
FAQ
| 質問 | 答え |
|---|---|
| N8N_ENCRYPTION_KEYはどこにありますか？ | 構成によります。環境変数に明示していなければ、初回起動で作られたキーが~/.n8n配下に保存される扱いです。Docker Compose例ではn8n_data:/home/node/.n8nが重要です。 |
| キーを失くしたらCredentialは復元できますか？ | 一般には厳しいです。DBやworkflowが残っても、暗号化に使ったキーが違うとCredentialを読めません。再入力で戻せる範囲と、キーが必要な範囲を分けて判断します。 |
| workflow exportだけで本番復元できますか？ | できません。workflow JSONは処理の形を戻す材料です。DB、volume、Credential、.env、Webhook、OAuth/APIキーの確認が別に必要です。 |
| queue modeでは何に注意しますか？ | mainだけでなくworker、webhook processorにも同じN8N_ENCRYPTION_KEYを渡します。workerだけ失敗する時は、key、DB接続、Redis/queue設定、WEBHOOK_URLを分けて見ます。 |
| Webhook URLが変わった時は何を見ますか？ | WEBHOOK_URL、reverse proxy、DNS、HTTPS、production/test URLの違い、OAuth redirect URI、外部サービス側の送信先を確認します。 |
| 暗号化キーは定期的に変えるべきですか？ | 自己判断で値を置き換える話ではありません。n8nのencryption key rotationは条件と互換性があるため、DBバックアップと公式手順の確認が先です。 |
/healthが200なら復旧完了ですか？ | いいえ。コンテナ起動の入口にはなりますが、Credential復号、OAuth/APIキー、Webhook実行、通知到達まで分けて確認します。 |
参照した公開情報
本文の入口はSNS調査で拾った実ペインに置き、保存先やqueue mode、rotation、export/import、Webhook URLはn8n公式Docsで確認しています。
- n8n Docs: Set a custom encryption key
- n8n Docs: Encryption key rotation
- n8n Docs: Configuring queue mode
- n8n Docs: Docker Compose
- n8n Docs: Export and import workflows
- n8n Docs: Webhook node
- n8n Docs: WEBHOOK_URL with reverse proxy
- n8n Community: Credentials could not be decrypted
- n8n Community: Resetting encryption key after upgrade
- n8n Community: Different encryption key error
- n8n Community: Worker encryption key after update
確認日: 2026年6月30日。SNS運用側のPriority A後続WaveおよびArticle 80 Waveで収集された、Credential復号不能、N8N_ENCRYPTION_KEY、queue modeのworker差分、workflow exportと本番復元の混同、Webhook URL復旧、/health 200の限界を反映。公式情報は仕様確認、CommunityやX/Reddit由来の声は読者ペインの見出し素材として扱っています。
