n8nをVPSにセルフホストする手順｜Docker＋PostgreSQLで構築・バックアップまで実機検証【2026年版】

2026-09-26

※内容は2026年9月26日時点の情報（n8n 2.40.7）をもとにしています。n8nはほぼ毎週更新され、2026年10月にはバージョン3.0が出る予定です。

「問い合わせが来たらすぐスマホに知らせたい」「毎朝決まった集計を自動で送りたい」。こうした自動化を、Zapierのような有料サービスに頼らず、自分のサーバーで動かせるのが「n8n（エヌエイトエヌ）」です。

この記事では、n8nをVPSにセルフホストする手順を紹介します。当サイトOSSMatchの運営チームが、実際にVPSへn8nを立てて、構築・自動化の作成・バックアップと復元・アップデートまでを通しで試した結果をもとにまとめました。実機で見つかったつまずきも、そのまま載せています。

自動化したいけれど、Zapierの料金やデータの置き場所が気になっていませんか

ZapierやMakeは、画面上でサービス同士をつなぐだけで自動化が作れる便利なサービスです。ただ、使い込むほど次のような悩みが出てきます。

• 自動化の数や実行回数が増えるほど、月額料金が上がっていく
• 無料プランでは、2ステップ以上の自動化や短い間隔での実行ができない
• 問い合わせの内容や顧客の情報を、海外のクラウドに流すことに抵抗がある

私たちはWeb制作とWebサービスの開発をしていて、自動化はふだんから積極的に取り入れています。最近は、定型的な作業の多くをAI（Claude Code）とcron・スクリプトで片付けていて、Zapierは少し触ったことがある程度です。

それでもn8nを試したのは、「人がいない時間に、何かが起きたら動く」自動化には、専用の仕組みがあると便利だからです。問い合わせフォームの送信、外部サービスからの通知、決まった時刻の実行などです。n8nなら、こうした自動化を画面で組み立てて、自分のサーバーで24時間動かせます。

n8nのセルフホストが向いている人・向かない人

n8nは、ノード（処理の部品）を線でつないで自動化を作るツールです。数百のサービスとの連携部品が用意されていて、JavaScriptやPythonのコードを書き込むこともできます。

セルフホスト版は無料で使え、実行回数の上限もありません。料金はサーバー代だけです。ZapierやMakeとの料金の違い（課金の数え方の違い）は、ここでは簡単に表にまとめます。

一方で、n8nの公式ドキュメント自身が「セルフホストはサーバー管理の知識がある人向け」と書いています。次に当てはまる方は、ZapierやMakeのままか、n8n Cloudを選ぶほうが安心です。

• サーバーのアップデートやバックアップを、自分で続ける自信がない
• 英語の画面に抵抗がある（n8nの画面は英語のみです）
• 自動化の回数が少なく、今の無料プランで足りている

セルフホストの前に知っておきたい2つのこと

1つめはライセンスです。n8nは「Sustainable Use License」という独自のライセンスで公開されています。公式のFAQによると、自社の業務を自動化したり、受託で顧客のためにワークフローを作ったりする使い方は認められています。一方で、n8nをサービスとして提供し、顧客にワークフローを作らせる使い方は認められていません。判断に迷う場合は、公式（license@n8n.io）に確認してください。本記事は法的な助言ではありません。

2つめは日本語です。n8nの画面は英語のみで、公式の日本語訳はありません（2026年9月時点）。有志による非公式の日本語化パッチはありますが、n8nの版ごとに作り直しが必要で、この記事の時点では最新版（2.40.x）向けのものはまだ出ていません。ノード名や設定項目は、各サービスの英語の名前と同じなので、英語のまま使っても大きく困ることはありません。

n8nに必要なスペックとVPSの選び方

この記事の構成は、次の4つのコンテナで動かします。

• n8n本体：画面と自動化の実行
• タスクランナー：Codeノードに書いたJavaScript・Pythonを、本体から切り離して実行する
• PostgreSQL：ワークフローや実行履歴を保存するデータベース
• Caddy：HTTPS化（証明書の取得と更新を自動で行う）

私たちがVPSで実際に測ったメモリの使用量は、次のとおりです。

Codeノードを動かすと、タスクランナーがJavaScriptとPythonの実行環境を立ち上げるため、一時的にメモリが増えます。OSの分と余裕を考えると、メモリ2GBのプランがおすすめです。1GBでも軽い使い方なら動きますが、大きなデータやCodeノードを扱うとメモリ不足になりやすくなります。

※料金は2026年9月時点の公式サイトの表示です。最新の料金は公式サイトで確認してください。

シンVPSの料金・プランを見る（PR）

Docker Composeでn8nを構築する手順

ここからは、Docker Composeでn8nを動かし、Caddyで自動的にHTTPS化する手順を紹介します。前提は次のとおりです。

• Ubuntu 24.04のVPSに、Dockerがインストール済み
• n8n用のサブドメイン（例：n8n.example.com）を用意できる
• ファイアウォールで80番・443番を開けている

DockerのインストールやVPSの初期設定は、Umamiの構築記事の手順1・手順2と同じです。

手順1：DNSを設定し、.envを作る

サブドメインのAレコードを、VPSのIPアドレスに向けます。反映される前に起動すると、HTTPS証明書の取得に失敗するので、先に確認しておきます。

dig +short n8n.example.com   # 自分のPCで実行。VPSのIPアドレスが返ればOK

次に、作業用のフォルダと、パスワードや暗号化キーをまとめた.envファイルを作ります。値はコマンドで自動生成します。

mkdir -p ~/n8n && cd ~/n8n
cat > .env <<EOF
# n8n と runners の版をそろえる（最新の stable は https://github.com/n8n-io/n8n/releases で確認）
N8N_VERSION=2.40.7
N8N_DOMAIN=n8n.example.com

POSTGRES_USER=n8n
POSTGRES_DB=n8n
POSTGRES_PASSWORD=$(openssl rand -hex 16)

# 認証情報（APIキーなど）を暗号化する鍵。失くすと保存した認証情報が二度と読めない
N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)

# n8n本体とタスクランナーの間の合言葉
N8N_RUNNERS_AUTH_TOKEN=$(openssl rand -hex 32)
EOF
chmod 600 .env

特に大事なのがN8N_ENCRYPTION_KEY（暗号化キー）です。n8nに保存したAPIキーやパスワードは、このキーで暗号化されます。このキーを失くすと、保存した認証情報は二度と読めなくなります。あとで紹介するバックアップで、必ず一緒に保存します。

手順2：docker-compose.ymlとCaddyfileを作る

nano docker-compose.ymlで、次の内容を保存します。

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: always
    environment:
      # データベース（PostgreSQL）
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: "5432"
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      # 暗号化キー
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      # 公開URL（Caddy の後ろで動かす）
      N8N_HOST: ${N8N_DOMAIN}
      N8N_PORT: "5678"
      N8N_PROTOCOL: https
      N8N_WEBHOOK_URL: https://${N8N_DOMAIN}/
      N8N_EDITOR_BASE_URL: https://${N8N_DOMAIN}/
      N8N_PROXY_HOPS: "1"
      # タイムゾーン
      GENERIC_TIMEZONE: Asia/Tokyo
      TZ: Asia/Tokyo
      # その他
      NODE_ENV: production
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
      # 外部タスクランナー（Code ノードを別のコンテナで実行する）
      N8N_RUNNERS_MODE: external
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

  n8n-runner:
    image: n8nio/runners:${N8N_VERSION}
    restart: always
    environment:
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
    depends_on:
      - n8n

  postgres:
    image: postgres:18
    restart: always
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
      PGDATA: /var/lib/postgresql/data   # 消さない（Postgres 18 の保存場所の変更対策）
    volumes:
      - db_storage:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 10

  caddy:
    image: caddy:2
    restart: always
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n

volumes:
  n8n_data:
  db_storage:
  caddy_data:
  caddy_config:

ポイントになる設定は次のとおりです。

n8n（5678番）、タスクランナー（5679番）、PostgreSQL（5432番）のポートは、外に公開しません。公開するのはCaddyの80番・443番だけです。

続けて、nano Caddyfileで次の3行を保存します。

n8n.example.com {
    reverse_proxy n8n:5678
}

手順3：起動して、動作を確認する

3つのファイルがそろっていることを確認してから起動します。設定ファイルを作る前に起動すると、同じ名前のフォルダが作られてしまうので注意してください。

ls -l .env docker-compose.yml Caddyfile   # 3つとも「ファイル」になっていること
sudo docker compose up -d
sudo docker compose ps                    # n8n・n8n-runner・postgres・caddy が起動していること

証明書の取得に数十秒かかることがあります。次のコマンドで動作を確認します。

curl -s https://n8n.example.com/healthz             # {"status":"ok"} が返ればOK
sudo docker compose logs n8n | grep -E "Registered runner|Editor is now accessible"

ログに次の行が出ていれば、タスクランナーがn8n本体とつながっていて、画面も開ける状態です。

Registered runner "launcher-javascript" (6fa6e2bd32890c54)
Registered runner "launcher-python" (0369d01996d709cd)
Editor is now accessible via:

手順4：すぐにオーナーアカウントを作る

ブラウザでhttps://n8n.example.comを開くと、オーナー（管理者）の登録画面が表示されます。最初に登録した人がオーナーになるため、起動したらすぐに登録してください。URLを他人に先に開かれると、そのまま乗っ取られてしまいます。

1. 「Set up owner account」の画面で、メールアドレス・名前・パスワードを登録する
2. 「Customize n8n to you」（利用目的のアンケート）は任意。答えずに「Get started」で進めてよい
3. 「Get paid features for free」は、メールアドレスを登録すると、フォルダ機能や実行履歴の検索などが無料で使えるようになる案内。必要なければ「Skip」でよい

登録が済んだら、設定画面の個人設定（Settings → Personal）で、2段階認証も有効にしておきましょう。

最初の自動化：問い合わせフォームの送信をスマホに通知する

構築できたら、実際に自動化を1つ作ってみます。私たちが最初に作ったのは、Webサイトの問い合わせフォームから送信があったら、スマホに通知するワークフローです。通知には、以前紹介した自分のサーバーで動かすプッシュ通知「ntfy」を使いました。

HTTP Requestノードの本文（Body）には、次の式を入れています。フォームの項目を組み立てて、件名付きの通知にしています。

{{ JSON.stringify({
  topic: 'alerts',
  title: '[お問い合わせ] ' + ($json.body.site || 'サイト不明'),
  tags: ['envelope'],
  priority: 4,
  message: '名前：' + ($json.body.name || '（なし）')
    + '\nメール：' + ($json.body.email || '（なし）')
    + '\n\n' + $json.body.message.slice(0, 1000)
}) }}

ntfyのトークンのような秘密の値は、ノードに直接書かず、認証情報（Credentials）に保存するのがポイントです。認証情報は、手順1の暗号化キーで暗号化されてデータベースに保存されます。

作ったワークフローは、画面右上の「Publish」を押すと、外部からの呼び出しを受け付けるようになります（以前のバージョンの「Activate」にあたります）。次のコマンドでテスト送信して、スマホに通知が届けば成功です。

curl -X POST https://n8n.example.com/webhook/contact \
  -H "Content-Type: application/json" \
  -d '{"site":"example.com","name":"テスト太郎","email":"test@example.com","message":"n8n の動作確認です"}'

実行の結果は、ワークフローの「Executions」タブで確認できます。スパムと判断した送信は「受け付けない」の側に流れていることが、線の色でわかります。

バックアップとアップデート：暗号化キーを失わないために

n8nを長く使ううえで一番大事なのが、バックアップです。保存するのは次の3つです。

1. PostgreSQLのデータベース（ワークフロー・認証情報・実行履歴）
2. n8n_dataボリューム（暗号化キーの入った設定ファイル）
3. .envファイル（暗号化キー・データベースのパスワード）

データベースだけを戻しても、暗号化キーがなければ認証情報は読めません。3つをまとめて保存します。

毎日のバックアップ

nano ~/n8n/backup.shで、次のスクリプトを保存します。途中で失敗したら、そこで止まって失敗として終わる作りにしています。

#!/bin/bash
# n8n の DB・データ・設定を毎日保存し、14日分残す（root で実行）
set -euo pipefail
cd "$(dirname "$0")"
DIR="/root/backup/n8n"
STAMP="$(date +%F)"
VOL="n8n_n8n_data"   # 「フォルダ名_n8n_data」。sudo docker volume ls で確認
mkdir -p "$DIR" && chmod 700 "$DIR"

# 1) PostgreSQL（ユーザー名・DB名はコンテナの環境変数を使う）
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB"' \
  | gzip > "$DIR/n8n-db-$STAMP.sql.gz.tmp"
gzip -t "$DIR/n8n-db-$STAMP.sql.gz.tmp"
mv "$DIR/n8n-db-$STAMP.sql.gz.tmp" "$DIR/n8n-db-$STAMP.sql.gz"

# 2) n8n_data ボリューム（暗号化キーの入った config など）
docker run --rm -v "$VOL":/data:ro -v "$DIR":/backup alpine \
  tar czf "/backup/n8n-data-$STAMP.tar.gz.tmp" -C /data .
gzip -t "$DIR/n8n-data-$STAMP.tar.gz.tmp"
mv "$DIR/n8n-data-$STAMP.tar.gz.tmp" "$DIR/n8n-data-$STAMP.tar.gz"

# 3) .env（暗号化キー・DBパスワード）
cp .env "$DIR/n8n-env-$STAMP"

chmod 600 "$DIR"/n8n-*
find "$DIR" -name 'n8n-*' -mtime +14 -delete

chmod 700 ~/n8n/backup.sh
sudo docker volume ls | grep n8n_data      # ボリューム名を確認し、backup.sh の VOL と合わせる
sudo ~/n8n/backup.sh && sudo ls -lh /root/backup/n8n

私たちの環境では、3つの保存が約6秒で終わりました。PostgreSQLを使う構成なら、n8nを止めずにバックアップして問題ありません（止めずに取ったバックアップから、正常に復元できることを確認しました）。

毎日自動で実行するには、sudo crontab -eに次の1行を追加します。ntfyを使っている場合は、失敗したときだけスマホに通知されるようにしておくと安心です（ntfyを使わない場合は「||」から後ろを省略します）。

30 4 * * * /home/ユーザー名/n8n/backup.sh >> /root/backup/n8n-backup.log 2>&1 || curl -s -H "Authorization: Bearer tk_xxxxx" -H "Priority: high" -d "n8nのバックアップに失敗" https://ntfy.example.com/alerts

バックアップファイルは、VPSの外（各社のバックアップ機能や別のストレージ）にも置いておきましょう。ただし.envと暗号化キーは、認証情報そのものを開ける鍵です。置き場所の権限には注意してください。

復元の手順（移行・障害のときだけ）

私たちは、バックアップを別の環境に戻す「新しいサーバーへの移行」も試しました。オーナーのアカウント、ワークフロー、公開の状態、認証情報まで元どおりに戻り、戻した環境からntfyの通知も届きました。

cd ~/n8n
# 新しいサーバーに戻す場合は、先にコンテナとボリュームを作ってから postgres だけ起動する
#   sudo docker compose create && sudo docker compose start postgres
sudo docker compose stop n8n n8n-runner

# DB を作り直して戻す
sudo docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres -c "DROP DATABASE IF EXISTS $POSTGRES_DB;" -c "CREATE DATABASE $POSTGRES_DB OWNER $POSTGRES_USER;"'
set -o pipefail
sudo gunzip -c /root/backup/n8n/n8n-db-YYYY-MM-DD.sql.gz \
  | sudo docker compose exec -T postgres sh -c 'psql -X -q -v ON_ERROR_STOP=1 -U "$POSTGRES_USER" -d "$POSTGRES_DB"'

# n8n_data を戻す
sudo docker run --rm -v n8n_n8n_data:/data -v /root/backup/n8n:/backup alpine \
  sh -c 'rm -rf /data/* /data/.[!.]* 2>/dev/null; tar xzf /backup/n8n-data-YYYY-MM-DD.tar.gz -C /data'

sudo docker compose start n8n n8n-runner

別のサーバーに移すときは、.envも必ず同じものを使ってください。暗号化キーが違うと、n8nは次のエラーを出して起動しません。

Error: Mismatching encryption keys. The encryption key in the settings file /home/node/.n8n/config does not match the N8N_ENCRYPTION_KEY env var. Please make sure both keys match.

アップデートの手順

n8nはほぼ毎週新しい版が出ます。公式は、少なくとも月1回は更新し、何段階もまとめて上げないよう勧めています。

cd ~/n8n
sudo ./backup.sh                          # 1) 先にバックアップ
sudo nano .env                            # 2) N8N_VERSION を新しい版に（n8n と runners が同時に上がる）
sudo docker compose pull                  # 3) 新しいイメージを取得
sudo docker compose up -d                 # 4) 変わったコンテナだけ作り直す
sudo docker compose logs -f n8n           # 5) 「Editor is now accessible via:」が出るまで待つ

私たちが2.40.7から2.41.3に上げたときは、約25秒で終わりました。データベースの移行は起動時に自動で行われ、ログには「Migrations in progress, please do NOT stop the process.」（移行中なので止めないで）と表示されます。

「docker compose down -v」は絶対に使わないでください。「-v」を付けると、暗号化キーの入ったボリュームまで削除されます。データベースを戻しても、保存した認証情報がすべて読めなくなります。

n8nのセルフホストでつまずきやすい点

実機での検証中に私たちが実際にはまった点と、古い記事の手順どおりに進めたときに起きやすい問題をまとめます。

まとめ：n8nならZapierの代わりを月1,000円前後のVPSで持てる

n8nは、実行回数やステップ数を気にせず、自分のサーバーで自動化を動かせるツールです。今回の構成は、実際に動かしてメモリは400〜570MB程度でした。メモリ2GBのVPSで、余裕を持って運用できます。

1. n8n・タスクランナー・PostgreSQL・Caddyの4つをDocker Composeで動かす
2. 起動したら、すぐにオーナーアカウントを作る
3. 秘密の値は認証情報に保存し、ワークフローは「Publish」で公開する
4. データベース・n8n_data・.envの3つを毎日バックアップする
5. 「docker compose down -v」は使わない

一方で、アップデートやバックアップは自分で続ける必要があります。サーバーの管理に手をかけたくない場合は、ZapierやMake、n8n Cloudを選ぶのも正解です。

シンVPSの料金・プランを見る（PR）

n8nの必要スペックやおすすめのVPSはn8nの詳細ページで、ほかの自動化ツールはZapierの代替ツール一覧で比較できます。Zapierから乗り換えた場合にいくら節約できるかは、節約額シミュレーターで試算できます。

参考にした公式情報

• n8n：使い方の選び方（クラウド版とセルフホスト）
• n8n-hosting：PostgreSQLとタスクランナーを使う構成例
• n8n：タスクランナーの設定
• n8n：リバースプロキシの後ろでのWebhook URLの設定
• n8n：バックアップと復元
• n8n：アップデート
• n8n：3.0の破壊的変更
• n8n：ライセンスのFAQ