広告を含みます。公開フォーラムと公式docsを確認し、SNS由来の弱い観測は見出し素材として扱っています。
n8nがVPSで落ちる時は、メモリだけを増やしても解決しないことがあります。Out of Memory、502、SQLite、Dockerログ、実行履歴、DB構成、暗号化キーを分けて確認します。
n8n self-hostは便利ですが、止まった時の復旧も自分の仕事になります。workflowを書き出していても、DB、volume、.env、N8N_ENCRYPTION_KEYが欠けるとCredentialを戻せないことがあります。
小さな検証なら2GBでも始められます。Webhook、PostgreSQL、監視、バックアップまで同居するなら4GB以上を見ます。
n8n公式docsではqueue modeでPostgres 13+が推奨され、SQLiteは推奨されていません。実行が増えるならDB構成も見直します。
更新や復元で最初に見るもの
Docker restartやupdate後に、n8nが初期画面へ戻る、Credentialが使えない、登録画面が出る、という失敗は「アプリは起動しているのにデータが戻っていない」状態です。VPS選定より前に、どこへ何を保存しているかを確認します。
| 症状 | 疑うところ | 確認するもの | 戻す順番 |
|---|---|---|---|
| 初期画面や登録画面へ戻る | volume永続化不足、別volumeで起動、compose変更 | `n8n_data`、`/home/node/.n8n`、DBファイル、composeのvolumes。 | コンテナを止め、正しいvolumeとcomposeに戻してから起動する。 |
| Credentialが復号できない | 暗号化キー喪失、`.env`不一致、別インスタンスのDB | `N8N_ENCRYPTION_KEY`、`~/.n8n`設定、DB、バックアップ時点。 | 暗号化キー、DB、volumeを同じ組み合わせで戻す。 |
| workflowだけ戻ってCredentialが空 | workflow exportだけで安心した | DB、Credential、暗号化キー、外部サービス側の再認証。 | DB/volumeを戻し、必要ならCredentialを再入力する。 |
| Webhook URLが変わる | 復元後のID、公開URL、reverse proxy、WEBHOOK_URL差分 | Webhook ID、外部連携先の送信URL、HTTPS、リバースプロキシ。 | 外部連携先のURLまで含めて動作テストする。 |
症状別チェック
| 症状 | 疑うところ | 確認すること | 次の対処 |
|---|---|---|---|
| Out of Memoryで落ちる | メモリ、並列実行、AIノード、大きいデータ | VPSメモリ、swap、Docker再起動回数、実行中ワークフロー。 | 4GB以上、実行数削減、重い処理の分離。 |
| 502 Bad Gateway | n8nプロセス停止、リバースプロキシ、コンテナ再起動 | Docker logs、proxy logs、ヘルスチェック。 | 監視、再起動設計、メモリ余裕。 |
| Webhook停止に後から気づく | 実行失敗通知なし、外形監視なし、認証や外部サービス仕様変更 | 最後の成功時刻、失敗ログ、HTTP応答、影響を受けた連携先。 | 失敗通知、外形監視、影響範囲メモを分ける。 |
| silent failureが起きる | 例外を握りつぶす分岐、失敗通知なし、リトライキュー滞留 | error workflow、失敗時の分岐、例外キュー、最後に成功した時刻。 | 失敗通知、例外キュー確認、手動再実行の単位を用意する。 |
| workflow依存で止まる | 前段workflowの失敗、外部API変更、エラー処理層不足 | 依存しているworkflow、失敗時の分岐、再実行できる単位。 | error workflow、リトライ、手動復旧手順を用意する。 |
| UIが重い | 実行履歴、DB肥大化、CPU/IO | 実行データ保存、DBサイズ、ディスク残量。 | 履歴削除設定、PostgreSQL、ログ整理。 |
| 更新後に戻せない | バックアップ不足、env管理、DBダンプなし、暗号化キー不一致 | compose、.env、DB、volume、N8N_ENCRYPTION_KEYの保存先。 | 更新前バックアップ、復旧手順、Credential復号テストを作る。 |
止まった原因と気づく仕組みを分ける
Webhookや自動化処理では、原因の修正よりも、止まっていた時間と影響範囲の確認が先に痛みになります。VPSでは実行履歴、失敗通知、外形監視、復旧手順を別々に用意します。
| 見る場所 | 何を見るか | 遅れると困ること | 先に決めること |
|---|---|---|---|
| 実行履歴 | 最後の成功時刻、失敗したワークフロー、エラー本文。 | どこから処理漏れしたかを後追いで探すことになる。 | 保存期間、DB容量、履歴削除設定。 |
| 失敗通知 | 失敗時にメール、Discord、Slackなどへ届くか。 | 通知があっても見ない場所に届き、翌朝まで気づけない。 | 普段見る通知先、テスト送信、代替先。 |
| エラー処理層 | リトライ、error workflow、失敗時の分岐、手動再実行の単位。 | 前段の失敗が後続workflowに広がり、影響範囲が見えにくくなる。 | どこで止めるか、どこまで自動復旧するか。 |
| リトライ/例外キュー | 失敗した実行が溜まっていないか、再試行待ちが詰まっていないか。 | 処理が止まっていないように見えて、裏で未処理だけが増える。 | 再試行回数、破棄条件、手動で戻す順番。 |
| 外形監視 | n8n画面、Webhook URL、API応答、SSL。 | コンテナ内では動いて見えても、外から届かない状態を見逃す。 | 監視間隔、通知条件、VPS外の通知先。 |
| 影響範囲 | 関係するCredential、連携先、処理済みデータ。 | 停止原因より先に、どの業務や投稿が抜けたか確認が必要になる。 | ワークフローごとの責任範囲、復旧チェックリスト。 |
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復号、通知まで分けて見る。 | 監視・バックアップ・復旧チェックの記事へ内部リンクで戻す。 |
原因と対処
ワークフロー数、並列実行、AIノードで負荷が上がります。VPSの余裕を先に見ます。
実行履歴を残し続けるとDBが増えます。公式の実行データ削除設定を確認します。
軽い検証なら楽ですが、広げるならPostgreSQLを検討します。
ログやイメージが増えると容量を圧迫します。定期的に整理します。
落ちたことに気づけないと自動化の意味が薄れます。外形監視、実行失敗通知、通知先を分けます。
DB、volume、暗号化キーがそろわないと、Credentialを戻せないことがあります。
構成の目安
| 使い方 | 目安 | 構成 | 候補 |
|---|---|---|---|
| 検証 | 2GB | n8n単体、少数ワークフロー、外部公開なし。 | ConoHa VPSを確認する |
| 個人の常時処理 | 4GB | n8n、HTTPS、監視、バックアップ。 | XServer VPSを確認する |
| 公開Webhook | 4GB以上 | PostgreSQL、外形監視、ログ整理。 | さくらのVPSを確認する |
| キュー/複数worker | 8GB以上 | PostgreSQL、Redis、worker分離。 | 構成を分けて検討 |
監視とバックアップ
| 項目 | 見る理由 | 対処 |
|---|---|---|
| 外形監視 | n8n画面やWebhookが外から届くか確認する。 | UptimeRobotを確認する |
| 失敗通知 | 実行履歴を見に行く前に、止まったことへ気づく。 | メール、Discord、SlackなどVPS外の通知先をテストする。 |
| 実行履歴 | DB肥大化を防ぐ。 | n8n executions環境変数で保存期間と件数を確認。 |
| DB | ワークフローと認証情報を守る。 | PostgreSQL、DBダンプ、接続情報の保管。 |
| 暗号化キー | Credential復元に関係するため、DBだけ戻しても復旧できないリスクを減らす。 | n8n encryption key docsを確認し、固定値と保管場所を決める。 |
| Docker volume | 公式Compose例では`n8n_data`がSQLite DBと暗号化キーの保存先になる。 | `n8n_data`、DB、`.n8n`、バックアップ先を確認する。 |
| Docker構成 | 更新失敗から戻す。 | n8n Docker Compose docs、volume、.env、起動コマンドを保存。 |
| Error workflow | 失敗した実行を通知し、silent failureを減らす。 | n8n error workflow docsを確認し、通知先と再実行単位を決める。 |
参照した公開情報
| 情報源 | 使った位置づけ |
|---|---|
| n8n Communityの事例 | OOM、502、SQLite、Docker構成のペイン確認。 |
| n8n queue mode docs | queue modeでPostgres 13+推奨、SQLite非推奨の確認。 |
| n8n executions環境変数 | 実行データ削除設定の確認。 |
| n8n encryption key docs | 暗号化キー固定化と復旧時の確認項目。 |
| n8n forum: credentials could not be decrypted | Credential復号不能の失敗例。 |
| n8n forum: Docker update lost data | Docker更新後のデータ喪失ペイン。 |
公式で確認する
DockerやWebアプリもまとめて見る候補。
XServer VPSを確認する
確認日: 2026年6月28日。SNS由来の未検証ペインは本文根拠に直用せず、見出しと再調査項目として扱っています。2026年6月30日のAggressive Wave、反応回収、外部調査で拾ったWebhook停止に気づけない不安、workflow依存、silent failure、例外キュー、リトライ不足、Docker restart/update後の初期化、Credential復号不能、暗号化キー復元不安は、実行履歴・失敗通知・外形監視・エラー処理・復元確認表へ反映しました。仕様はn8n公式docsと公開フォーラムで確認しました。