「2GBのVPSでn8nは動くのか」を調べると、たいてい「動く」か「厳しい」のどちらかしか書いてありません。具体的に何MB増えるのかは、ほとんど出てきません。

実際に載せて、1分刻みで測りました。

n8nを載せると何が何MB増えるか

合計402MB。 そして載せ終わってもまだ1.1GB空いています。

測定条件

  • サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS
  • 元から動いていたもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本
  • 記録：1分ごとにcronで自動記録（スクリプトは前の記事に載せています）
  • 時間：2026-09-07 01:12 〜 01:37

前の記事で43時間分のベースラインを取ってあります。「載せる前」が分かっているので、増えた分がそのままn8nのコストになります。

結果：4段階に分けて測る

多くの記事は「n8nは○MB」で終わります。しかし実際に増えるものは1つではありません。

段階システム全体のメモリ増分
元の状態438MB—
＋Dockerデーモン476MB+38MB
＋n8nコンテナ起動804MB+328MB
＋UIを開いてワークフローを1本840MB+36MB
合計 +402MB

ディスクは 10GB → 13GB（+3GB）。スワップは 0 → 37MB 使われました。

発見1：Dockerデーモンだけなら38MB

「Dockerは重い」とよく言われます。実際に測ると、デーモン単体では38MBでした。

導入直後の記録がこれです。

01:14  431MB  python 90.8, systemd-journal 72.7, multipathd 26.7   ← 導入前
01:15  523MB  apt-get 98.3, python 90.8, dockerd 87.6              ← インストール中
01:16  483MB  python 90.8, dockerd 88.3, systemd-journal 72.9      ← 完了
01:19  478MB  python 90.8, dockerd 87.0, systemd-journal 73.0      ← 安定

インストール中は apt-get で523MBまで上がりますが、終われば478〜485MBに落ち着きます。

重いのはDockerではなく、コンテナの中身です。 ここを分けずに「Dockerを入れるとメモリを食う」と言うのは、少し雑だと思いました。

プロセスのRSSを足しても、実際の増加分にはならない

面白いズレがありました。dockerd のRSSは87MBですが、システム全体の増加は38MBです。

RSSは共有ライブラリを重複して数えるため、プロセスごとの数字を足し上げても実際の消費量にはなりません。信用すべきは free の used のほうです。

ps の数字だけを見て「87MB食っている」と書くと、倍以上ずれます。

発見2：n8nの正体はNode.jsプロセス2本

n8nを起動した直後の上位プロセスがこれです。

node-MainThread   305.6MB
node-MainThread   117.5MB
dockerd            78.1MB

docker stats ではコンテナ全体で 395.9MiB でした。

n8nというアプリケーションが重いのではなく、Node.jsのランタイムが2本立ち上がっているという構図です。片方がメインプロセス、もう片方がワーカーだと考えられます。

参考までに、このサーバーで元から動いている自作のPythonアプリは90MBです。同じ「1つのアプリ」でも、ランタイムが違うと3〜4倍変わります。

発見3：UIを開くだけで36MB増える

ここが今回いちばん意外でした。

ブラウザでn8nの管理画面を開き、ワークフローを1本組んだ結果です。

コンテナのメモリ
起動直後（UI未接続）395.9MiB
UIを開いて操作した後434.4MiB

+38.5MiB。しかも、操作をやめても戻りませんでした。

システム全体でも 804MB → 840MB に増えています。

つまり 「n8nは○MB」という数字は、測ったタイミングで変わります。 起動直後の数字だけを見て容量を見積もると、実際の運用では足りなくなる可能性があります。

発見4：ディスクが3GB増えた

メモリばかり見ていましたが、先に効いてきそうなのはディスクでした。

使用量
n8n導入前10GB
n8n導入後13GB

/var/lib/docker の中身だけで 2.1GB。n8nのイメージ本体です。

100GBのディスクなので今は問題ありませんが、この調子でDify、Ollama、その他を試したら、メモリより先にディスクが苦しくなります。 ローカルLLMのモデルファイルは1つ数GBです。

測る前は、この順番を逆に考えていました。

メモリ上限を必ず付ける

今回はこう起動しました。

sudo docker run -d --name n8n \
  --restart unless-stopped \
  --memory=768m \
  -p 127.0.0.1:5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e GENERIC_TIMEZONE="Asia/Tokyo" \
  -e TZ="Asia/Tokyo" \
  docker.n8n.io/n8nio/n8n

--memory=768m が要点です。

このサーバーには、本番で動いている処理と公開中のサイトが同居しています。n8nが暴走してメモリを食い尽くすと、OOM Killerがどのプロセスを殺すか選べません。 上限を課しておけば、あふれるのはコンテナの中だけで済みます。

結果は 434.4MiB / 768MiB（56.6%）。余裕を持って収まりました。上限としては妥当な線だったと思います。

-p 127.0.0.1:5678:5678 も必須です

n8nは初期状態で誰でもアクセスできます。 -p 5678:5678 と書くと全世界に公開されてしまう。

127.0.0.1 を頭に付けると、サーバー内部からしか繋がらなくなります。管理画面はSSHトンネル経由で開きます。

ssh -L 5678:127.0.0.1:5678 ユーザー名@サーバーのアドレス

そのうえでブラウザから http://localhost:5678 を開く。外に開けずに使えます。

自動化ツールは認証情報の塊です。APIキーもパスワードも入ります。まずポートを閉じてから起動してください。

結論：2GBに載る。ただし条件がある

載る

  • 合計402MB増えて、まだ1.1GB空いている
  • 元から動いていた処理も、公開中のサイトも止まらなかった
  • CPUは終始ほぼアイドル（ロードアベレージ0.08前後）

気をつけること

  • 上限を課さないなら載せないほうがいい。同居しているものが道連れになります
  • ディスクが3GB減る。ツールを増やすならここが先に効きます
  • UIを開くと増えて、戻らない。起動直後の数字で見積もらないこと
  • スワップは用意しておく。今回37MB使われました

載らないケース

  • PostgreSQLを別途立てる構成（n8nは本番運用でPostgreSQL推奨。SQLiteのままなら今回の数字ですが、DBを足すとさらに100〜300MB）
  • ワーカーを分離するスケール構成
  • 同じサーバーでDifyやローカルLLMも動かす

次に測ること

n8nは載りました。残り1.1GB。

次はここにDifyを入れてみます。同じ手順で、同じ間隔で測ります。入るのか、入らないのか。入らないならどこで止まるのか。

「AI用途のVPSは何GB必要か」という問いに、推測ではなく実測で答えられるところまで持っていくつもりです。