サーバー選びナビ

タグ: Credential

  • n8nのN8N_ENCRYPTION_KEYはどこにある？Credential復元で詰まる前に見ること

    SNS調査で出た「Workflowは見えるのにCredentialが読めない」痛みを入口に、公式Docsで仕様確認しています。

    n8nのN8N_ENCRYPTION_KEYは、障害が起きてから探すものではありません。Credential復元で詰まらないために、最初に固定して、DB、volume、.env、docker-compose.ymlと同じ束で保管するものです。

    Docker更新後に「workflowは見える」「ログインもできる」状態でも、Credentialが復号できなければOAuth、APIキー、Webhook、通知は戻っていません。この記事では、どこを見るか、何をバックアップするか、workflow exportと本番復元をどう分けるかを整理します。

    結論: キー、DB、volume、.envを同時に残す

    n8n公式Docsでは、初回起動時に暗号化キーを作り、Credential保存前の暗号化に使うと説明されています。Docker Compose例ではn8n_data:/home/node/.n8nがSQLite DBと暗号化キーの保存場所として示されています。つまり、DBだけ、workflow exportだけ、composeだけでは足りません。

    避けたいこと: Credential復号不能をあとで考える

    復旧時に「Credential could not be decrypted」と出てからキーを探しても、見つからないことがあります。構築時点でN8N_ENCRYPTION_KEYを固定し、復元テストでCredentialのテスト接続まで確認します。

    まず起きている痛み

    Workflowは見える

    JSONやDB上のworkflowが残っていても、Credentialを復号できなければ本番連携は戻りません。

    Credentialが読めない

    OAuth、APIキー、DB接続情報が復号できないと、Webhookや定期実行は見た目より深く止まります。

    キーが見つからない

    N8N_ENCRYPTION_KEYは障害後に探すものではなく、構築時に固定して保管するものです。

    workerだけ失敗する

    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本番URLWEBHOOK_URL、reverse proxy、HTTPS、DNS、production/test URL。n8n内では動いて見えても、外部サービスから本番Webhookへ届かなくなります。
    OAuth redirect URIGoogle、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_fileN8N_ENCRYPTION_KEYを明示しているか。composeは残っていても、読み込んでいる.envが別ファイルだとキーが変わります。本番の.env、権限、保管場所、更新履歴。
    ~/.n8n / /home/node/.n8n初回起動時に作られたキーやSQLite DBが残っている可能性。Docker volume名が変わると、新しい空の/home/node/.n8nを見て初期化に見えます。n8n_data volume、DB、設定ファイル、mount先。
    docker-compose.ymlenvironment、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設定、デプロイテンプレート。
    これから契約する人と、すでにVPSを持っている人を分ける

    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復号、通知まで分けて見る。監視・バックアップ・復旧チェックの記事へ内部リンクで戻す。
    n8nをVPSで動かすなら、戻せる構成まで先に決める

    料金だけでなく、Docker volume、DB、.env、Credential、監視を残しやすい構成にしておくと、更新後の事故で詰まりにくくなります。

    ConoHa VPSを確認する

    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キーの有効性を実行テストで見ます。

    復元で確認する順番

    1固定する

    初回構築時にN8N_ENCRYPTION_KEYを.envや秘密管理に固定します。

    2保管する

    キー、DB、volume、docker-compose.yml、.envを同じ日付で退避します。

    3試す

    別環境でCredential復号とOAuth/APIキーのテスト接続まで確認します。

    4更新する

    Docker更新前に参照volume、DB、env_file、WEBHOOK_URLを記録します。

    5監視する

    /health 200だけで終えず、Webhook実行と通知到達まで見ます。

    確認層見るもの復旧完了と言える状態
    起動docker compose ps、ログ、/healthコンテナが起動し、基本ヘルスチェックが通る。
    DBPostgres/SQLite接続、対象DB、volume参照以前のworkflow、Credential、ユーザーが同じDBから見えている。
    CredentialCredential一覧、OAuth/APIキーのテスト接続暗号化されたCredentialを復号でき、外部APIを呼べる。
    WebhookWEBHOOK_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_KEYDBRedis/queueWEBHOOK_URL
    mainCredential暗号化/復号の基準になる値を固定。本番DBへ接続してworkflowとCredentialを読む。queue modeの接続先とprefixを確認。画面表示やOAuth redirect URIに影響。
    workermainと同じ値を渡す。ここが違うとCredential復号で失敗。mainと同じDBへ接続して実行時のCredentialを読む。Redis接続先が違うとjobを拾えない、または別queueを見る。外部URL生成がlocalhostへ戻らないか確認。
    webhook processorWebhook経由の実行でも同じkeyを使える状態にする。Webhook実行が本番DBのworkflow/Credentialへ触れるか。queueに流す構成ならRedis接続を揃える。production URL、reverse proxy、HTTPSを揃える。

    VPS選定に戻すならここを見る

    n8nの復旧力は、CPUやメモリだけでは決まりません。docker-compose.yml、.env、n8n_data volume、Postgres dump、監視通知を残しやすい運用にできるかを見ます。

    ConoHa VPS

    n8n、Dify、Webhook検証をVPSで始めつつ、DB、volume、.envの保管手順まで作りたい人向けの候補です。

    ConoHa VPSを確認する
    XServer VPS

    compose、volume、DB、監視を自分で設計し、内部リンク先の記事と合わせて運用しやすい候補です。

    XServer VPSを確認する
    さくらのVPS

    長期運用、バックアップ、監視、秘密情報の扱いを自分で確認しながら使いたい人向けの比較候補です。

    さくらの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で確認しています。

    関連する記事

    確認日: 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由来の声は読者ペインの見出し素材として扱っています。

  • n8nをDockerで更新したらデータや認証情報が消える原因と対策

    広告を含みます。料金、仕様、キャンペーンは公式ページで確認してください。

    n8nをDockerで更新・再起動したあとに「データが消えた」「registration pageへ戻った」「Credentialが復号できない」となった時は、記事を読む人が一番焦るところです。

    ただし、最初にやるべきことは「消えた」と決めることではありません。まず、今のコンテナがどのvolume、どのDB、どのN8N_ENCRYPTION_KEYを見ているかを確認します。SNS調査でも、ここがn8n self-hostingの強いペインとして繰り返し出てきました。

    結論: n8nの復元はDB、volume、.env、暗号化キーをセットで見る

    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だけをバックアップ扱いにすること
    n8nをVPSで動かすなら、更新前に戻せる構成まで決める

    料金だけで選ぶより、Docker volume、DB、バックアップ、監視、復元手順を残しやすいVPSを選ぶ方が、あとで効きます。

    ConoHa VPSを確認する

    消えたように見える時にまず見るもの

    n8nのDocker更新で怖いのは、原因がひとつに見えないことです。volumeが違う、DBが違う、暗号化キーが違う、Webhook URLが変わる、どれでも「壊れた」ように見えます。

    見る順番確認ポイントなぜ重要かメモ
    1. 現在のvolumedocker 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と.envdocker-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 volumeSQLite DB、settings、暗号化キーが入る構成が多いvolume名を変えて起動し、空のn8nに見えるvolume名とMountpointを記録し、更新前にsnapshotを取る
    PostgreSQL DBWorkflow、Credential、実行履歴などDBだけ古い、または別DBへ接続しているdump、接続先、ユーザー、DB名をセットで残す
    .envドメイン、timezone、DB接続、暗号化キー、Webhook URLWEBHOOK_URLが変わり、連携先のURLを直す羽目になるパスワードを含むため、公開せず安全な場所へ保管する
    docker-compose.ymlimage、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 modeworkerごとにキーが違うと、実行時にCredentialで詰まります。main、worker、環境変数、secret管理全workerへ同じキーを渡す
    移行/復元DB、volume、暗号化キーがそろって初めてCredential復旧の可能性が高まります。移行元と移行先の.env、DB、volumeキーだけ、DBだけ、workflow exportだけでは不十分

    更新前にやる順番

    1停止する

    更新前にn8nを止め、現在のcompose、.env、volume、DB名を記録します。

    2退避する

    volume snapshot、DB dump、.env、compose、暗号化キーを同じ日付で残します。

    3更新する

    imageだけでなく、volume名、DB接続先、WEBHOOK_URLが変わっていないか見ます。

    4確認する

    ログイン、Workflow、Credentialテスト、Webhook外部到達、Error workflowを確認します。

    5監視する

    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、実行履歴、設定が見える
    CredentialWorkflowが見えても、暗号化キーが違うと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 VPSDocker、Webhook、PostgreSQL、監視まで自分で設計する読者に合わせやすい候補です。
    Linux運用を丁寧に詰めるcompose管理、バックアップ、国内リージョン、運用メモさくらのVPSサーバー運用を自分で管理しながら、復元手順まで整えたい人の比較対象になります。
    ConoHa VPS

    n8n、Dify、AIエージェントなどをVPS上で動かす導線をまとめて考えやすい候補です。

    ConoHa VPSを確認する
    XServer VPS

    VPS、Docker、DB、Webhookを自分で組み合わせ、内部リンク先の記事群とも相性がよい候補です。

    XServer VPSを確認する
    さくらのVPS

    compose、volume、バックアップ、監視を自分で設計したい人向けに比較対象へ入れたい候補です。

    さくらの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の事例で技術的な確認点を補強しています。

    次に読む

    確認日: 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で分類して扱っています。