HostingerのVPSでn8nを動かす：タスク課金のないB2B自動化

要点

VPSでn8nを動かすとは、自動化ツールを自分のサーバーで動かし、タスクごとの課金の代わりにマシンの固定費を払うことです。Zapierの請求がすでに重いとき（年間プランでタスク10,000件は月額129米ドル）、または1回の実行にステップが多いときに元が取れます。クレジット10,000では、Make CoreはまだVPSと同じ価格帯です。本番の構成は4つです。Docker上のn8n、データベースとしてのPostgreSQL、リバースプロキシ（NginxまたはTraefik）、サブドメインのSSL証明書です。HostingerのKVMプランはRAM 4 GBから32 GBまであり、n8nのドキュメント自身が、4 GBのインスタンスで毎秒最大220実行まで処理したテストを公開しています。上限は請求額ではなくなり、CPU、メモリ、そしてサーバーを見る人になります。自動化が重要な業務ルールを抱え始めたら、次はキャンバスにノードを足すことではなく、オーダーメイドの連携です。

1. B2Bでタスク課金が重くなる理由

MakeとZapierは、フローが実行する仕事に対して課金します。Zapierでは、2026年10月12日に読んだ公式料金ページによると、「a task is counted whenever Zapier successfully completes a unit of work for you」です。完了したアクションはそれぞれ数え、トリガーとフィルターは数えません。Makeでは、モジュールのアクションごとにクレジットを1つ使います。n8n Cloudの課金は違います。ワークフロー全体の1回の実行ごとに課金し、n8nの料金ページの言葉では「regardless of complexity」です。

B2Bの運用では、差はすぐに出ます。注文を受け、ERPを参照し、CRMを更新し、税務システムで請求書を作り、営業に知らせるフローには、アクションが5つあります。月に2,000回動かすと（仮の例です）、Zapierではタスク10,000件、Makeでは少なくともクレジット10,000になります。n8nでは実行2,000回です。自分のVPSでは、実行回数は請求に入りません。入るのはCPUとメモリの使用量です。

2つ目の問題は、上限を超えたときに何が起きるかです。Zapierでタスクごとの課金をオンにすると、超過分は年間プランで基本料金の1.25倍、月額プランで2.5倍になり、利用はサブスクリプション価格の3倍に達したところで止まります。オプションをオフにすると、自動化は上限で止まり、次の請求サイクルまで再開しません。Makeでは、クレジットがなくなると「your scenarios won't continue to run」です。請求や顧客対応を自動化しているなら、月の25日に止まるコストは、プランの差額より大きくなります。

既製のツールで自動化するか、システムを作るかまだ迷っているなら、オーダーメイドのシステムと連携のページが、それぞれのアプローチがどこで終わるかを説明しています。

2. 各選択肢の費用を並べる

以下の数字は、2026年10月12日に公式ページで読んだものです。単位は同じではありません（タスク、クレジット、実行、サーバー）。そこが要点です。量とともに増えないのはVPSだけです。

出典：Zapier、Make、n8n、Hostinger VPSの公式料金ページ。

表だけで決める前に、3つあります。第一に、Hostingerのキャンペーン価格は、契約月数で割ったプラン総額であり、2年ごとの更新は定価です。費用は更新価格で見てください。第二に、Hostingerのn8nホスティングページは「ワークフローと実行は無制限」と案内していますが、実際の上限はハードウェアです。小さいマシンの重いフローは、どんな枠よりも先に止まります。第三に、n8nの有料Businessライセンスは、セルフホストでも、料金ページによれば、すべてのインスタンスの実行を契約枠に合算します。固定費が当てはまるのは、n8nがGitHubで維持している標準のセルフホスト版です。

分岐点は表からそのまま出ます。Zapierでは、年間プランのタスク10,000件が月額129米ドルです。KVM 2の更新はR$ 77.99で、ドルはレアルより高いので、為替を計算しなくてもVPSの方が安くなります。Makeに対しては違います。クレジット10,000ではCoreが月額9米ドルで、KVM 2と同じ価格帯であり、世話をするサーバーはありません。この量では、MakeはVPSに負けません。VPSが元を取るのは3つのタイプです。すでにZapierのタスク10,000件以上の枠を払っている人。ステップが多いフローを動かす人。Makeではモジュールのアクションごとにクレジットを使うからです。クレジットが尽きたときに自動化を止めたくない人。Makeのページが価格を出しているのはクレジット10,000までです。それより多い量は、決める前に表を確認してください。

表に出ない費用は運用です。更新、バックアップ、Webhookが失敗したときのログ確認。n8nのドキュメント自身が警告しています。「n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime.」その時間には値段があります。自分の時間か、雇う人の時間かです。

現行のホスティングとVPSのプランを確認するには、紹介リンクからHostingerを開く。プロジェクトに必要なリソースでプランを選んでください。

3. 本番向けの参照アーキテクチャ

Hostingerのテンプレート「Ubuntu 24.04 with n8n」は、Dockerに入ったn8nを最初から渡し、数分で始められます。自動化に依存するB2Bの運用では、推奨する構成は4層です。

Docker上のn8n

公式イメージは n8nio/n8n で、ポート5678を待ち受けます。コンテナには、n8nのデータディレクトリ用の永続ボリュームが必要です。外部データベースを使っても、ドキュメントによれば、インスタンスの暗号鍵とログはそこに残ります。鍵を保管せずにこのボリュームを失うと、保存した認証情報へアクセスできなくなります。

SQLiteではなくPostgreSQL

既定では、n8nは認証情報、実行、ワークフローを、ボリューム内のファイルであるSQLiteに書きます。テストには足ります。本番では、PostgreSQLの方が一貫したバックアップをしやすく、同時書き込みにも強く、ドキュメントに公開された単一インスタンスの性能テストでn8nが使ったデータベースです。切り替えは環境変数です。DB_TYPE=postgresdb と DB_POSTGRESDB_* です。

SSL付きリバースプロキシ

n8nをインターネットに直接出してはいけません。公式のDocker Composeガイドは、TraefikでTLS証明書を発行・更新し、n8nへはHTTPSだけで届くようにします。VPSがすでに他のサイト用にNginxを動かしているなら、Nginxが同じ役割をします。サブドメインでトラフィックを受け、SSLを終端し、n8nのローカルポートへ渡します。ERP、決済ゲートウェイ、CRMのWebhookは有効なHTTPSを要求するので、この層は任意ではありません。

サブドメインとWebhook URL

公式ガイドの前提は、VPSのIPを指すAレコードを持ったドメインまたはサブドメインです。n8nは正しいWebhook URLを作るためにそのアドレスを知る必要があります。N8N_HOST、N8N_PROTOCOL=https、そして N8N_WEBHOOK_URL です。この変数はn8n 2.30.0からあります。それより前のバージョンの名前は WEBHOOK_URL です。これがないと、n8nは内部アドレスのWebhookを作り、外部のシステムはそこに届きません。

4. サイジング：n8nに必要なRAMとCPU

n8nのドキュメントは、メモリの最小要件を公開していません。公開しているものの方が役に立ちます。何がメモリを押し上げるかと、基準になるテストです。メモリエラーのページで、n8nは「doesn't restrict the amount of data each node can fetch and process」と書き、重くなる要因を挙げています。JSONの量、バイナリファイルの大きさ、ワークフロー内のノード数、Codeノードの使用、手動実行（n8nはデータを画面へコピーします）、同時に動くワークフローです。

ドキュメントに公開された性能テストは、RAM 4 GBの単一インスタンス、mainモードのn8n、PostgreSQLを使い、ワークフロー実行を毎秒最大220まで記録しました。これは、軽いフローなら4 GBでn8nが余裕を持って動くことを示します。大きな表計算、PDF、AIモデルへの呼び出しではどうなるかは示していません。メモリが溢れるのはそこです。

仕様と価格の出典は、HostingerのVPS公式ページです。使い方の列は、n8nドキュメントのメモリ要因からの私の推奨であり、計測ではありません。

同じサーバーにPostgreSQLを置くB2Bの運用では、KVM 2が妥当な出発点です。データベースとプロキシもメモリを使い、余裕があれば、添付ファイル付きのフローが他を落としにくくなります。HostingerのFAQもKVM 2を同じように、n8nのような中規模アプリケーションに足りる能力だと説明しています。

プランを上げる前に、フローを調整してください。n8nのドキュメントは、処理をバッチに分けること（公式の例は、1実行10,000行を200行に置き換えます）、ネイティブノードで足りるときにCodeノードを避けること、大きな量を手動実行で試さないこと、メインへ返すデータを少なくしたサブワークフローに分けることを勧めています。それでもヒープエラーが出るなら、NODE_OPTIONS に --max-old-space-size を付けると、Nodeが使えるメモリが増えます。

1台のサーバーでは足りないとき、n8nはqueue modeで伸ばします。ドキュメントの複数インスタンスのテストは、Webhookとワーカーを別インスタンスにし、Redisを使います。Hostingerには、キューモードのn8n向けのVPSテンプレートがあります。

必要なのが、n8nをERP、ストア、CRMと話すようにすることなら、それはオーダーメイドの連携（Webhook、キュー）です。システムと自動化したい内容を書いてください。

プロジェクトを相談

5. Hostinger VPSでの手順

以下は、n8n公式のDocker Composeガイドに沿い、前にPostgreSQLとプロキシを置きます。Hostingerの完成テンプレートを使った場合も、DNS、プロキシ、確認の手順はそのまま使えます。

5.1 サブドメインを向ける

ドメインの管理画面で、サブドメイン（例：n8n.suaempresa.com.br）のAレコードをVPSのIPで作ります。伝播したか確認します。

dig +short n8n.suaempresa.com.br

応答はVPSのIPでなければなりません。そうなるまで、SSL証明書は出ません。

5.2 Dockerを確認し、秘密情報を作る

公式ガイドは、Docker EngineとDocker Composeのインストールを求めています。そのあとプロジェクトのフォルダを作り、N8N_ENCRYPTION_KEY とデータベースのパスワードを、値をターミナルに出さずに .env へ直接書きます。

docker --version
docker compose version
mkdir -p ~/n8n && cd ~/n8n
echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
echo "DB_POSTGRESDB_PASSWORD=$(openssl rand -hex 24)" >> .env
chmod 600 .env

値はターミナルの出力に出ません。.env を開くのは、鍵とパスワードをサーバーの外のパスワード管理へコピーするときだけです。

5.3 データベースと公開アドレスを設定する

同じフォルダの .env に、残りのPostgreSQL変数を足します。このファイルはリポジトリに入れません。

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n

同じファイルに、公開アドレスとタイムゾーンを書きます。n8n 2.30.0より前では、N8N_WEBHOOK_URL を WEBHOOK_URL に置き換えます。

N8N_HOST=n8n.suaempresa.com.br
N8N_PROTOCOL=https
N8N_WEBHOOK_URL=https://n8n.suaempresa.com.br/
GENERIC_TIMEZONE=America/Sao_Paulo
TZ=America/Sao_Paulo

5.4 コンテナを起動する

公式ガイドの docker-compose.yml から始め、独自のボリュームを持つ postgres サービスを足します。n8nのサービスでは、データ用ボリュームを残し、env_file を .env に向け、ポート5678は127.0.0.1だけに公開します。プロキシだけがn8nに届くようにするためです。

sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs n8n --tail 50

2つのコンテナが実行中と出て、n8nのログにデータベース接続のエラーがないことが必要です。

5.5 プロキシとSSLを置く

公式ガイドのTraefikを使うなら、証明書は最初のアクセスで勝手に出ます。VPSにすでにNginxがあるなら、サブドメイン用のサイトをこのブロックで作ります。トラフィックを渡し、n8nの画面のリアルタイム接続を維持します。

location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

そのあと証明書を発行し、公開アドレスを試します。

sudo certbot --nginx -d n8n.suaempresa.com.br
curl -I https://n8n.suaempresa.com.br

curl は、証明書の警告なしに、HTTPSでステータス200を返す必要があります。ブラウザでアドレスを開き、インスタンスのオーナーアカウントを作ります。VPSのファイアウォールでは、SSH、HTTP、HTTPSだけを開けたままにします。

6. 運用：n8nを動かし続けるもの

立ち上げは短い部分です。信頼できる自動化と、金曜の夜に消える自動化を分けるのは、そのあとの習慣です。

バックアップは2つ。 PostgreSQLのダンプが、ワークフロー、暗号化された認証情報、履歴を持ちます。N8N_ENCRYPTION_KEY が、その認証情報を読む能力を持ちます。片方だけでは何も復元できません。ダンプは毎日VPSの外へ取り、少なくとも1回はきれいなマシンで復元を試してください。

実行履歴の削除。 n8nは既定で古い実行を消します。実行データのドキュメントによれば、336時間（14日）を超えたもの、または保存された実行が10,000を超えたものを消します。これがないと、ディスクが尽きるまでデータベースが大きくなります。.env に明示するなら次のとおりです。

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000

枠を切った更新。 更新とは、新しいイメージを取り、Composeでコンテナを作り直すことです。バックアップのあと、顧客のWebhookが来る時間の外で行い、先にリリースノートを読んでください。WEBHOOK_URL から N8N_WEBHOOK_URL への変更だけでも、バージョンのあいだで変数名が変わることが分かります。

最小限の監視。 別のフローが失敗したときにチームへ知らせるエラー用ワークフローをn8nに置き、サブドメインを時々開く外部モニターを置きます。サーバーが落ちたとき、気づくのは外部モニターだけです。

同じVPSでAIエージェントなどの別ツールも動かすなら、コンテナで分け、合計メモリを見てください。HostingerのVPSでClaude Codeを24時間動かすの記事が、同じ種類のサーバーのもう一つの使い方を示しています。

7. n8nでは足りず、オーダーメイド連携が向くとき

n8nは、すでにAPIとコネクタがあるシステムをつなぐのに優れています。次の4つでは、置き場所として外れ始めます。

1. 業務ルールがキャンバスに住んでいる。 価格計算、与信の方針、税のルールがCodeノードに散らばると、テストもレビューも信頼できる版管理もないコードになります。重要なルールは専用のサービスへ置き、n8nはそのサービスを呼ぶだけにします。
2. 量が一貫性を要求する。 注文を二重に処理しても、失ってもいけないなら、キュー、冪等性、制御された再処理が必要です。その一部はn8nでも組めますが、専用ワーカーの方が部品は少なくなります。
3. 相手のシステムにコネクタがない。 古いERP、ローカルのデータベース、APIのないポータルには、そのシステム用に書いたアダプタが必要です。n8nはアダプタを使います。代わりにはなりません。
4. チームに必要なのはフローではなく画面。 承認、照合、例外には画面が要ります。止まった表計算を置き換えるために自動化が生まれたなら、表計算をシステムに置き換えるときの記事が、パネルの時期かどうかを見る助けになります。

B2Bでうまくいきやすい形はハイブリッドです。単純な連携とオーケストレーションはn8n、重要なルールと難しいコネクタは自前のサービス、すべて自分が管理する同じインフラの上です。

エージェント向けの完成プロンプト

下の文を、VPSのターミナル（SSH）に入れるAIエージェントへ貼ってください。前提を確認し、第5節の手順を同じ順で実行し、最初のエラーで止まります。管理画面へのログイン、DNSレコードの作成、ブラウザでのオーナーアカウント作成は、あなたの作業のままです。

UbuntuのVPSに、Docker、PostgreSQL、プロキシ、SSLでn8nをインストールします。

こちらの情報：
- サブドメイン: <SUBDOMAIN>  （例: n8n.suaempresa.com.br）
- VPSのIP: <VPS_IP>
- プロキシ: <TRAEFIK_OR_NGINX>

ルール：
- パスワード、トークン、APIキー、ログインコードを、表示したり、チャットに貼ったり、バージョン管理されるファイルに書いたりしない。
- データベースのパスワードとN8N_ENCRYPTION_KEYは、サーバーの.envだけに置く。場所を伝え、値は伝えない。
- 各コマンドは実行前に示し、正確なエラーで止まり、出力を添える。
- コマンド、バージョン、価格を発明しない。下のコマンドだけを使う。

前提（最初に確認）：
1. 実行: dig +short <SUBDOMAIN>。出力は <VPS_IP> でなければならない。違うなら止まり、ドメイン管理画面でAレコードを作るよう頼む。
2. 実行: docker --version と docker compose version。どちらかがなければ止まり、知らせる。

手順：
3. 実行: mkdir -p ~/n8n && cd ~/n8n。そのあと、値を表示せずに: echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env、echo "DB_POSTGRESDB_PASSWORD=$(openssl rand -hex 24)" >> .env、chmod 600 .env。openssl rand を単体で実行せず、.envの中身を見せない。.envの鍵とパスワードをパスワード管理へコピーするよう思い出させる。
4. .envへ追加: DB_TYPE=postgresdb、DB_POSTGRESDB_HOST=postgres、DB_POSTGRESDB_DATABASE=n8n、DB_POSTGRESDB_USER=n8n。
5. .envへ追加: N8N_HOST=<SUBDOMAIN>、N8N_PROTOCOL=https、N8N_WEBHOOK_URL=https://<SUBDOMAIN>/、GENERIC_TIMEZONE=America/Sao_Paulo、TZ=America/Sao_Paulo。n8nのバージョンが2.30.0より前なら、N8N_WEBHOOK_URLの代わりにWEBHOOK_URLを使う。
6. n8n公式のDocker Composeガイドからdocker-compose.ymlを作り、独自ボリュームのpostgresサービスを置く。n8nサービスではデータ用ボリュームを残し、env_file .envを使い、ポート5678は127.0.0.1だけに公開する。
7. 実行: sudo docker compose up -d、そのあと sudo docker compose ps と sudo docker compose logs n8n --tail 50。2つのコンテナが実行中で、ログにデータベース接続のエラーがないこと。
8. プロキシ：
   - <TRAEFIK_OR_NGINX> がTraefikなら、公式ガイドの設定を使う。
   - Nginxなら、location / が http://127.0.0.1:5678 へ渡し、proxy_http_version 1.1 と、Upgrade および Connection "upgrade" のヘッダを持つサブドメインのサイトを作る。そのあと実行: sudo certbot --nginx -d <SUBDOMAIN>。
9. VPSのファイアウォールでは、SSH、HTTP、HTTPSだけを開けたままにする。

こちらが行う手順（到達したら知らせる）：
- ドメイン管理画面でAレコードを作る。
- ブラウザで https://<SUBDOMAIN> を開き、インスタンスのオーナーアカウントを作る。
- .envからN8N_ENCRYPTION_KEYとデータベースのパスワードをパスワード管理へコピーする。

最終確認：
- 実行: curl -I https://<SUBDOMAIN>。証明書エラーなしに、HTTPSでステータス200を返すこと。
- 実行: sudo docker compose ps。n8nとpostgresが実行中であること。
両方の確認が通ってから、終わったと言う。何をしたかと、各ファイルがどこにあるかの要約を渡す。

よくある質問

n8nのホスティングはいくらか

主な費用はVPSです。2026年10月12日に読んだHostingerの公式ページでは、KVM 1（RAM 4 GB）は月額R$ 29.99で、更新は月額R$ 59.99です。KVM 2（8 GB）は月額R$ 43.99で、更新は月額R$ 77.99、更新は2年ごとです。おそらく既に持っているドメインと、保守の時間を足してください。比較として、n8n Cloud Starterは年間プランで月額20ユーロ、実行2,500回です。n8nの料金ページによります。

n8nに必要なRAMは何GBか

n8nのドキュメントは最小値を決めていません。公開されている性能テストは、PostgreSQL付きのRAM 4 GBのインスタンスで、毎秒220実行に達しました。実際には、軽いフローなら4 GBで足ります。同じマシンにPostgreSQLとプロキシがあり、フローの途中にファイルがあるなら、8 GBが余裕になります。消費は、JSONの量、バイナリファイル、Codeノード、同時のワークフローで上がります。

Hostingerのn8nテンプレートを本番で使えるか

出発点としては使えます。「Ubuntu 24.04 with n8n」テンプレートは、Dockerに入ったn8nをインストール済みで渡します。顧客の処理を載せる前に、どのデータベースを使っているか確認し、SQLiteならPostgreSQLへ替え、SSL付きのサブドメイン、Webhookの変数、暗号鍵を含むバックアップを設定してください。

SQLiteかPostgreSQLか

SQLiteはn8nの既定で、テストに向きます。本番はPostgreSQLです。n8nが動いたままで一貫したバックアップができ、同時実行との相性がよく、ドキュメントの単一インスタンス性能テストのデータベースでもあります。VACUUMを実行しないとディスク容量が戻らない、というSQLiteの問題も避けられます。

自分のVPSのn8nに実行回数の上限はあるか

課金上はありません。上限はマシンの能力、つまりCPU、メモリ、ディスクになります。例外はn8nの有料Businessライセンスで、セルフホストでも、料金ページによれば、すべてのインスタンスの実行を契約枠に合算します。

結論

HostingerのVPSでn8nを動かすと、量とともに増える請求が、サーバーの固定費に替わります。Zapierのタスク10,000件の枠と、ステップの多いフローでは元が取れます。クレジット10,000のMake Coreとは価格が並び、利点は枠が尽きたときに止まらないことです。その代わりに払うのは運用です。PostgreSQL、SSL付きプロキシ、暗号鍵を含むバックアップ、枠を切った更新。データベースとプロキシが同じマシンならKVM 2から始め、プランを上げる前にフローを調整し、重要な業務ルールはキャンバスの外へ出してください。自動化が請求、在庫、顧客対応を支え始めたら、オーダーメイドのシステムと同じ世話が要ります。

必要なのが、ERP、ストア、CRMがWebhookとキューで会話する、オーダーメイドのシステム連携と自動化されたフローなら、システムと自動化したい内容を書いてください。

プロジェクトを相談