サーバー選びナビ

タグ: n8n

  • 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がVPSで落ちる原因は？メモリ・DB・Docker構成の見直し方

    広告を含みます。公開フォーラムと公式docsを確認し、SNS由来の弱い観測は見出し素材として扱っています。

    n8nがVPSで落ちる時は、メモリだけを増やしても解決しないことがあります。Out of Memory、502、SQLite、Dockerログ、実行履歴、DB構成、暗号化キーを分けて確認します。

    n8n self-hostは便利ですが、止まった時の復旧も自分の仕事になります。workflowを書き出していても、DB、volume、.env、N8N_ENCRYPTION_KEYが欠けるとCredentialを戻せないことがあります。

    結論: まず2GB、公開運用は4GB以上から見る

    小さな検証なら2GBでも始められます。Webhook、PostgreSQL、監視、バックアップまで同居するなら4GB以上を見ます。

    SQLiteのまま広げすぎない

    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 Gatewayn8nプロセス停止、リバースプロキシ、コンテナ再起動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、連携先、処理済みデータ。停止原因より先に、どの業務や投稿が抜けたか確認が必要になる。ワークフローごとの責任範囲、復旧チェックリスト。
    これから契約する人と、すでに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で本番寄りに動かすなら余裕を持つ

    2GBで試し、公開WebhookやDB同居なら4GB以上も比較します。

    ConoHa VPSを確認する

    原因と対処

    メモリ不足

    ワークフロー数、並列実行、AIノードで負荷が上がります。VPSの余裕を先に見ます。

    DB肥大化

    実行履歴を残し続けるとDBが増えます。公式の実行データ削除設定を確認します。

    SQLite運用

    軽い検証なら楽ですが、広げるならPostgreSQLを検討します。

    Dockerログ

    ログやイメージが増えると容量を圧迫します。定期的に整理します。

    監視不足

    落ちたことに気づけないと自動化の意味が薄れます。外形監視、実行失敗通知、通知先を分けます。

    Credential復元

    DB、volume、暗号化キーがそろわないと、Credentialを戻せないことがあります。

    構成の目安

    使い方目安構成候補
    検証2GBn8n単体、少数ワークフロー、外部公開なし。ConoHa VPSを確認する
    個人の常時処理4GBn8n、HTTPS、監視、バックアップ。XServer VPSを確認する
    公開Webhook4GB以上PostgreSQL、外形監視、ログ整理。さくらのVPSを確認する
    キュー/複数worker8GB以上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 docsqueue modeでPostgres 13+推奨、SQLite非推奨の確認。
    n8n executions環境変数実行データ削除設定の確認。
    n8n encryption key docs暗号化キー固定化と復旧時の確認項目。
    n8n forum: credentials could not be decryptedCredential復号不能の失敗例。
    n8n forum: Docker update lost dataDocker更新後のデータ喪失ペイン。

    公式で確認する

    ConoHa VPS

    小さく始めて、必要なら増やす候補。

    ConoHa VPSを確認する
    XServer VPS

    DockerやWebアプリもまとめて見る候補。

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

    国内VPSで長期運用を比較する候補。

    さくらのVPSを確認する

    次に読む

    確認日: 2026年6月28日。SNS由来の未検証ペインは本文根拠に直用せず、見出しと再調査項目として扱っています。2026年6月30日のAggressive Wave、反応回収、外部調査で拾ったWebhook停止に気づけない不安、workflow依存、silent failure、例外キュー、リトライ不足、Docker restart/update後の初期化、Credential復号不能、暗号化キー復元不安は、実行履歴・失敗通知・外形監視・エラー処理・復元確認表へ反映しました。仕様はn8n公式docsと公開フォーラムで確認しました。

  • n8n CloudとVPS self-hostはどちらを選ぶ？運用負荷で決める

    広告を含みます。n8nをCloudで使うか、VPSで動かすかを比べる記事です。

    n8nは、学習や小さな検証ならVPS self-hostで始めやすいです。業務の中に入り、止まった時の復旧や利用者管理まで見るならn8n Cloudも候補になります。

    安さだけで比べると、あとでバックアップ、更新、Webhook、DB、復旧担当で迷いやすくなります。ここでは「誰が運用するか」から分けます。

    学習や検証はVPS self-hostからでよい

    Dockerで動かせる人、バックアップと更新を自分で持てる人は、VPSで小さく始めやすいです。

    業務で止めにくいならCloudも見る

    失敗したワークフローが売上、顧客対応、社内業務に影響するなら、費用より復旧しやすさを先に見ます。

    用途別の分け方

    使い方候補選ぶ理由契約前に見るところ
    学習、個人検証、小さなWebhookVPS self-host費用を抑えやすく、Docker、DB、ログ、バックアップの仕組みを学べる。2GBで足りるか、永続ボリューム、更新手順、ポート公開。
    業務の通知や定期処理n8n Cloudサーバー管理を減らし、ワークフロー作成と運用に集中しやすい。料金、実行数、利用者、サポート、データ管理。
    Dify、DB、APIも同じ環境で動かすVPSを広めに取るn8nだけでなく、周辺ツールもまとめて置ける。4GB以上、バックアップ、監視、公開範囲。
    まずはCloudとVPSを同じ土俵で比べる

    n8n Cloudは公式料金、VPSはメモリと運用範囲を見ます。自分で戻せるかが分かれ目です。

    n8n Cloudの料金を確認する

    VPSで始める時に決めること

    永続化

    n8nの設定、認証情報、実行履歴を消さないように、volumeやDBの保存先を決めます。

    DB

    小さく始めるならSQLite、長く使うならPostgreSQLも候補になります。

    更新

    Dockerイメージ更新後に戻せるか。壊れた時の戻し方を先に決めます。

    Webhook

    外部サービスから届く入口なので、ドメイン、HTTPS、監視も合わせて見ます。

    バックアップ

    ワークフローだけでなく、認証情報と暗号化キーを失わない設計にします。

    通知

    失敗や停止に気づけないと、業務化した時に痛くなります。

    VPS候補

    小さく始める

    n8n、Webhook、軽いBotから始めるならConoHa VPSも候補。

    ConoHa VPSを確認する
    DifyやDockerも使う

    6GB、12GBまで見ながら広めに取るならXServer VPSも比較。

    XServer VPSを確認する
    自分でLinuxを組む

    手順を自分で持ちたいなら、さくらのVPSも比較対象。

    さくらのVPSを確認する

    n8n Cloudを選ぶ場面

    状況Cloud寄りになる理由まだVPSでよい場面
    止まると顧客対応が遅れる復旧担当やサポートを含めて考える必要がある。自分だけが使う通知や検証。
    利用者が増えるユーザー管理、権限、共有の運用が重くなる。個人運用、1人で触るワークフロー。
    更新やバックアップが負担サーバー管理を減らせる。DockerやDBの運用を自分で管理できる。

    関連する記事

    確認日: 2026年6月25日。参照: n8n公式アフィリエイト、n8n公式Docker docs、n8n公式料金ページ。n8n Cloudのアフィリエイトリンクは未設定のため、公開時点では通常の公式リンクです。

  • ConoHa VPSの評判は？AI・自動化用途で向く人と注意点

    広告を含みます。AI自動化、Webhook、小さなアプリ用にConoHa VPSを検討する人向けです。

    ConoHa VPSは、n8n、Dify、Bot、API、検証環境を小さく常時稼働させたい人に向きます。管理画面、テンプレート、API、オブジェクトストレージ、自動バックアップなどをまとめて見られる点が使う理由になります。

    一方で、VPSなのでOS更新、SSH、公開ポート、バックアップ、復旧手順は自分で見ます。WordPressだけを置きたい人や、WindowsでMT4/MT5を動かしたい人は別候補も確認します。

    結論: 自動化やAIツールを動かすなら候補に入る

    公式ではAIエージェント実行環境として、Difyやn8nなどをConoHa VPS上でセルフホストする構成を案内しています。PCのスリープから切り離したい人に合います。

    注意: サーバー管理を任せたい人向けではない

    VPSは自由な分、管理する範囲が広いです。バックアップを取るだけでなく、戻す手順まで決めてから使います。

    用途別の選び方

    やりたいこと候補選ぶ理由注意点
    n8n、Dify、Botを常時動かすConoHa VPSAIエージェント環境、スタートアップスクリプト、API、オブジェクトストレージを確認できる。2GBで足りるか、DBやログ保存をどうするか先に決める。
    WebアプリやAPIを小さく公開するConoHa VPSVPS、DBサーバー、ロードバランサー、プライベートネットワークを含む構成を検討しやすい。公開範囲、セキュリティグループ、バックアップを自分で設計する。
    Difyや複数コンテナで余裕を取りたいXServer VPSDocker、Dify、WordPressなど目的別導線があり、メモリ帯を比較しやすい。ConoHaだけで決めず、4GB以上や長期料金も比べる。
    Linux運用を自分で組みたいさくらのVPS手順を自分で持ちたい人、長期運用や国内リージョンを重視する人の比較候補。用意済みアプリより、自分で構成する前提で比べる。
    n8nやDifyを小さく動かすならConoHa VPS

    AIエージェント環境、API、バックアップ、オブジェクトストレージを公式ページで確認してからプランを選びます。

    評判を見るときの判断軸

    小さく始めやすいか

    AIエージェント構成例ではVPS 2GBの入口が示されています。n8nや軽いBotから始める人は見やすいです。

    保存先を分けられるか

    オブジェクトストレージはS3互換APIに対応。ログや成果物、バックアップの逃がし先として検討できます。

    復旧まで考えられるか

    自動バックアップやイメージ保存を使う場合も、復元手順を決めておく必要があります。

    向いている人と注意点

    サービス向いている人判断材料契約前に見るところ
    ConoHa VPSn8n、Dify、Bot、APIを小さく常時稼働させたい人2GB/4GB、バックアップ、API、オブジェクトストレージ、セキュリティグループ。まず用途と必要メモリを決めて公式で確認する。
    XServer VPSDockerやDifyをメモリ多めで比較したい人2GB、6GB、12GB、Docker/Dify導線、バックアップやSLAの有無。重めの構成ならConoHaと並べて比較する。
    さくらのVPSLinux運用を自分で組みたい人リージョン、プラン、スケールアップ、パケットフィルター、スタートアップスクリプト。手順を自分で持てるか確認する。

    ConoHa VPSを選ぶ前に見ること

    • n8nやDifyを動かすなら、DB、Redis、ログ保存、バックアップ先まで決める。
    • 公開するサービスなら、セキュリティグループで必要な通信だけ開ける。
    • 自動バックアップやイメージ保存を使う場合、復元手順を一度試す。
    • 小さく始めるなら2GB、Difyや複数コンテナなら4GB以上も比較する。
    DifyやDockerで余裕を取りたいならXServer VPSも比較

    メモリ帯に余裕を取りたい場合は、ConoHa VPSとXServer VPSを並べて比べます。

    避けたほうがいいケース

    WordPressだけ、Windows取引ツールだけなら別候補を先に見る

    WordPressだけならレンタルサーバーやWordPress専用サービスの方が運用しやすいことがあります。MT4/MT5をWindowsで動かすなら、Windows VPSやFX専用VPSを見た方が判断しやすいです。

    Linuxを自分で組みたいならさくらのVPSも候補

    手順を自分で持つ前提なら、国内リージョンや長期運用の比較候補として確認します。

    この記事のまとめ

    ConoHa VPSは、自動化と小さなクラウド運用の入口として見やすい

    n8n、Dify、Bot、APIを自宅PCから切り離して動かしたい人には合います。判断するときは、料金だけでなく、メモリ、バックアップ、公開範囲、ログ保存、復旧手順まで見ます。

    あわせて読む

    確認日: 2026年6月25日。公式情報: ConoHa VPS、XServer VPS、さくらのVPS。料金、キャンペーン、仕様、提供機能は変更されることがあります。

  • Docker VPSのメモリは何GB？n8n・Dify・DBで選ぶ

    広告を含みます。DockerをVPSで動かす時のメモリ目安を整理します。

    Docker用VPSのメモリは、コンテナ数ではなく「何を常時動かすか」で決めます。n8nなら2GBから、DB込みの公開運用なら4GBから、Difyや複数サービスなら8GB以上を見ます。

    Docker公式docsでは、コンテナにメモリ制限を設定できることが示されています。VPS全体の余裕と、各コンテナの上限を分けて考えると失敗しにくいです。

    結論: n8nは2GB、DB込みは4GB、Difyは8GB以上から

    1GBは検証用。Docker Composeでn8n、PostgreSQL、nginxを置くなら4GBを見ます。Dify、Redis、PostgreSQL、複数workerまで含めるなら8GB以上を基準にします。

    注意: 余ったメモリは無駄ではない

    メモリが足りないと、スワップ、DB遅延、コンテナ再起動が起きます。月額を少し下げるより、障害調査の時間を減らすほうが得な場面があります。

    メモリ目安

    構成目安向いている用途候補
    単体コンテナの検証1GB小さなWeb、CLI、短時間の動作確認。止まっても困らない検証。XServer VPSを確認する
    n8n、軽いAPI、Webhook2GB個人用の自動化、少数ワークフロー、外部Webhookの小規模受信。ConoHa VPSを確認する
    n8n + PostgreSQL + nginx4GB公開運用、実行履歴保存、DBバックアップ、監視まで入れる構成。ConoHa VPSを確認する
    Dify、Redis、PostgreSQL、複数サービス8GB以上AIアプリ、複数コンテナ、DBとworkerを同時に動かす構成。さくらのVPSを確認する
    Dockerを本番寄りに使うなら4GBを基準に見る

    n8n、Webhook、DB、監視をまとめて置くなら、1GBや2GBだけで詰めないほうが安全です。

    ConoHa VPSを確認する

    メモリを食うもの

    DB

    PostgreSQLやMySQLは、アプリ本体よりも長くメモリとディスクを使います。

    Redis

    キューやキャッシュを使う構成では、Redis分の余裕も必要です。

    ログ

    Dockerログを放置するとディスクを圧迫し、結果的にDBやアプリが止まります。

    同時実行

    WebhookやAI処理が重なると、単体テストでは足りていたメモリを超えます。

    コンテナ制限も決める

    項目なぜ必要か判断
    memory limit1つのコンテナがVPS全体のメモリを使い切るのを防ぐ。重い処理をするコンテナほど上限を決める。
    swap一時的な不足を吸収できるが、遅くなりやすい。頼りすぎない。メモリ不足の警告として見る。
    restart policy落ちたコンテナを自動で戻す。戻るだけでなく、落ちた通知も入れる。
    log rotationログ肥大化でディスク満杯になるのを防ぐ。最初から上限を決める。

    VPS候補

    候補向いている人選ぶ理由注意点
    ConoHa VPSn8n、Webhook、DB込みで始めたい人時間課金、SLA、自動バックアップ、有料オプションを見ながら始めやすい。メモリだけでなくディスク、バックアップ、監視も設定する。
    XServer VPSDocker Composeを自分で組める人イメージ保存、接続制限、SSH Keyなど、構築後に固める機能を確認しやすい。アプリ監視、ログ、復旧手順は自分で組む。
    さくらのVPS国内運用や長期運用を重視する人国内データセンター、24時間365日のサーバー状況監視、スケールアップが判断材料になる。コンテナ単位の監視は別途組む。

    用途で選ぶ

    n8nやWebhook

    2GBから始め、公開運用なら4GBへ。バックアップと監視も一緒に見る。

    ConoHa VPSを確認する
    自分でCompose管理

    Docker、nginx、DB、ログを自分で扱うなら構築しやすさを見る。

    XServer VPSを確認する
    Difyや複数サービス

    8GB以上を見ながら、長期運用とスケールアップを重視する。

    さくらのVPSを確認する

    次に読む

    確認日: 2026年6月24日。参照: Docker公式docs、XServer VPS機能一覧、ConoHa VPS公式、さくらのVPS特長。必要メモリはコンテナ数、DB、ログ、同時実行で変わります。

  • n8n用VPSのスペックは？1GB・2GB・4GBの選び方

    広告を含みます。n8nをVPSで動かす時のメモリ、DB、バックアップを整理します。

    n8nは小さく試すだけなら軽く始められます。ただし、Webhookを公開し、複数ワークフローを常時動かし、実行履歴を残すなら、1GBではなく2GB以上を基準に見たほうが安定します。

    ここでは「試す」「個人で使う」「公開Webhookを受ける」「AI連携やキューを使う」に分けて、VPSのスペックを選びます。

    結論: 迷うなら2GB、公開運用なら4GBから見る

    1GBは検証向けです。Docker Composeでn8nを置き、Webhookを受け、DBやログも見るなら2GB以上。AI連携、並列実行、PostgreSQL、Redisを含めるなら4GB以上を見ます。

    注意: メモリだけで決めない

    n8nは実行履歴が増えるとDBも膨らみます。実行データの削除設定、バックアップ、監視を入れないと、VPSのスペックより先にディスクやDBで詰まります。

    スペック目安

    使い方目安向いている構成候補
    触って試す1GBDocker単体、少数ワークフロー、外部公開なし。止まっても困らない検証。ConoHa VPSを確認する
    個人用の定期処理2GBn8n + リバースプロキシ。実行履歴を整理しながら使う。XServer VPSを確認する
    Webhookを公開して常時受ける4GBn8n + PostgreSQL + 監視 + バックアップ。停止したくない用途。ConoHa VPSを確認する
    AI連携、並列実行、チーム利用8GB以上PostgreSQL、Redis、worker分離を検討。DBと実行数を分けて見る。さくらのVPSを確認する
    WebhookやAPI連携を止めたくないなら2GB以上から

    まず小さく始め、必要に応じて4GBへ上げる前提で選ぶと失敗しにくいです。

    ConoHa VPSを確認する

    重くなる原因

    実行履歴

    成功・失敗の履歴を残し続けるとDBが増えます。保存期間と件数を決めます。

    Webhook

    外部から同時に呼ばれると、処理待ちが増えます。公開するなら監視も必要です。

    AIノード

    API待ちやデータ整形で処理時間が伸びます。大きなデータを扱うほど余裕が必要です。

    DBとログ

    PostgreSQL、Dockerログ、添付ファイルが増えます。メモリだけでなくディスクも見ます。

    DBと実行履歴の見方

    項目見る理由判断
    SQLite小さく試すには楽ですが、公開運用やキュー運用には向きません。検証まで。長く使うならPostgreSQLへ。
    PostgreSQLn8n公式docsでもqueue modeではPostgres 13+が推奨されています。公開Webhookや複数ワークフローでは早めに使う。
    実行データ削除`EXECUTIONS_DATA_PRUNE`、最大保存時間、最大件数でDB肥大化を抑えます。最初から設定しておく。
    バックアップVPSイメージだけでなく、DBダンプと設定ファイルを戻せるかが重要です。更新前に戻せる形を作る。

    VPS候補

    候補向いている人選ぶ理由注意点
    ConoHa VPSn8nを小さく始め、必要なら上げたい人時間課金、SLA、自動バックアップ、有料オプションを見ながら始めやすい。運用管理は自分で行う。自動バックアップの条件は契約前に確認する。
    XServer VPSDocker Composeで自分で組める人イメージ保存、接続制限、SSH Keyなど、構築後に固める機能を確認しやすい。監視、DBバックアップ、更新手順は自分で設計する。
    さくらのVPS国内運用や長期運用を重視する人国内データセンター、24時間365日のサーバー状況監視、スケールアップが判断材料になる。アプリ単位の監視と復旧は自分の運用として組む。

    最初に決めること

    決めること目安理由
    公開するか外部Webhookを受けるなら2GB以上外からの呼び出し、SSL、リバースプロキシ、監視が必要になる。
    DBを分けるか長く使うならPostgreSQL実行履歴とワークフローを守りやすい。
    並列実行するか増えるなら4GB以上同時処理が増えるとメモリとDBの余裕が必要になる。
    戻し方VPSイメージ + DBバックアップ設定ミスや更新失敗から戻せる。

    用途で選ぶ

    小さく始める

    検証から公開運用へ広げたいなら、時間課金やバックアップを見て始める。

    ConoHa VPSを確認する
    Dockerで自分で組む

    Compose、リバースプロキシ、監視を自分で組むなら構築しやすさを見る。

    XServer VPSを確認する
    長期運用で見る

    国内運用やスケールアップを重視するなら比較対象に入れる。

    さくらのVPSを確認する

    次に読む

    確認日: 2026年6月24日。参照: n8n公式docs、XServer VPS機能一覧、ConoHa VPS公式、さくらのVPS特長。n8nの必要スペックはワークフロー数、データ量、実行頻度で変わります。

  • 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で分類して扱っています。

  • Webhookを受けるVPSのおすすめは？n8n・Bot・APIで選ぶ

    広告を含みます。Webhookを受けるサーバー選びとして整理しています。

    Webhook用VPSは、外部サービスから呼ばれる入口を24時間置くための場所です。料金より先に「公開URL」「ログ」「認証」「止まった時の復旧」を見ます。

    n8n、Discord Bot、LINE Bot、GitHub連携、決済通知、フォーム通知などは、外からHTTPで呼ばれます。自宅PCでも試せますが、スリープや回線変更で止まる運用には向きません。

    n8nや小さなBotならConoHa VPSから見る

    ConoHa VPSはAIエージェント実行環境、n8n、Dify、オブジェクトストレージ、セキュリティグループなどの導線があります。個人の自動化から始めやすい候補です。

    Webhookは入口を雑に公開しない

    URLを知っている人が叩ける状態にすると危険です。Basic認証、ヘッダー認証、IP制限、ログ確認を先に決めます。

    結論

    やりたいこと候補選ぶ理由注意点
    n8n、通知Bot、小さな自動化ConoHa VPS2GB構成から始めやすく、n8nやAIエージェント系の常時稼働に広げやすいです。Webhook URL、管理画面、SSHを同じ感覚で外に出さない。
    Docker、Node.js、FastAPIも同居XServer VPS2GBでvCPU 3コア、NVMe SSD 50GB。Docker目的の入口もあります。DBやworkerを同居するなら4GB以上も比較する。
    長く地味に運用したいさくらのVPS国内VPSとして標準的に使いやすく、用途を広げやすい候補です。初期設定、バックアップ、監視は自分で整える。
    まず動作確認だけローカルPCテストだけなら無料で始められます。外部サービスから安定して呼ばせる本番運用には不向きです。
    n8nやBotの入口を置くならConoHa VPSを先に確認

    小さなWebhook、通知Bot、自動化ワークフローを常時動かしたい人向けです。

    ConoHa VPSを確認する

    WebhookでVPSが必要になる理由

    公開URLが必要

    GitHub、Stripe、LINEなどが、あなたのURLへHTTPリクエストを送ります。

    24時間受ける

    PCがスリープしたり回線が変わったりすると、通知を受けられません。

    ログを見る

    届いたか、失敗したか、どのサービスから来たかを追える場所が必要です。

    入口を守る

    認証、IP制限、秘密URL、レート制限を用途ごとに分けます。

    構成の目安

    用途最初の目安増やすタイミング見ておくこと
    n8nのWebhook2GB前後から検証実行履歴、DB、同時実行、ファイル処理が増えた時。Production URL、認証、実行ログ、バックアップ。
    Discord Bot、LINE Bot軽いBotなら2GB前後常駐処理、画像処理、外部API待ちが増えた時。再起動後の自動復旧、ログ、APIキー管理。
    FastAPI、Node.jsのWebhook受信2GBから4GBDB、キュー、worker、管理画面を同居する時。HTTPS、リバースプロキシ、環境変数、監視。
    決済通知、予約通知、本番連携4GB以上も比較止まると売上や業務に影響する時。バックアップ、冗長化、障害時の手順。

    買う前に決めること

    1何を受けるか

    n8n、Bot、GitHub、決済、フォーム通知。入口ごとにURLを分けます。

    2どう守るか

    Basic認証、ヘッダー認証、JWT、IP制限のどれを使うか決めます。

    3止まったら戻す

    再起動、自動起動、ログ保存、バックアップ先を先に決めます。

    サービス比較

    サービス向いているWebhook選ぶ理由注意点
    ConoHa VPSn8n、通知Bot、AI API連携2GB構成のAIエージェント実行環境例があり、オブジェクトストレージや自動バックアップにも広げやすいです。公開範囲とセキュリティグループを最初に整理する。
    XServer VPSDocker、Node.js、FastAPI2GBでvCPU 3コア、NVMe SSD 50GB。Docker目的の導線があり、APIサーバーへ広げやすいです。本番DBやworkerも同居するなら上位プランを比較する。
    さくらのVPS長期運用、小規模API、検証環境国内VPSとして地味に使いやすく、構成を自分で作りたい人に向きます。監視、バックアップ、SSL更新を自分で整える。
    DockerやAPIサーバーも一緒に置くならXServer VPSも比較

    Webhook受信だけでなく、Node.js、FastAPI、Docker Composeへ広げたい人向けです。

    XServer VPSを確認する

    避けたい設定

    避けたいこと理由代わりにやること
    Webhookを1本にまとめるどのサービスの失敗か追いにくくなります。用途ごとにURL、認証、ログを分ける。
    認証なしで公開するURLが漏れると誰でも呼べる入口になります。ヘッダー認証、Basic認証、IP制限を使う。
    ログを残さない失敗時に原因を追えません。アプリログ、Webサーバーログ、n8n実行履歴を見る。
    バックアップを後回しworkflow、DB、環境変数を戻せなくなります。契約直後に復元手順まで試す。

    公式情報を確認する

    ConoHa VPS

    n8n、Bot、小さな自動化の入口を作りたい人向け。

    ConoHa VPSを確認する
    XServer VPS

    Docker、Node.js、FastAPIへ広げたい人向け。

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

    標準的な国内VPSで長く運用したい人向け。

    さくらのVPSを確認する

    次に読む

    確認日: 2026年6月23日。料金、キャンペーン、仕様は変わることがあります。申し込み前に各公式ページで最新条件を確認してください。

  • Docker VPSのおすすめは？Dify・n8n・Webアプリで選ぶ

    広告を含むページです。料金、キャンペーン、対応機能は公式ページで確認してから申し込んでください。

    Docker用のVPSは、Dockerそのものではなく「何をコンテナで動かすか」から選びます。n8nや軽いBotなら小さく始めやすく、Difyや複数サービス構成なら4GB以上を見た方が失敗しにくいです。

    Docker公式はUbuntu向けDocker Engineで64bit版のUbuntu 26.04、25.10、24.04 LTS、22.04 LTSなどを案内しています。VPS側ではOS、メモリ、ディスク、バックアップ、公開ポートをまとめて確認します。

    軽い自動化ならConoHa VPS、重めならXServer VPSも見る

    ConoHa VPSはAIエージェント環境としてDifyやn8nを案内。XServer VPSは目的別申込にDifyとDockerの導線があり、2GB、6GB、12GBの入口が分かりやすいです。

    Docker Composeを使うなら、メモリと保存先を先に見る

    Dockerはアプリをまとめやすい反面、DB、Redis、ログ、アップロード、環境変数が散らばりやすくなります。料金より先に、データをどこに置くかを決めます。

    2GBで始める用途n8n、軽いBot、検証用API、個人の小さなWebアプリ。
    4GB以上を見る用途Dify、DBつきアプリ、複数コンテナ、継続運用。
    保存先volume、DB、ログ、アップロード、バックアップを分けます。
    公開範囲80/443、SSH、管理画面、Webhookを必要な分だけ開けます。

    まず結論

    Dockerで動かしたいもの候補選ぶ理由注意点
    n8n、通知Bot、軽いAPIConoHa VPSAIエージェント環境としてn8nやDifyの導線があり、小さな常時稼働用途から見やすい候補です。Docker、OS更新、SSH鍵、バックアップは自分で管理します。
    Dify、DBつきWebアプリ、複数コンテナXServer VPSDify、Dockerの目的別導線があり、6GB、12GBなどのメモリ帯も見やすいです。通常プランは自動バックアップやSLAの有無をプランごとに確認します。
    Linuxを自分で触って学ぶ、構成を自由に組むさくらのVPSDocker構築環境の申込導線があり、1G、2G、4Gなどの段階で選べます。用意済みアプリより、自分で作る人向けです。
    仕事用、本番用、止めにくい仕組みバックアップ/SLAつきプランDockerは動かすより、更新失敗やデータ破損から戻せることが大事です。バックアップなしでDBつきアプリを公開しない方が安全です。
    n8nや軽いBotをDockerで動かすなら、まずConoHa VPS

    小さく始める用途なら、2GB前後から試し、DifyやDBつきアプリに広げる段階で4GB以上を見ます。最初から公開ポートとバックアップを決めておくと、後で崩れにくいです。

    ConoHa VPSを確認する

    用途別のメモリ目安

    用途見たいメモリ理由
    n8n、軽いWebhook、通知Bot2GB前後から検証小さな自動化なら始めやすいです。実行履歴やDBが増えたら上位プランを見ます。
    Dify4GB以上Dify公式のDocker Compose構成はCPU 2 Core以上、RAM 4 GiB以上が最低要件です。
    Webアプリ + DB + Redis4GBから6GB以上アプリ本体だけでなく、DB、Redis、ログ、バックアップまで含めて見る必要があります。
    高負荷アプリ、複数サービス、本番運用6GBから12GB以上同時アクセス、ビルド、バッチ処理、監視、復旧を考えると余裕が必要です。

    Docker VPSで先に決めること

    Composeを使うか

    Dify、n8n、DBつきアプリはDocker Composeで考えると整理しやすいです。単体コンテナより保存先と起動順を意識します。

    どこを永続化するか

    DB、volume、アップロード、`.env`、ログ。消えると困るものを、コンテナの中だけに置かないようにします。

    どう戻すか

    更新前のスナップショット、DBバックアップ、設定ファイルの控えを用意します。公開後は「戻せること」が価値になります。

    公開前チェック

    • SSHをパスワードだけで開けっぱなしにしない。鍵認証、ポート、接続元を確認します。
    • 管理画面をそのまま外に出さない。HTTPS、認証、IP制限をセットで見ます。
    • `.env` やAPIキーを雑に置かない。不要なキーは無効化し、権限を絞ります。
    • DBをコンテナごと消える場所に置かない。volumeとバックアップを確認します。
    • ログを放置しない。ディスクを圧迫する前にローテーションや保存期間を決めます。
    • Dockerの更新手順を決める。更新前に戻せる状態を作ってから進めます。

    候補サービスの分け方

    サービス合う人確認すること申し込み前に見るところ
    ConoHa VPSn8n、Dify、BotなどをDockerで小さく常時稼働させたい人2GBで足りるか、Difyなら4GB以上か、バックアップ、セキュリティグループ、オブジェクトストレージ。公式のAIエージェント環境と料金を確認する。
    XServer VPSDify、Docker、Webアプリを性能と価格で比較したい人2GB、6GB、12GBの差、キャンペーン期限、通常価格、自動バックアップ/SLAの有無。Docker目的別導線と必要メモリを確認する。
    さくらのVPSLinuxとDockerを自分で組みたい人Docker構築環境、1G/2G/4G、リージョン、ディスク、スケールアップ。自分で構成を持てるか確認する。

    公式ページで確認する

    ConoHa VPS

    n8n、軽いBot、AIエージェント環境を小さく始めたい人向け。

    ConoHa VPSを確認する
    XServer VPS

    Dify、Docker、Webアプリを含めて、メモリと性能を見たい人向け。

    XServer VPSを確認する

    次に読む

    確認日: 2026年6月22日。公式情報: Docker Docs、Dify Docs、ConoHa VPS、XServer VPS、さくらのVPS。料金、キャンペーン、仕様は変更されることがあります。

  • n8n用VPSのおすすめは？自動化を止めずに動かす選び方

    広告を含むページです。料金、キャンペーン、対応機能は公式ページで確認してから申し込んでください。

    n8nを自宅PCで動かすと、PCを閉じた時点で自動化も止まります。予約投稿、Webhook、通知、データ整理を止めずに動かしたいなら、n8nを置く小さなVPSを用意するのが分かりやすいです。

    ただし、n8nは「入れれば終わり」ではありません。Docker、データ保存、バックアップ、公開範囲、停止時の復旧まで見て選ばないと、便利な自動化ほど後で困ります。

    まず検討しやすいのはConoHa VPS

    ConoHa VPSは公式ページでAIエージェント実行環境としてn8n、Dify、OpenClaw、Hermes Agentを案内しています。PCから切り離して常時動かす用途を最初から想定しやすいのが強みです。

    本番運用なら、安さより復旧しやすさ

    n8nには認証情報、実行履歴、ワークフローが残ります。料金だけで選ぶより、データをどこに置くか、止まった時に戻せるか、管理画面を外に出しすぎないかを先に見ます。

    Dockern8n公式はセルフホストでDocker利用を案内しています。
    保存先SQLiteかPostgreSQLか、永続ボリュームをどう持つかを確認します。
    復旧バックアップ、更新手順、再起動後の確認まで決めます。
    公開範囲管理画面、Webhook、SSH、APIキーを雑に外へ出さないようにします。

    まず結論

    やりたいこと候補選ぶ理由注意点
    n8nを小さく常時稼働させるConoHa VPS公式でn8nを含むAIエージェント実行環境を案内。2GB構成例も確認でき、個人の検証から始めやすい候補です。OS更新、Docker、鍵、バックアップ、公開範囲は自分で管理します。
    n8nとWebアプリ、APIも一緒に動かすXServer VPSDify、Docker、WordPressなど目的別の申込導線があり、2GB、6GB、12GBの入口が分かりやすいです。通常VPSは自動バックアップやSLAの有無をプランごとに確認します。
    Linuxを自分で組みたいさくらのVPSDocker構築環境の導線があり、1G、2G、4Gなどの段階で選べます。手順を自分で持てる人向けです。n8n向けに用意済みというより、自分で構成する前提で見ます。
    Windowsアプリを画面で動かすABLENET VPSWindows Server環境やMT4/MT5向けの比較候補。n8n目的なら基本はLinux、画面アプリが必要ならWindows系を見ます。n8n用の第一候補ではありません。RDS/SALなどの費用も確認します。
    n8nをPCから切り離して動かすなら、まずConoHa VPS

    小さく始めるなら、n8nを置く場所、保存先、バックアップ、公開範囲を同時に確認します。先にここを決めると、後から作り直す手間が減ります。

    ConoHa VPSを確認する

    n8n用VPSで先に決めること

    1何を動かすか

    予約投稿、通知、Webhook、データ整理、AI API連携。実行頻度をざっくり決めます。

    2どこに保存するか

    ワークフロー、認証情報、実行履歴、添付ファイルの保存先を決めます。

    3どう守るか

    管理画面、SSH、Webhook、APIキーの公開範囲を絞ります。

    4どう戻すか

    更新失敗、停止、データ破損に備えてバックアップと復旧手順を残します。

    Webhook停止に気づく仕組みを先に作る

    n8nやMakeのWebhookは、止まった原因よりも「止まったことにいつ気づけるか」が運用上の痛みになります。実行履歴を見るだけでなく、失敗時の通知先と影響範囲の確認順を決めます。

    見るもの確認すること止まった時の痛みVPS側で準備すること
    Webhook URL外部から届くか、HTTPエラーや認証切れが出ていないか。フォーム、通知、連携処理が止まり、翌朝まで気づけない。外形監視、HTTPS、WEBHOOK_URL、リバースプロキシログ。
    公開口と認証Webhookが認証なしで外に出ていないか、用途ごとにURLを分けているか。誰でも叩ける入口になり、問題が起きた時に影響範囲を切り分けにくい。HTTPS、Basic認証やトークン、IP制限、用途別Webhook。
    実行履歴最後に成功した時刻、失敗したワークフロー、エラー本文。原因調査より先に、どこまで処理漏れしたか確認が必要になる。実行データの保存期間、DB容量、ログの残し方。
    通知先メールだけでなく、普段見るチャットやスマホ通知に届くか。通知は出ていても見ていない場所に届き、復旧が遅れる。Discord、Slack、メールなどVPS外の通知先とテスト送信。
    リトライと失敗分岐一時的なAPI失敗を再試行するか、失敗時に別ルートへ流すか。1回の失敗で処理が抜け、後から手作業で追うことになる。失敗通知、再実行手順、重要ワークフローのエラー処理。
    影響範囲どの連携先、どのCredential、どのデータが関係するか。広いCredentialだと、失敗時に確認する範囲が大きくなる。用途別Credential、対象フォルダ限定、処理単位のメモ。

    後から足すほどつらい項目

    Webhookは最初に動くと安心しがちですが、認証、通知、リトライを後付けにすると、URL変更や再テストの手戻りが大きくなります。公開前に最低限の運用項目を先に決めます。

    項目後から足す時の痛み先に決めること
    認証共有済みWebhook URLを変える、連携先の設定を戻す、動作確認をやり直すことになる。Basic認証、トークン、IP制限、用途別URL。
    失敗通知止まった後に通知を作っても、過去の失敗時刻や影響範囲を追いづらい。メール、Discord、Slackなど普段見る通知先とテスト送信。
    リトライ1回のAPI失敗で処理が抜け、どこから再実行するかを手作業で探す。再試行回数、失敗時の分岐、手動再実行の単位。
    実行履歴残しすぎるとDBが重く、少なすぎると障害時に追えない。保存期間、削除設定、ログを見る人。
    影響範囲どのCredentialや連携先が関係するか分からず、復旧確認が広がる。用途別Credential、処理単位、失敗時に見る順番。

    バックアップからCredentialが戻せるかを見る

    n8nのバックアップは、workflowを書き出せば終わりではありません。Docker restartやupdate後に初期画面へ戻る、Credentialが復号できない、登録画面に戻る、という失敗を避けるには、保存先と暗号化キーをセットで見ます。

    見るもの欠けると起きることVPS選定時に確認すること
    DB / volumeworkflowやCredential、実行履歴が戻らず、n8nが初期状態に見える。バックアップ対象、スナップショット、DBダンプ、Docker volumeの場所。
    `.env` / N8N_ENCRYPTION_KEYDBがあってもCredentialを復号できず、外部連携を再設定することになる。環境変数の保管先、暗号化キーの別保管、権限管理。
    docker-compose.yml更新後に別volumeで起動し、データが消えたように見える。compose、volume名、起動コマンド、更新前の退避。
    workflow export処理の形だけ戻り、CredentialやWebhook URLの再設定が残る。export/import手順、Credentialの扱い、外部連携先の再接続。
    復元テストバックアップはあるのに、本番障害時に戻せるか分からない。小さな検証環境、復旧手順メモ、テスト送信。

    Credential権限で先に分けること

    n8nのCredentialは便利ですが、Google Drive、Sheets、メール、Slack、DBなどに広い権限を渡すほど、事故時の影響も広がります。VPSでself-hostするなら、スペックだけでなく、Credentialをどこまで許すかを先に決めます。

    不安先にやること理由VPS側で見ること
    OAuthでどの権限を許せばよいか分からない個人の本アカウントをそのまま使わず、用途別の専用アカウントや連携先を用意する。n8nが便利になるほど、Credentialが触れる範囲も広がりやすいからです。n8n管理画面、Credential保存先、バックアップ、アクセス元制限。
    Google DriveやSheetsを触らせすぎたくない対象フォルダや対象ファイルだけを共有し、読み取り専用で足りる処理は書き込み権限を渡さない。ワークフローのミスや誤実行が起きても、触れる範囲を小さくできます。ワークフローごとのCredential分離、実行履歴、ログの残し方。
    Community Editionで権限を細かく分けにくいOwner/Admin/Memberの役割、共有Credential、編集できる人を運用ルールとして分ける。細かい権限分離に頼れない場面では、人とワークフロー単位で触れる範囲を狭くする必要があります。管理者アカウント、ユーザー追加、Credential共有、監査できるメモ。
    OAuthリダイレクトURIで詰まるIP直打ちで進めず、ドメイン、HTTPS、n8nの公開URL、Webhook URLを先に決める。GmailなどのOAuth連携は、後からURLを変えると設定をやり直すことがあります。ドメイン、SSL、N8N_HOST、WEBHOOK_URL、リバースプロキシ。
    APIキーやトークンをどこに置くか迷う個人キーの使い回しを避け、用途別キー、失効手順、ローテーション日を決める。漏れた時に止める単位を小さくし、どのワークフローが使っているか追いやすくするためです。環境変数、`.n8n` ディレクトリ、DB、バックアップファイルの保護。
    self-hostしたn8n本体を復元できるか暗号化キー、DB、ワークフロー、Credential、Docker Composeを一緒に管理する。暗号化キーやDBが欠けると、バックアップがあってもCredentialを復元できない可能性があります。VPSイメージ、DBダンプ、設定ファイル、別保管の復旧手順。

    必要なスペックの考え方

    使い方最初の見方増やすタイミング
    個人の予約投稿、通知、軽いWebhook2GB前後から検証しやすいです。まずはワークフロー数と実行頻度を絞ります。実行履歴が増える、同時実行が増える、ブラウザ操作系の処理が重い時。
    仕事用の定期処理、API連携、フォーム処理メモリだけでなく、バックアップとDBの扱いを重視します。PostgreSQL、Redis、キュー処理が必要になった時。
    AI APIを呼ぶ自動化AIの計算は外部API側なので、VPSはn8n、DB、ログ、Webhookを動かす場所として見ます。大量実行、添付ファイル処理、複数人利用が増えた時。
    ローカルLLMや画像生成を回す通常VPSではなくGPUサーバーを別枠で見ます。モデル本体を動かすならCPU/RAMよりGPU要件を確認します。

    SQLite、PostgreSQL、Redisの違い

    構成向いている使い方注意点
    SQLite個人の検証、小さなワークフロー、まず触ってみる段階。データの場所とバックアップを忘れると、移行や復旧で困ります。
    PostgreSQL仕事用、継続運用、実行履歴や認証情報をきちんと管理したい時。DBのバックアップ、接続情報、復旧手順まで含めて設計します。
    Redis + queue mode処理を並列化したい、ワーカーを分けたい、実行数が増えてきた時。n8n公式はキューモードでSQLite利用を推奨していません。PostgreSQLとセットで考えます。

    失敗しやすい点

    • 管理画面をそのまま公開する。強いパスワード、認証、IP制限、HTTPSを前提にします。
    • Credentialを広い権限のまま使う。読み取り専用、対象フォルダ限定、用途別アカウントで影響範囲を小さくします。
    • OAuthの同意画面を流れで進める。どのサービスへ、どの権限を渡しているかをワークフロー単位で確認します。
    • OAuth用のURLを後回しにする。ドメイン、HTTPS、公開URL、Webhook URLを先に決めないと、連携設定で戻り作業が出ます。
    • 共有Credentialを便利だからと使い回す。誰がどのワークフローで使うか、編集できる人を分けておきます。
    • APIキーをワークフローに置きっぱなしにする。不要になったキーは無効化します。
    • 実行履歴を残しすぎる。ログや履歴が増えるほどDBとストレージを圧迫します。
    • Webhook停止を実行履歴だけで見ようとする。失敗通知、外形監視、影響範囲確認を分けておきます。
    • Webhookを認証なし、失敗通知なし、リトライなしで公開する。小さく動いても、止まった時に追えない構成になります。
    • workflow exportだけで安心する。DB、volume、`.env`、N8N_ENCRYPTION_KEY、Credential復元まで確認します。
    • 更新前にバックアップを取らない。Dockerイメージ更新の前後で戻せる状態にします。
    • Webhook URLを雑にばらまく。外部から叩かれる入口なので、用途ごとに分けます。
    • 料金だけでWindows VPSを選ぶ。n8nは基本Linuxで十分なことが多く、Windowsは画面アプリ用です。

    候補サービスの見方

    サービス合う人確認すること次の行動
    ConoHa VPSn8n、Dify、Bot、AIエージェントをまず常時稼働させたい人2GBで足りるか、バックアップ、セキュリティグループ、オブジェクトストレージ、公開範囲。公式のAIエージェント構成例と料金を確認する。
    XServer VPSn8nに加えてWebアプリ、API、Dify、Dockerも使いたい人2GB、6GB、12GBの差、キャンペーン期限、通常価格、自動バックアップ/SLAの有無。必要メモリを決めてプランを見る。
    さくらのVPSLinuxとDockerを自分で組みたい人1G、2G、4Gの性能差、リージョン、ディスク、スケールアップの流れ。Docker構築環境で始めるか確認する。
    ABLENET VPSWindowsアプリやMT4/MT5も動かしたい人Windows Server、RDS/SAL、メモリ、通常価格、試用期間。n8n目的ではなく、Windows用途が本当にあるか切り分ける。

    公式ページで確認する

    ConoHa VPS

    n8nを含むAIエージェント環境を、小さく常時稼働させたい人向け。

    ConoHa VPSを確認する
    XServer VPS

    Dify、Docker、Webアプリ、APIも含めて性能と価格を見たい人向け。

    XServer VPSを確認する
    ABLENET VPS

    WindowsアプリやMT4/MT5など、画面操作が必要な用途もある人向け。

    ABLENET VPSを確認する

    次に読む

    確認日: 2026年6月22日。Credential権限まわりは2026年6月28日のSNS第9波、Webhook停止に翌朝まで気づけない不安、認証なし・失敗通知なし・リトライなしの運用不安、後から認証・通知・リトライを足す手戻り、Docker更新後の初期化、Credential復元不安は2026年6月30日のAggressive Wave・反応回収・外部調査を読者ペインとして反映し、仕様確認はn8n公式Docsで行います。料金、キャンペーン、仕様は変更されることがあります。