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

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

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

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

まず結論

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

n8n用VPSで先に決めること

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 / volume	workflowやCredential、実行履歴が戻らず、n8nが初期状態に見える。	バックアップ対象、スナップショット、DBダンプ、Docker volumeの場所。
`.env` / N8N_ENCRYPTION_KEY	DBがあっても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ダンプ、設定ファイル、別保管の復旧手順。

必要なスペックの考え方

使い方	最初の見方	増やすタイミング
個人の予約投稿、通知、軽いWebhook	2GB前後から検証しやすいです。まずはワークフロー数と実行頻度を絞ります。	実行履歴が増える、同時実行が増える、ブラウザ操作系の処理が重い時。
仕事用の定期処理、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 VPS	n8n、Dify、Bot、AIエージェントをまず常時稼働させたい人	2GBで足りるか、バックアップ、セキュリティグループ、オブジェクトストレージ、公開範囲。	公式のAIエージェント構成例と料金を確認する。
XServer VPS	n8nに加えてWebアプリ、API、Dify、Dockerも使いたい人	2GB、6GB、12GBの差、キャンペーン期限、通常価格、自動バックアップ/SLAの有無。	必要メモリを決めてプランを見る。
さくらのVPS	LinuxとDockerを自分で組みたい人	1G、2G、4Gの性能差、リージョン、ディスク、スケールアップの流れ。	Docker構築環境で始めるか確認する。
ABLENET VPS	WindowsアプリやMT4/MT5も動かしたい人	Windows Server、RDS/SAL、メモリ、通常価格、試用期間。	n8n目的ではなく、Windows用途が本当にあるか切り分ける。

公式ページで確認する

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