自ホストのn8nにRAMはどれくらい要りますか？

約2 GBが、n8nとそのPostgresデータベースと通常のワークフローに快適なスイートスポットです。ワークフローが軽ければ1 GBでも動きますが、大きな実行で感じます。重い並列実行や大きなペイロードなら4 GBへ。

n8nを自ホストするのにDockerは要りますか？

断然一番簡単な方法です — 一つのcomposeファイルがn8n、データベース、永続ストレージを与え、アップグレードは一回のpull。代わりにnpmで入れられますが、Dockerが依存とアップグレードの頭痛を省いてくれます。

n8nの自ホストはn8nクラウドより安いですか？

自動化を安定して流すなら、はい — 定額の月額VPSが実行ごとの価格に勝ち、ワークフローや実行の上限がありません。月に数回の実行なら、ホスト席のほうが簡単かも。人々が自ホストするもう一つの理由は制御：データとAPIキーがサーバーから決して出ません。

n8nにドメインは要りますか？

OAuthベースのノード（Googleなど）ときれいなHTTPSには、はい — ドメインをサーバーに向け、n8nを証明書付きのリバースプロキシの後ろに置きます。純粋に内部用途なら、ドメインなしでSSHトンネル越しに到達できます。

n8nはNAT VPSで動きますか、それとも専用IPが要りますか？

内部/SSHトンネル用途はNATの箱で動きます。自分のドメインとHTTPSの公開URLが欲しい（一部のOAuthコールバックとwebhookに必要）なら、全ポートを制御する専用IPプランのほうがきれいに合います。

DockerでVPSにn8nを自ホストする

n8nは、軽く使い始めてから静かに業務の半分をそれ経由でルーティングするような道具です。その時点で「誰かのクラウド席で動き、実行ごとに計量され、APIキーが彼らのサーバーに住んでいる」があまり良く感じなくなります。自ホストが三つとも直します — 定額、実行の上限なし、そして鍵が自分の所有する箱に留まる。Dockerなら15分の仕事です。

実際にどれくらいのサーバーが要るか

買い過ぎ・買い足りないを避けるため、まず正直な数字を：

~2 GB RAM がスイートスポット — n8nとそのPostgresデータベースと通常のワークフローがここに快適に収まります。
1 GB はワークフローが軽ければ動きますが、大きな実行で気づきます。
4 GB は重い並列実行をするか大きなペイロードを通す場合。

n8nは待機時にCPUを食いません；実行中にスパイクします。2コアの箱が大半の構成に十分です。（仕様をワークロードに合わせる詳細はサイジングガイドで。）

Docker構成

まっさらなUbuntu/Debianの箱で、Dockerを入れます：

curl -fsSL https://get.docker.com | sudo sh

フォルダと docker-compose.yml を作ります — 永続ボリュームとPostgresを持つn8n：

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

指摘する価値が二つ：ボリューム（n8n-data、db-data）が、再起動とアップグレードをまたいでワークフローを生かすものです — 飛ばさないこと。そしてn8nは 0.0.0.0 ではなく 127.0.0.1 にバインドされています — インターネットに直接晒されていません。それは意図的で、次のステップがアクセスを安全に扱います。

アクセス：HTTPSかトンネル

公開URL（OAuthノードとwebhookに必要）： サブドメインをサーバーに向け、127.0.0.1:5678 の前でリバースプロキシを動かします（Caddyが最も手間なし — 自動HTTPS）。ここで専用IPプランが合います、ポートとDNSを制御するので。
自分のためだけ、ドメインなし： プロキシを飛ばしてSSHトンネル越しに到達 — ssh -L 5678:127.0.0.1:5678 user@server、それから localhost:5678 を開く。NAT VPSで問題なく動きます。

締めて、上げ続ける

n8nはあなたのAPIキーと資格情報を保つので、箱は締まっていなければなりません：本物の資格情報を入れる前にセキュリティチェックリスト（SSH鍵、ファイアウォール、パスワードログインなし）をやりましょう。composeファイルの restart: always がすでに、Dockerがクラッシュや再起動の後にn8nを戻すことを意味します — それで稼働時間は片づいています。

値打ちがあるか？

量について自分に正直に。自動化を絶えず動かすなら、自ホストがコストで勝ち（定額対実行ごと）、ワークフロー/実行の制限を取り除きます。月に数フローを起動するだけなら、ホスト席のほうが手間が少ない。でも制御の論拠はいずれにせよ立ちます：あなたのワークフロー、あなたのデータ、あなたの鍵 — 借り物ではなく、あなたのサーバーに。 n8nに本気になった多くの人にとって、それが決め手です。

2 GBの箱、composeファイル、ドメイン（かトンネル）、それで自分の自動化ハブを動かしています — KYCなしの暗号通貨で支払い可能、数分で稼働。

既製の構成： n8n向けVPS を参照 — 推奨プランと1分の暗号デプロイ。