n8n Docker セルフホスト完全手順｜コピペで動く3ファイルと3ヶ月運用の実数値【2026年版】

記事内に広告を含みます

この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。

n8n Docker セルフホスト｜必要なのは3ファイルと10分です
なぜ n8n を Docker でセルフホストするのか（クラウド／npm 直ではなく）
- Zapier 月 vs VPS 月600円 ── コスト主権の中身
- Docker を選ぶ理由（npm 直インストールではなく）
n8n Docker 構築の前提条件
コピペで動く設定ファイル一式（docker-compose.yml / .env / Caddyfile）
まずローカルで試す最小構成（ドメイン・SSL 不要 / localhost:5678）
- ローカル構成と本番 VPS 構成の差分
n8n Docker の各設定の解説 ── なぜこの値なのか
n8n の起動と初期設定（DNS → docker compose up -d → アカウント作成）
Dockerfile で n8n を拡張する（独自パッケージ・依存を足したいとき）
- 公式イメージで大半は足りる｜拡張が要る時だけ Dockerfile
- FROM docker.n8n.io/n8nio/n8n を拡張する最小例
n8n を Docker で3ヶ月運用して分かったこと（実数値）
n8n Docker セルフホストのトラブルシューティング（遭遇した4つ）
まとめ：サーバーが動いたら、次は何を自動化するか
あわせて読みたい
- n8nシリーズの他の記事
Git/Claude Code 使い込んでる人ほど、止まりがちです。

n8n Docker セルフホスト｜必要なのは3ファイルと10分です

n8n を Docker でセルフホストするのに必要なのは、docker-compose.yml / .env / Caddyfile の3ファイルだけです。VPS にコピペして docker compose up -d を打てば、SSL 付きで10〜30分で立ち上がります。月500〜600円で、Zapier や n8n クラウドの月額課金から降りられます。

この記事では、その3ファイルをコピペでそのまま動く形で全文載せます。あわせて、先回りで潰しておきたい n8n 固有の地雷（DB_TYPE の選択ミス、ENCRYPTION_KEY 消失で全クレデンシャルが復号不能になる事故など）と、Hetzner の VPS で n8n を3ヶ月運用して出た実数値（CPU・メモリ・ディスク）まで、必要な情報を1箇所にまとめました。2026年5月時点・n8n v2 系の記録です。

「Docker でサーバーに常駐させるのは、なんとなく怖い」と手が止まる気持ちも分かります。n8nとは何か（読み方・Zapierとの違い）まで調べて VPS も契約できるのに、いざ構築となると Qiita や Zenn の設定例が記事ごとに違っていて迷う——半年前の私もそうで、最初に半日溶かしました。でも詰まりの正体は Docker の難しさではなく、情報が散らばっていることでした。だから、この1本で完結させます。

なぜ n8n を Docker でセルフホストするのか（クラウド／npm 直ではなく）

手順に入る前に、3つの「ほんとにこれでいいの？」に先に答えておきます。私自身が構築前に引っかかった疑問でもあります。

Zapier 月$30 vs VPS 月600円 ── コスト主権の中身

Zapier は使った分だけ課金が増える従量制で、月$20〜$50。n8n クラウド版も月額がかかります。一方、n8n をセルフホストすると、かかるのは VPS 代だけ。

	Zapier / n8n クラウド	n8n セルフホスト（Docker）
月額	$20〜$50（従量・増える）	VPS 代のみ月500〜600円（固定）
実行回数	プランごとに上限	無制限
ワークフロー数	プランごとに上限	無制限
データの置き場所	相手のサーバー	自分のサーバー
運用の手間	ほぼゼロ	初回構築 + 月数分のメンテ

ぶっちゃけ、ここで本当に欲しいのは「安いこと」そのものより、従量課金から降りて、自分で全部握る側に回るという主導権なんですよね。実行回数を気にしながらワークフローを5つに絞る、あの感覚から解放される。クラウド版を全否定するつもりはありません。手間ゼロで使えるのは大きな価値です。ただ、毎月の課金と「全部自分で握れる自由」を天秤にかけて、後者を選ぶ人のための記事です。

Docker を選ぶ理由（npm 直インストールではなく）

「Docker じゃなくて npm で直に入れちゃダメなの？」とよく聞かれます。動くには動きます。ただ、私が Docker を選ぶ理由は3つです。

依存関係を閉じ込められる ── Node.js のバージョンや PostgreSQL をホスト OS に直接入れると、後で別のものを入れたときに衝突します。Docker なら n8n の世界がコンテナの中に閉じます。
アップデートが2コマンド ── docker compose pull && docker compose up -d で終わり。npm 直だと依存の更新で詰まることがあります。
DB 込みで再現可能 ── 設定ファイルさえあれば、別の VPS でもまったく同じ環境がもう一度立ちます。引っ越しが怖くなくなる。

「Docker は難しそう」というイメージがあるかもしれませんが、この記事でやるのは設定ファイルを3つ置いて1コマンド打つだけ。怖さの大半は、やってみると拍子抜けします。

n8n Docker 構築の前提条件

走り出す前に、必要なものをはっきりさせておきます。ここが曖昧なまま始めると、途中で「あれが足りない」と止まるので。

項目	条件
VPS	Ubuntu 22.04以降（Debian系でもOK）
スペック	最低1 vCPU / 2 GB RAM / 20 GB SSD
ドメイン	自分のドメインがあり、DNSのAレコードを設定できる
Docker	Docker EngineとDocker Composeが入っている

VPS はどこでも構いません。コマンドラインの操作に不安があるなら、日本語の管理画面で完結するConoHa VPSの2GBプランあたりが入りやすいです（このリンクはアフィリエイトリンクです）。

私自身は Hetzner の CX22（EUR 3.79/月、約600円）で運用しています。2 vCPU、4 GB RAM、40 GB NVMe SSD。n8n には十分すぎるスペックです。海外 VPS で英語の管理画面に抵抗がなければ、コスパは頭一つ抜けています。

Docker がまだ入っていない場合は、公式のインストールスクリプトで一発です。Docker の仕組み自体に不安がある人は、超初心者向けの Docker 基礎を先に読んでおくと、これから打つコマンドの意味が腑に落ちます。

bash

# Docker公式のインストールスクリプト（Ubuntu）

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

sudo usermod -aG docker $USER

2行目を実行したら、いったんログアウトして入り直してください。これで docker コマンドを sudo なしで打てるようになります。

コピペで動く設定ファイル一式（docker-compose.yml / .env / Caddyfile）

ここが核です。散らばった設定例を比べて消耗するくらいなら、3ヶ月動いている1セットをそのまま使ってください。

以下の3ファイルを VPS 上の同じディレクトリに置きます。

ディレクトリ構成

/opt/n8n/

├── docker-compose.yml

├── .env

└── caddy_config/

└── Caddyfile

まず作業ディレクトリを作ります。

bash

sudo mkdir -p /opt/n8n/caddy_config

cd /opt/n8n

docker-compose.yml 全文（n8n + PostgreSQL + Caddy）

yaml

services:

postgres:

image: postgres:16-alpine

restart: unless-stopped

environment:

- POSTGRES_USER=${POSTGRES_USER}

- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

- POSTGRES_DB=${POSTGRES_DB}

volumes:

- postgres_data:/var/lib/postgresql/data

healthcheck:

test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]

interval: 10s

timeout: 5s

retries: 5

shm_size: 128mb

n8n:

image: docker.n8n.io/n8nio/n8n

restart: always

depends_on:

postgres:

condition: service_healthy

environment:

- 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_HOST=${SUBDOMAIN}.${DOMAIN_NAME}

- N8N_PORT=5678

- N8N_PROTOCOL=https

- NODE_ENV=production

- WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/

- GENERIC_TIMEZONE=${GENERIC_TIMEZONE}

- TZ=${TZ}

- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

- EXECUTIONS_DATA_PRUNE=true

- EXECUTIONS_DATA_MAX_AGE=168

- N8N_DEFAULT_BINARY_DATA_MODE=filesystem

- N8N_DIAGNOSTICS_ENABLED=false

volumes:

- n8n_data:/home/node/.n8n

- ${DATA_FOLDER}/local_files:/files

caddy:

image: caddy:latest

restart: unless-stopped

ports:

- "80:80"

- "443:443"

environment:

- SSL_EMAIL=${SSL_EMAIL}

- SUBDOMAIN=${SUBDOMAIN}

- DOMAIN_NAME=${DOMAIN_NAME}

volumes:

- caddy_data:/data

- ${DATA_FOLDER}/caddy_config:/config

- ${DATA_FOLDER}/caddy_config/Caddyfile:/etc/caddy/Caddyfile

volumes:

postgres_data:

n8n_data:

caddy_data:

20行ちょっとの YAML に見えますが、これだけで n8n + データベース + SSL 付きリバースプロキシが揃います。各サービスのインデント（字下げ）だけは崩さないよう注意してください。YAML はインデントで構造が決まるので、ここがズレると起動しません。

.env 全文（パスワード・ENCRYPTION_KEY 生成コマンド込み）

bash

POSTGRES_USER=n8n

POSTGRES_PASSWORD=ここに強力なパスワードを入れる

POSTGRES_DB=n8n

DATA_FOLDER=/opt/n8n

DOMAIN_NAME=example.com

SUBDOMAIN=n8n

SSL_EMAIL=your-email@example.com

GENERIC_TIMEZONE=Asia/Tokyo

TZ=Asia/Tokyo

N8N_ENCRYPTION_KEY=ここに64文字のランダム文字列を入れる

パスワードと暗号化キーは、以下のコマンドで生成できます。

bash

# パスワード生成（32文字）

openssl rand -base64 32

# 暗号化キー生成（64文字）

openssl rand -hex 32

DOMAIN_NAME と SUBDOMAIN は自分の環境に合わせて書き換えてください。n8n.example.com でアクセスする想定です。生成した N8N_ENCRYPTION_KEY は、この後で説明する理由から、必ずどこか安全な場所に控えておいてください。

Caddyfile 全文（7行で SSL 自動取得）

{

email {$SSL_EMAIL}

}

{$SUBDOMAIN}.{$DOMAIN_NAME} {

reverse_proxy n8n:5678 {

flush_interval -1

}

}

たった7行。でもこれだけで SSL 証明書の自動取得と自動更新が動きます。Nginx で同じことをやろうとすると、certbot の設定で倍の手間がかかります。Caddy を選ぶ理由はここです。

そして flush_interval -1。これは見落としがちですが、入れておかないと長時間実行するワークフローの途中で接続が切れます。n8n 固有の罠なので、忘れずに入れてください。詳しくは後の「各設定の解説」で触れます。

まずローカルで試す最小構成（ドメイン・SSL 不要 / localhost:5678）

「いきなり VPS は怖い。まず自分の Mac や Windows で n8n を触ってみたいだけ」── これも正解です。私も最初の感触を掴んだのはローカルでした。

ローカルで試すなら、ドメインも SSL も要りません。Caddy を抜いて、n8n と PostgreSQL の2つだけ立てれば、http://localhost:5678 で開けます。Docker Desktop（Mac / Windows）か Docker Engine が入っていれば動きます。これが n8n のいちばん簡単なインストール方法です。

yaml

# docker-compose.yml（ローカル最小構成 / Caddy なし）

services:

postgres:

image: postgres:16-alpine

restart: unless-stopped

environment:

- POSTGRES_USER=n8n

- POSTGRES_PASSWORD=localpassword

- POSTGRES_DB=n8n

volumes:

- postgres_data:/var/lib/postgresql/data

n8n:

image: docker.n8n.io/n8nio/n8n

restart: unless-stopped

ports:

- "5678:5678"

depends_on:

- postgres

environment:

- DB_TYPE=postgresdb

- DB_POSTGRESDB_HOST=postgres

- DB_POSTGRESDB_DATABASE=n8n

- DB_POSTGRESDB_USER=n8n

- DB_POSTGRESDB_PASSWORD=localpassword

- N8N_SECURE_COOKIE=false

volumes:

- n8n_data:/home/node/.n8n

volumes:

postgres_data:

n8n_data:

このファイルを置いたディレクトリで docker compose up -d を打って、ブラウザで http://localhost:5678 を開くだけ。N8N_SECURE_COOKIE=false は、SSL なし（http）でログイン画面を出すために必要です。本番ではこの行は不要です（https になるので）。

ローカル構成と本番 VPS 構成の差分

	ローカル（お試し）	本番 VPS
Caddy（SSL）	なし	あり（https 自動）
アクセス先	http://localhost:5678	https://n8n.example.com
ドメイン / DNS	不要	必要（A レコード1本）
N8N_SECURE_COOKIE	false	設定不要（既定 true）
Webhook の到達	外部から届かない	届く
用途	触って慣れる	常時稼働・自動化の実運用

ローカルは「触って慣れる」用です。Webhook（外部サービスからの通知）を受け取る自動化を本格的に組むなら、結局は外から届く本番 VPS が要ります。ローカルで操作感を掴んだら、上の本番3ファイルに進んでください。やることはほぼ同じで、Caddy とドメインが足されるだけです。

n8n Docker の各設定の解説 ── なぜこの値なのか

YAML 全体をコピペすれば動きます。でも「なぜこの設定なのか」を知っておくと、トラブルが起きたとき自分で対処できます。ここは、私が3ヶ月の間に踏んだ／人が踏むのを見た地雷を、先回りで潰すパートです。

DB_TYPE=postgresdb（最多の設定ミス・1時間ハマる罠）

ここ、いちばん多い設定ミスです。

postgres ではなく postgresdb。n8n 独自の命名規則なので、一般的な Docker Compose の感覚で postgres と書くと接続エラーになります。これだけで1時間ハマった人を、私は何人か見ています。コピペしていれば踏みませんが、自分で書き換えるときは要注意です。

N8N_ENCRYPTION_KEY（失うと全クレデンシャル復号不能）

n8n はワークフロー内の API キーやパスワードを暗号化して保存します。この鍵を紛失すると、保存済みのクレデンシャルがすべて復号不可能になります。つまり、全ての外部サービス接続を最初からやり直しです。

これは脅しではなく、実際に起きます。VPS を作り直したときに .env を控えていなければ、それまで繋いだ Slack も Google も Notion も、全部もう一度認証し直しになる。.env ファイルのバックアップは、何よりも先に取っておいてください。

EXECUTIONS_DATA_PRUNE / MAX_AGE（DB 肥大化防止）

実行ログを168時間（7日）で自動削除する設定です。これがないと、データベースが際限なく肥大化します。毎分動くワークフローを放っておくと、数週間でディスクを食い潰しかねません。個人用途なら7日で十分です。

N8N_DEFAULT_BINARY_DATA_MODE=filesystem（2 GB RAM の OOM 回避）

画像や PDF などのバイナリデータを、データベースではなくファイルシステムに保存する設定です。メモリ消費を大幅に抑えられるので、2 GB RAM の VPS では必須です。これを入れずに PDF 生成を回したら、メモリが足りずに OOM Killer に n8n を殺されたことがあります。低スペック VPS で動かす人は、この1行が効きます。

Caddyfile の flush_interval -1（長時間ワークフローで接続が切れる罠）

先ほどの Caddyfile に出てきた1行です。リバースプロキシは普通、レスポンスをある程度バッファしてから流します。ところが n8n は実行中の進捗をストリーミングで返すため、バッファされると長時間ワークフローの途中で接続が切れたように見えます。flush_interval -1 はバッファせず即座に流す指定。これも踏むまで誰も教えてくれない、n8n 固有の地雷です。

n8n の起動と初期設定（DNS → docker compose up -d → アカウント作成）

ここまで準備できたら、あとは3ステップです。慣れれば10分、初めてでも30分あれば終わります。

1. DNS を設定

ドメインの DNS 管理画面で、A レコードを1本追加します。これが「自分のサブドメインを VPS に向ける」設定です。

タイプ: A

名前: n8n（サブドメイン）

値: VPSのIPアドレス

TTL: 300

2. 起動

bash

cd /opt/n8n

docker compose up -d

初回はイメージのダウンロードがあるので2〜3分かかります。

bash

# ログを確認

docker compose logs -f

PostgreSQL のヘルスチェックが通り、n8n が Editor is now accessible via: https://n8n.example.com と表示されたら成功です。この一行が出た瞬間が、いちばん「越えた」と感じる瞬間でした。

3. ブラウザでアクセス

https://n8n.example.com を開きます。初回はオーナーアカウントの作成画面が表示されるので、メールアドレスとパスワードを設定すれば n8n のダッシュボードに入れます。

立ち上がった直後、UI が全部英語で少し戸惑うかもしれません。日本語にしたい場合はn8n の UI を日本語化する方法（セルフホスト版）でまとめています。立てた直後の自然な次の一歩です。

Dockerfile で n8n を拡張する（独自パッケージ・依存を足したいとき）

ここから先は、最初は読み飛ばして構いません。まず動かすことが先です。

公式イメージで大半は足りる｜拡張が要る時だけ Dockerfile

結論から言うと、9割の人は公式イメージ（docker.n8n.io/n8nio/n8n）のままで足ります。私自身、3ヶ月のうち独自 Dockerfile が必要になった場面は限られていました。

Dockerfile を書く必要が出るのは、次のようなケースです。

Code ノードで使う npm パッケージを足したい（例: 独自の日付処理ライブラリ、画像処理）
システム依存のコマンドを使いたい（例: ffmpeg で動画変換、imagemagick で画像加工）
フォントやロケールを追加したい（PDF 生成で日本語が豆腐になるとき）

逆に言えば、上のどれにも当てはまらないなら Dockerfile は不要です。判断軸はシンプルで、「公式イメージで動かない壁にぶつかってから書く」。先回りで凝ったイメージを作ると、アップデートのたびに自分で追従する手間が増えます。

FROM docker.n8n.io/n8nio/n8n を拡張する最小例

例として、ffmpeg と独自 npm パッケージを足した Dockerfile です。公式イメージを土台（FROM）にして、必要なものだけ上乗せします。

dockerfile

# Dockerfile

# 公式イメージを土台にする

FROM docker.n8n.io/n8nio/n8n

# root に切り替えてシステム依存を入れる

USER root

RUN apk add --no-cache ffmpeg

# Code ノードで使う npm パッケージを追加

RUN npm install -g moment lodash

# n8n の実行ユーザー（node）に戻す

USER node

n8n の公式イメージは Alpine Linux ベースなので、システムパッケージは apk add で入れます（Debian 系の apt ではありません）。最後に USER node で実行ユーザーを戻すのを忘れないでください。root のまま動かすと、先ほどのパーミッション周りで余計なトラブルを呼びます。

あとは docker-compose.yml の n8n サービスで、image: を build: . に差し替えるだけです。

yaml

n8n:

# image: docker.n8n.io/n8nio/n8n   ← これをコメントアウト

build: .   ← 同じディレクトリの Dockerfile からビルド

# 以下はそのまま

これで docker compose up -d --build すると、拡張したイメージで n8n が立ち上がります。なお、Dockerfile で立てた n8n を AI ツールの一部として外から叩きたくなったら、n8n を MCP サーバー化して Claude Desktop から叩く方法が次の発展先です。

n8n を Docker で3ヶ月運用して分かったこと（実数値）

「構築できた」と「安定運用できている」の間には、けっこう距離があります。ここからが、公式ドキュメントにも Qiita にも載っていない、私の N=1 の運用記録です。

結論から言うと、拍子抜けするほど安定していました。あれだけ「壊したらどうしよう」と怖がっていたのが何だったのか、というくらいに。

実リソース消費（CPU 2〜5% / メモリ 800MB〜1.2GB / ディスク 3GB）

Hetzner の CX22（2 vCPU / 4 GB RAM）で、n8n + PostgreSQL + Caddy の3コンテナを動かした、2026年5月時点・3ヶ月分の実測値です。

CPU使用率: 平均2〜5%

メモリ使用量: 約800MB〜1.2GB

ディスク使用量: 約3GB（ログ自動削除あり）

ワークフローが10個程度なら、1 vCPU / 2 GB RAM でも問題なく動くと思います。あくまで私の環境（ワークフロー10個前後、画像・PDF 処理を時々）での話ですが、想像していた負荷の10分の1でした。

ただし前述のとおり、メモリ2 GB ギリギリでバイナリ処理（PDF 生成など）を回すと OOM Killer に殺されることがあります。N8N_DEFAULT_BINARY_DATA_MODE=filesystem は必ず設定してください。

バックアップを作ったのは構築2週間後だった話

正直に白状すると、バックアップの仕組みを作ったのは構築から2週間後でした。

その間にワークフローを10個作り込んでから、ふと「これ、消えたら全部終わりだな」と気づいて青ざめた。本来は最初の日に設定すべきものです。同じ轍を踏まないよう、起動できたらすぐ入れてください。週1の cron で十分です。

bash

# /opt/n8n/backup.sh

#!/bin/bash

docker compose -f /opt/n8n/docker-compose.yml exec -T postgres pg_dump -U n8n n8n | gzip > /opt/n8n/backups/n8n-db-$(date +%Y%m%d).sql.gz

# 30日以上古いバックアップを削除

find /opt/n8n/backups -name "*.sql.gz" -mtime +30 -delete

bash

# crontab -e で追加

0 3 * * 0 /opt/n8n/backup.sh

毎週日曜3時にバックアップを取り、30日で古いものを削除。DB に加えて .env（あの暗号化キー！）もどこか別の場所に控えておけば、VPS が吹き飛んでも復旧できます。

アップデートは2コマンド（pull && up -d）

bash

cd /opt/n8n

docker compose pull && docker compose up -d

これだけ。ダウンタイムは数秒です。Docker の更新の手軽さを実感するのがこの瞬間でした。

ただし、メジャーアップデート（1.x → 2.x など）の場合はリリースノートを必ず確認してください。DB マイグレーションが含まれることがあり、そのときはバックアップを取ってから上げるのが安全です。

n8n Docker セルフホストのトラブルシューティング（遭遇した4つ）

3ヶ月の間に遭遇した（または相談された）トラブルを4つまとめます。エラーメッセージで検索してここに辿り着いた人は、該当箇所だけ読んでください。

DB 接続エラー（ECONNREFUSED 5432 = DB_TYPE ミス）

ERROR: connect ECONNREFUSED 127.0.0.1:5432

99%の原因は DB_TYPE の設定ミスです。

bash

# docker-compose.yml の environment を確認

# ❌ DB_TYPE=postgres

# ✅ DB_TYPE=postgresdb

本記事の YAML では docker-compose.yml 内に直接 DB_TYPE=postgresdb と書いているので、コピペしていれば発生しません。

SSL 取得失敗（DNS 未伝播・80/443 未開放）

ERROR: challenge failed: ACME challenge not completed

確認ポイントは2つ。

DNS: A レコードが正しく設定され、伝播しているか（dig n8n.example.com で確認。設定直後は数分〜数十分かかることがあります）
ポート: VPS のファイアウォールで80番と443番が開いているか

bash

# ポート確認

sudo ufw status

# 開いていなければ

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

パーミッションエラー（UID 1000）

Error: EACCES: permission denied

n8n コンテナは UID 1000 で動作します。マウントしたフォルダのオーナーを合わせてください。

bash

sudo chown -R 1000:1000 /opt/n8n/local_files

Webhook 不達（WEBHOOK_URL の http・末尾スラッシュ）

外部サービスからの Webhook が届かない場合、.env の WEBHOOK_URL を確認してください。地味ですが、私が一番無駄に時間を使ったのがここでした。

bash

# ❌ よくある間違い

WEBHOOK_URL=http://n8n.example.com/ # httpになっている

WEBHOOK_URL=https://n8n.example.com # 末尾スラッシュがない

# ✅ 正しい

WEBHOOK_URL=https://n8n.example.com/

まとめ：サーバーが動いたら、次は何を自動化するか

ここまでの手順で、VPS 上に n8n の Docker セルフホスト環境が動いているはずです。振り返ると、必要だったのは3つのファイルだけでした。

docker-compose.yml — n8n + PostgreSQL + Caddy の3サービス定義
.env — パスワード、ドメイン、暗号化キーの設定
Caddyfile — SSL 自動化のリバースプロキシ設定

あれだけ「Docker でサーバーに常駐させるのが怖い」と思っていたのに、越えてみたら拍子抜けでした。月500〜600円の VPS 代だけで、ノード数もワークフロー数も制限なし。Zapier の無料プランで5つのワークフローに悩んでいたのが嘘みたいです。月額課金の従量制から、自分で全部握る側に回れた。

サーバーが動いたら、次は「何を組むか」です。使い方の第一歩はn8n の使い方・初回ワークフローの組み方で、30分で最初のワークフローまで進めます。「そもそも何を自動化すればいいのか分からない」なら、n8n で何を自動化すればいいか（日々の観察から見つける）が、自動化のタネの見つけ方の話です。

n8n 以外の選択肢もまだ迷っているなら、AI 自動化ツールの全体像（n8n・Dify・Make 比較）でツールの選び方を整理しています。

ぶっちゃけ、セルフホストの自由度を一度知ってしまうと、もう従量課金には戻れません。参考になれば幸いです。