n8nをセルフホストする方法|無料の範囲とDocker手順【2026年版】
業務自動化ツール「n8n(エヌ・エイト・エヌ)」は、自分のサーバーで動かす「セルフホスト」ならソフト代0円で使えます。n8n 社が運営するクラウド版(n8n Cloud)は月の実行回数で料金が決まるので、たくさん動かすほどセルフホストの方が割安になりやすい——というのが人気の理由です。
ただし「無料」には条件があります。ライセンス(Sustainable Use License)で使い方が決まっていること、更新・バックアップ・認証は自分の仕事になることです。

この記事では、n8n のセルフホストを Docker Compose で構築する手順、Webhook を外から受け取る設定、バックアップと認証、無料でできる範囲とライセンス、n8n Cloud との料金の違いを、2026年11月13日時点の公式情報で整理します。テスト用の Linux 環境(Docker)で実際に n8n をセットアップしたときの画面と、つまずいた所も載せます。
この記事はこんな人向けです
- 業務自動化ツール n8n を、自分の VPS などで無料で動かしたい
- Docker Compose での構築・Webhook・バックアップ・認証の設定をまとめて知りたい
- n8n Cloud とセルフホストで、料金やできることがどう違うのかを比べたい
n8nのセルフホストとは?一言でまとめると
n8n のソフトを自分の VPS などに入れて、自分で運用することです。n8n Cloud との違いは「誰がサーバーを持ち、誰が面倒を見るか」にあります。
| 比べる点 | n8n Cloud | セルフホスト(Community edition) |
|---|---|---|
| サーバー | n8n 社が用意 | 自分で用意(VPS など) |
| ソフトの料金 | 月額制(Starter 年払いで月$20〜) | 無料 |
| 料金の決まり方 | 月の実行回数 | サーバー代だけ |
| 更新・バックアップ | n8n 社 | 自分 |
| 始めるまで | 登録してすぐ | Docker・ドメイン・SSL の準備が要る |
| 向いている人 | サーバーを触りたくない人 | Docker とサーバーの更新を自分でできる人 |
※ 2026年11月13日時点(n8n「Pricing」「Choose how to use n8n」)。

n8n の公式ドキュメントは、セルフホストをサーバーやコンテナの扱いに慣れた人向けと位置づけ、慣れていない人には n8n Cloud をすすめています。設定を間違えると、データの消失や情報漏えいにつながるからです。この記事では、その「自分でやること」を一つずつ具体的にしていきます。
なお、国内 VPS の n8n 用アプリイメージを使えば、Docker の知識がなくても始められます。プランの選び方と始め方はこちらで解説しています。

無料でできる範囲:Community editionとライセンス
セルフホストの n8n は、ライセンスキーなしで動かすと Community edition(無料) になります。ほぼすべての機能が入っていますが、チームで使う機能を中心に、いくつかは有料プラン(Business・Enterprise)向けです。
| 機能 | Community(無料) | 登録した Community(無料) | Business(有料) |
|---|---|---|---|
| ワークフロー・ノード・Webhook | ○ | ○ | ○ |
| ユーザー数・ワークフロー数 | 無制限 | 無制限 | 無制限 |
| フォルダ・Debug in editor | × | ○ | ○ |
| Projects(プロジェクトごとの権限) | × | × | ○ |
| ワークフロー・認証情報の共有 | × | × | ○ |
| SSO(SAML・LDAP) | × | × | ○ |
| Git でのバージョン管理・Environments | × | × | ○ |
| Queue mode(処理の分散) | ○ | ○ | ○ |
※ 2026年11月13日時点(n8n Docs「Compare editions」、n8n「Pricing」)。登録した Community は、メールアドレスを登録して受け取る無料のライセンスキーで有効になります。

1人で使う、または少人数でも「作る人は1人」なら、Community edition で十分なケースがほとんどです。共有ができないので、Community ではワークフローと認証情報を見られるのはオーナーと作った本人だけになります。
① ライセンスは「オープンソース」ではない
n8n のソースコードは GitHub で公開されていますが、ライセンスは n8n 社が2022年に作った Sustainable Use License(SUL) です。OSI(オープンソースの定義を決めている団体)の基準ではオープンソースに当たらず、n8n 自身は「fair-code」と呼んでいます。ルールは次の3つです。
- 使う・改変するのは、自社の内部の業務か、非商用・個人の利用に限る
- 人に配る・提供するのは、非商用で無料の場合だけ
- ライセンスや著作権の表示を消さない
② できること・できないこと
判断の目安は「ワークフローを作る・直すのが自社の人だけかどうか」です。公式の FAQ の例を、よくある使い方に当てはめて並べ直すと次のようになります。
| 使い方 | SUL(無料)で |
|---|---|
| 自社の業務を自動化する | ○ |
| 個人のプロジェクト・学習・研究 | ○ |
| 顧客向けの自動化を自分の n8n で作る(顧客は編集しない) | ○ |
| ワークフローの作成・保守・研修を有料で請け負う | ○ |
| 自社サービスの裏側で n8n を動かす(利用者は n8n を触らない) | ○ |
| n8n を複数台動かす | ○ |
| 顧客が自分でワークフローを作れるサービスとして提供する | ×(UI・API・MCP・AI エージェント経由でも同じ) |
| n8n をフォークして自分の自動化製品を出す | × |
| ロゴを消してホワイトラベルで提供する | × |
※ 2026年11月13日時点(n8n Docs「License FAQ」「Community license」)。迷う場合は n8n(license@n8n.io)に確認するよう案内されています。
ブログ運営やネットショップの裏側の自動化、受託でワークフローを作る仕事は無料の範囲です。一方で「n8n を使った自動化サービス」を売るなら、Enterprise などの商用契約が必要になります。
n8n Cloudとセルフホストの料金を比べる
n8n Cloud は、月に何回ワークフローを実行するかでプランが決まります。1回の実行は「ワークフロー全体を最初から最後まで1回動かすこと」で、途中のステップ数は数えません。
| プラン | 年払い(月額) | 月払い(月額) | 月の実行回数 | 動く場所 |
|---|---|---|---|---|
| Starter | $20 | $24 | 2,500回 | Cloud |
| Pro | $50 | $60 | 10,000回 | Cloud |
| Business | $800 | $960 | 40,000回 | セルフホストだけ |
| Enterprise | 要問い合わせ | 要問い合わせ | 個別 | Cloud・セルフホスト |
| Community | 無料 | 無料 | 料金に関係しない | セルフホスト |
※ 2026年11月13日時点(n8n「Pricing」のドル表示)。表示の通貨は地域で変わり、ユーロ表示では Starter €20・Pro €50・Business €667(いずれも年払いの月額)でした。


① 実行回数で考えると差が大きい
公式の料金ページの FAQ でも例に挙がっているとおり、5分ごとに動くワークフローは1本で月に約8,600〜8,900回実行されます。これだけで Starter(2,500回)を超え、Pro(10,000回)でもほぼ埋まります。
セルフホストの Community edition なら、実行回数で料金は増えません。定期実行を何本も回したい人ほど、セルフホストが有利です。
② セルフホストにかかる本当のコスト
ソフトは無料でも、次の3つはかかります。
- サーバー代:VPS の月額(メモリ 2GB 前後のプランが目安。下の「必要なもの」を参照)
- ドメイン代:Webhook を外から受けるなら、n8n.example.com のようなサブドメインが必要
- 自分の作業時間:更新(公式は少なくとも月1回を推奨)・バックアップ・障害対応
「月$20〜$50 を払って手間をなくす」か「サーバー代+手間で回数を気にせず使う」か——この比較が Cloud とセルフホストの分かれ目です。
必要なもの:サーバーのスペックとドメイン
Docker Compose でセルフホストするときに用意するものを、公式の手順から抜き出しました。
| 必要なもの | 目安・内容 |
|---|---|
| サーバー | Linux の VPS(Docker が動くもの)。メモリは 2GB 前後から、AI 連携や大きなデータを扱うなら余裕を |
| ソフト | Docker Engine と Docker Compose v2 |
| ドメイン | サブドメイン(例:n8n.example.com)の A レコードをサーバーの IP に向ける |
| 開けるポート | 80(証明書の取得)・443(HTTPS)。5678 は外に開けない |
| メールアドレス | Let’s Encrypt の証明書の取得用 |
| データベース | 小さく始めるなら SQLite(既定)、人数が多い・常時稼働の本番なら PostgreSQL |
※ 2026年11月13日時点(n8n Docs「Use Docker Compose」「Install using Docker Compose」)。
n8n はワークフローで扱うデータの量や同時に動く数でメモリを使います。OS や Traefik も同じサーバーに載るので、2GB あると安心です(待機中の実際の使用量は、後半の「実際にセットアップしてみた」に載せています)。
注意したいのは、n8n の AI アシスタント(n8n Assistant)用のサンドボックスつきの構成です。こちらは公式にメモリ4GB以上・2 vCPUが必要とされ、サンドボックスは特権モードで動くためほかに何も載せない専用のサーバーでと注意書きがあります。まずは n8n 本体だけで始めるのがおすすめです。
VPS の選び方や、レンタルサーバーとの違いはこちらで整理しています。

Docker Composeで構築する手順
公式の「Use Docker Compose」の手順を、6つのステップにまとめました。Traefik(トラフィック)というリバースプロキシが、SSL 証明書の取得と更新を自動でしてくれる構成です。

① Docker と Docker Compose を入れる
Linux のディストリビューションごとの手順で Docker Engine と Compose を入れ、次のコマンドで確認します。
ターミナル(VPS)
docker --version
docker compose version
② サブドメインをサーバーに向ける
DNS の管理画面で、A レコード(名前 n8n、値はサーバーの IP アドレス)を追加します。
③ .env に自分の情報を書く
作業用のフォルダを作り、その中に .env を置きます。
ターミナル(VPS)
mkdir n8n-compose
cd n8n-compose
.env
DOMAIN_NAME=example.com
SUBDOMAIN=n8n
GENERIC_TIMEZONE=Asia/Tokyo
SSL_EMAIL=user@example.com
GENERIC_TIMEZONE は Asia/Tokyo にしておくのがポイントです。設定しないと、スケジュール実行の時刻がアメリカ東部時間(既定)で動きます。
④ local-files を作り、持ち主を合わせる
ホストと n8n でファイルをやり取りするフォルダを作ります。
ターミナル(VPS)
mkdir local-files
sudo chown 1000:1000 local-files
公式の手順は mkdir だけですが、root で作ると n8n から書き込めません(コンテナの中の n8n は uid 1000(node ユーザー)で動くため)。実際にバックアップの書き出しが「EACCES: permission denied」で失敗した様子は、下の「実際にセットアップしてみた」に載せています。
⑤ compose.yaml を書いて起動する
公式の compose.yaml は、Traefik(80・443 を受けて証明書を管理)と n8n(127.0.0.1:5678 だけで待ち受け)の2つのコンテナからなります。n8n 側の主な設定は次のとおりです。
| 設定 | 値 | 意味 |
|---|---|---|
| image | n8nio/n8n | 公式イメージ(安定版) |
| ports | 127.0.0.1:5678:5678 | 外から直接は入れない(Traefik 経由だけ) |
| N8N_HOST / N8N_PROTOCOL | n8n.example.com / https | 公開するアドレス |
| N8N_WEBHOOK_URL | https://n8n.example.com/ | Webhook の URL(次の節) |
| NODE_ENV | production | 本番モード |
| N8N_RESTRICT_FILE_ACCESS_TO | /files | ファイル操作を /files の中だけに |
| volumes | n8n_data:/home/node/.n8n | データベースと暗号化キー |
※ 2026年11月13日時点(n8n Docs「Use Docker Compose」)。compose.yaml の全文は公式ページからコピーしてください。
書けたら起動します。
ターミナル(VPS)
sudo docker compose up -d
⑥ ブラウザで開いてオーナーを作る
https://n8n.example.com を開くと、最初の管理者(オーナー)アカウントの作成画面が出ます。ここで作るのは自分の n8n の中だけのアカウントで、n8n Cloud への登録ではありません。パスワードは 8文字以上・数字と大文字を1つ以上が条件です。
手元のテスト環境で実際に起動・初期設定したときの画面とつまずいた所は、下の「実際にセットアップしてみた」にまとめています。
この手順で公開した n8n は HTTPS でだけアクセスできます。つながらないときは、サーバーのファイアウォール(80・443 が開いているか)と DNS の設定を見直します。
Dify など、ほかの AI ツールを VPS で動かす方法はこちらで比べています。

Webhookを外部から受け取る設定
n8n の Webhook ノードは、フォーム・決済・GitHub などのサービスから届いたデータでワークフローを動かす入り口です。セルフホストで一番つまずきやすいのがここなので、3つに分けて説明します。

① テスト用 URL と本番用 URL の違い
Webhook ノードには URL が2つあります。
| テスト用 URL | 本番用 URL | |
|---|---|---|
| パス | /webhook-test/〜 | /webhook/〜 |
| 受け付ける時 | 「Listen for test event」を押してから 120秒 | ワークフローを公開(Publish)している間 |
| 届いたデータ | エディタにそのまま表示 | Executions タブで見る |
| 使う場面 | 作りながら試す | 外部サービスに登録する |
※ 2026年11月13日時点(n8n Docs「Webhook」「Workflow development」)。
外部サービスに登録するのは本番用 URLです。テスト用 URL を登録したままにすると、待ち受けていない間は「登録されていない」というエラー(404)が返ります。
② N8N_WEBHOOK_URL を必ず設定する
n8n は、Webhook の URL を「プロトコル+ホスト名+ポート」から組み立てます。Traefik のようなリバースプロキシの裏で動かすと、中の 5678 番をもとに URL を作ってしまい、外から届かない URL が表示されます。
そこで、N8N_WEBHOOK_URL に外から見える URL(https://n8n.example.com/)を設定します。あわせて N8N_PROXY_HOPS=1 を設定し、プロキシで X-Forwarded-For・X-Forwarded-Host・X-Forwarded-Proto のヘッダーを渡します。
古い記事でよく見る WEBHOOK_URL は、n8n 2.35.0 から非推奨です。N8N_WEBHOOK_URL は 2.30.0 から使えるので、今から構築するならこちらを使います。
③ Webhook に認証を付ける
本番用 URL は、URL を知っている人なら誰でも叩けます。Webhook ノードの「Authentication」で認証を付けるのが基本です。
| 方式 | 仕組み | 向いている場面 |
|---|---|---|
| Header Auth | 決めたヘッダー(例:X-API-Key)の値が合うか | 送り手がヘッダーを付けられる API |
| Basic Auth | ユーザー名とパスワード | 古い仕組みのサービス |
| JWT Auth | 署名つきのトークン | トークンを発行できる送り手 |
| n8n User Auth(OAuth2) | n8n にログインした人だけ | 社内向けのボタン・ツール |
| None | 認証なし | テストだけ(本番では避ける) |
※ 2026年11月13日時点(n8n Docs「Webhook」)。受け取れるデータは既定で最大16MBで、N8N_PAYLOAD_SIZE_MAX で変えられます。
パスは既定でランダムな文字列になります。分かりやすい名前に変えるときほど、認証を付けておくと安心です。
認証とセキュリティの設定
Webhook のほかにも、セルフホストでは自分で締めるべき所がいくつかあります。公開前のチェックリストにまとめました。
| チェック | やること | 無料版で |
|---|---|---|
| 管理画面のログイン | オーナーのパスワードを強くする。ログイン画面は無効にできない(Basic auth での保護は 1.0 で廃止) | ○ |
| 2段階認証(2FA) | Settings → Profile & preferences → Enable 2FA。リカバリーコードを保存 | ○(全員への強制は Business 以上) |
| メール(SMTP) | 設定しないとパスワードを再設定できない。招待リンクは手で送れる | ○ |
| Webhook | 本番用 URL に Header Auth などの認証 | ○ |
| ポート | 80・443 だけ開け、5678 は外に開けない | ○ |
| メンバー | アカウントは信頼できる人にだけ発行する | ○ |
| 監査 | n8n audit で、認証のない Webhook や古いバージョンを確認 | ○ |
| 更新 | 月1回以上、リリースノートを見てから | ○ |
※ 2026年11月13日時点(n8n Docs「User management」「Require two-factor auth」「Manage security policies」「Run security audits」「Update n8n」)。
n8n は2026年10月に、ワークフローを作れるユーザーが悪用できる脆弱性をまとめて公開しました。内容と修正版は、冒頭のカードの記事で紹介しています。「アカウントを渡す相手を絞る」と「すぐ更新する」が一番効く対策です。
VPS 自体の初期設定(SSH の鍵認証・ファイアウォールなど)も忘れずに行います。

バックアップの方法:データの保存先とエクスポート
n8n のバックアップで一番大事なのは、「暗号化キー」も一緒に保存することです。n8n は認証情報(API キーなど)を暗号化してデータベースに入れていて、キーがないと復元しても認証情報を読めません。

① データの保存先:n8n_data ボリューム
Docker Compose の構成では、大事なデータはすべて n8n_data ボリューム(コンテナの中の /home/node/.n8n)にあります。
| ファイル | 中身 |
|---|---|
| config | 暗号化キー |
| database.sqlite | ワークフロー・認証情報・ユーザー・実行履歴(SQLite のとき) |
| n8nEventLog.log | イベントのログ |
※ 2026年11月13日時点(n8n Docs「Back up and restore」と、テスト用の環境で動かしたときの .n8n フォルダの中身)。
SQLite のときは、n8n を止めてから .n8n フォルダを丸ごとコピーします。動いたままコピーすると、データベースが壊れた状態で保存されることがあります。PostgreSQL を使うときは、.n8n フォルダ(暗号化キー)と、データベースのバックアップ(pg_dump など)の両方が必要です。

② ワークフローのエクスポート(CLI)
ワークフローと認証情報だけなら、n8n のコマンドで JSON に書き出せます。Docker Compose なら、compose.yaml のあるフォルダで次のように実行します。
ターミナル(VPS)
docker compose exec n8n n8n export:workflow --backup --output=/files/backups/workflows/
docker compose exec n8n n8n export:credentials --backup --output=/files/backups/credentials/
/files は手順④の local-files につながっているので、ホストの local-files/backups に JSON が残ります。コンテナの中の別の場所に書き出すと、コンテナを作り直したときに消えるので注意してください。
③ CLI のバックアップに入らないもの
便利な CLI のバックアップですが、ユーザーと権限・実行履歴・Variables・暗号化キーを含む設定は入りません。別のサーバーへワークフローを移すには十分でも、サーバーが壊れたときの復旧には足りないということです。
おすすめは次の組み合わせです。
- 毎日:CLI でワークフローと認証情報を書き出す(差分を見やすい)
- 更新の前と週1回:n8n を止めて n8n_data ボリュームを丸ごと保存する
- 別の場所に:バックアップはサーバーの外(自分の PC や別のストレージ)にも置く
復元は import:workflow・import:credentials で行います。取り込んだワークフローは無効の状態で入るので、画面から公開し直します。
アップデートの手順
n8n はほぼ毎週マイナー版が出ます。2026年11月13日時点の公式ドキュメントの表示では、安定版(stable)が 2.47.5、ベータ版(beta)が 2.48.2 でした。本番では stable を使います。
① 更新の前にバックアップする
公式も更新の前の完全なバックアップをすすめています。上の「n8n_data を丸ごと保存」をしてから進めます。
② リリースノートを確認する
2.47.7 の画面の上部には、n8n 3.0 に向けて「Settings > Migration Report」で変更が必要なワークフローを確認するよう案内が出ています。大きな版に上げる前は、リリースノートで破壊的な変更(breaking changes)を確認します。
③ コマンドで入れ替える
compose.yaml のあるフォルダで次の3行を実行します。
ターミナル(VPS)
docker compose pull
docker compose down
docker compose up -d
特定の版に固定したいときは、image を n8nio/n8n:2.47.5 のようにタグ付きで書きます。勝手に新しい版にならない代わりに、更新はタグを書き換えて行います。
実際にセットアップしてみた
2026年11月13日に、テスト用の Linux 環境(Docker)で次の手順を実際に動かしました。使ったのは公式イメージ docker.n8n.io/n8nio/n8n(バージョン 2.47.7)で、外からは届かない手元の環境です(Traefik・ドメイン・HTTPS は使っていません)。
① compose.yaml を書いて起動する
公式の compose.yaml から Traefik を除き、手元の 127.0.0.1:5678 だけに公開する形にしました。.env の GENERIC_TIMEZONE は Asia/Tokyo です。
compose.yaml(手元で試す用)
services:
n8n:
image: docker.n8n.io/n8nio/n8n
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
- GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
- TZ=${GENERIC_TIMEZONE}
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
- N8N_LISTEN_ADDRESS=0.0.0.0
- N8N_PERSONALIZATION_ENABLED=false
volumes:
- n8n_data:/home/node/.n8n
- ./local-files:/files
volumes:
n8n_data:
ターミナル
docker compose up -d
最初は N8N_LISTEN_ADDRESS を書かずに起動したところ、コンテナは立ち上がったものの n8n が止まり、ログに次のエラーが出ました。
実行結果(n8n のログ)
n8n's address '::' is not available. Please run n8n with a different address, provide correct address in the environment variables N8N_LISTEN_ADDRESS
IPv6 が使えない環境で起きるエラーです。N8N_LISTEN_ADDRESS=0.0.0.0 を足して起動し直すと、/healthz が {"status":"ok"} を返すようになりました。N8N_PERSONALIZATION_ENABLED=false は、オーナー作成の直後に出るアンケート(「Customize n8n to you」の5問)を出さないための設定で、無くても動きます。
② ブラウザで開いてオーナーを作る
http://127.0.0.1:5678 を開くと、オーナーアカウントの作成画面が出ました。

パスワードの条件は「8+ characters, at least 1 number and 1 capital letter」です。ここで作るのは手元の n8n の中だけのアカウントで、試したときはダミーのメールアドレス(owner@example.com)で作りました。
③ 認証つきの Webhook を作って公開する
認証情報に Header Auth(ヘッダー名 X-API-Key)を作り、Webhook ノード(POST・パス itpicks-test・Header Auth)→ Respond to Webhook ノードのワークフローを作って公開しました。

ワークフローの一覧に「Published」と出て、Webhook ノードにはテスト用 URL(/webhook-test/itpicks-test)と本番用 URL の切り替えが表示されます。
④ curl で Webhook を呼んでみる
本番用 URL に、ヘッダーなし・正しいキー・テスト用 URL の順で POST しました。
ターミナル
curl -i -X POST http://localhost:5678/webhook/itpicks-test -H "Content-Type: application/json" -d '{"message":"hello n8n"}'
curl -i -X POST http://localhost:5678/webhook/itpicks-test -H "X-API-Key: local-test-key-123" -H "Content-Type: application/json" -d '{"message":"hello n8n"}'
curl -i -X POST http://localhost:5678/webhook-test/itpicks-test -H "Content-Type: application/json" -d '{"message":"hello n8n"}'
実行結果(要点)
HTTP/1.1 403 Forbidden
Authorization data is wrong!
HTTP/1.1 200 OK
{"ok":true,"received":"hello n8n","at":"2026-11-13T19:40:08.186+09:00"}
HTTP/1.1 404 Not Found
{"code":404,"message":"The requested webhook \"itpicks-test\" is not registered.","hint":"Click the 'Execute workflow' button on the canvas, then try again. (In test mode, the webhook only works for one call after you click this button)"}
| 送り方 | 結果 |
|---|---|
| ヘッダーなし | 403「Authorization data is wrong!」 |
| 間違ったキー(wrong-key) | 403 |
| 正しい X-API-Key | 200(時刻は +09:00 で返った) |
| テスト用 URL(待ち受けなし) | 404「not registered」 |
認証を付けた本番用 URL は、キーが合うときだけ動きます。返ってきた時刻が +09:00 なので、GENERIC_TIMEZONE の Asia/Tokyo も効いています。テスト用 URL は「待ち受け」を始めていないと 404 になるので、外部サービスには本番用 URL を登録します。

成功した呼び出しは Executions タブに「Succeeded in 36ms」と残りました。
⑤ ワークフローと認証情報を書き出す
ターミナル
docker compose exec n8n n8n export:workflow --backup --output=/files/backups/workflows/
実行結果
Error exporting workflows. See log messages for details.
Filesystem error while creating the output directory: EACCES: permission denied, mkdir '/files/backups/workflows/'
ここでつまずきました。原因は、ホストの local-files を root で作っていたことです。コンテナの中の n8n は uid 1000 で動いているので、root のフォルダには書き込めません。
ターミナル
docker compose exec n8n id
ls -ld local-files
実行結果
uid=1000(node) gid=1000(node) groups=1000(node)
drwxr-xr-x 2 root root 4096 Nov 13 10:37 local-files
local-files の持ち主を 1000 に変えて、もう一度書き出します。
ターミナル
chown 1000:1000 local-files
docker compose exec n8n n8n export:workflow --backup --output=/files/backups/workflows/
docker compose exec n8n n8n export:credentials --backup --output=/files/backups/credentials/
実行結果
Successfully exported 1 workflows.
Successfully exported 1 credentials.
ホストの local-files/backups に、ワークフローと認証情報の JSON が1つずつできました。認証情報の中身は「U2FsdGVkX19…」で始まる暗号化されたままで、読むには暗号化キー(config)が要ります。
⑥ データの場所と、使うメモリ・ディスクを見る
ターミナル
docker compose exec n8n ls -la /home/node/.n8n
docker stats --no-stream
実行結果(抜粋)
-rw------- 1 node node 56 Nov 13 19:37 config
-rw-r--r-- 1 node node 2469888 Nov 13 19:38 database.sqlite
-rw-r--r-- 1 node node 4202432 Nov 13 19:41 database.sqlite-wal
-rw-r--r-- 1 node node 1616 Nov 13 19:42 n8nEventLog.log
n8n-compose-n8n-1 MEM 396.4MiB / 15.71GiB CPU 0.47%
暗号化キーの config とデータベース(database.sqlite)が n8n_data ボリュームに入っていることが分かります。ワークフロー1本で待機中のメモリは約396MB、イメージのディスク使用量は docker system df -v で約1.95GBでした。
⑦ 監査を実行して、片付ける
n8n の n8n audit を実行すると、レポートは「Security settings」(コミュニティパッケージ・公開 API・診断データの送信が有効、など)だけで、認証を付けた Webhook は指摘されませんでした。最後にコンテナ・ボリューム・ネットワークを削除しました。
ターミナル
docker compose down -v
この先は公式の手順
ドメインの DNS 設定・Traefik による HTTPS・N8N_WEBHOOK_URL の設定・外部サービスへの Webhook の登録は、今回は行っていません。上の「Docker Composeで構築する手順」「Webhookを外部から受け取る設定」で、公式ドキュメントの手順として説明しています。
どちらを選ぶ?Cloudとセルフホストの選び方
ここまでの内容を、3つの質問にまとめました。

- Docker やサーバーの更新に自信がない → n8n Cloud。無料体験(クレジットカード不要)で試してから決められます
- 自社・個人で使い、作る人が少ない → セルフホストの Community edition。ソフト代0円で実行回数を気にせず使えます
- チームで権限を分けたい・SSO が要る → セルフホスト+Business、または Enterprise
- お客さんに n8n でワークフローを作らせたい → 無料の範囲外。n8n に商用ライセンスを相談します
IT Picks としては、まずは小さな VPS に Community edition を入れ、Webhook に認証を付け、バックアップを自動化するところから始めるのがおすすめだと考えています。手間に見合わないと感じたら、ワークフローを書き出して Cloud に移すこともできます。
AI エージェントから VPS を操作する方法はこちらで比べています。

よくある質問
Q. n8n のセルフホストは本当に無料ですか? A. ソフトは無料です(Community edition)。ただしサーバー代・ドメイン代はかかり、SSO や共有などの機能は有料プランです。使い方も、ライセンス(SUL)の「自社の業務・個人の利用」の範囲に限られます。
Q. 会社の業務に使っても大丈夫ですか? A. 自社の業務の自動化は無料の範囲です。顧客のためのワークフローを作って料金をもらうのも認められています。顧客自身が n8n でワークフローを作れる形で提供するのは範囲外です。
Q. docker run の1行で始める記事を見ました。Compose との違いは? A. docker run でも動きますが、公式ドキュメントの Docker のページは「内容が古い」として、Docker Compose での構築を推奨の方法に挙げています。SSL・ボリューム・環境変数を1つのファイルで管理できるので、更新やバックアップも楽になります。
Q. 手元の PC で動かした n8n で Webhook を受けられますか? A. 外部サービスからは届きません。公式は、ローカルで Webhook を試すときに トンネル機能(cloudflared)を使う方法を案内しています。本番は VPS などの公開サーバーで動かします。
Q. SQLite のままで大丈夫ですか? A. 1人や少人数で試すなら SQLite で始められます。公式は、数人以上が使う・常に動かす本番では PostgreSQL をすすめています。
Q. バックアップは CLI のエクスポートだけで足りますか? A. 足りません。ユーザー・実行履歴・暗号化キーが入らないので、n8n_data ボリュームの丸ごとの保存と組み合わせてください。
まとめ
n8n をセルフホストする方法のポイントをまとめます。
- ソフトの料金:無料(Community edition。サーバー代・ドメイン代は別)
- Cloud の料金:Starter 月$20・Pro 月$50(年払い・ドル表示。月の実行回数で決まる)
- 無料に含まれないもの:Projects・共有・SSO・Git 管理など(Business 以上)
- ライセンス:Sustainable Use License(自社の業務・個人の利用は可、n8n をサービスとして売るのは不可)
- 構築:Docker Compose+Traefik、タイムゾーンは Asia/Tokyo、local-files は uid 1000 に
- Webhook:本番用 URL を使い、N8N_WEBHOOK_URL と認証を設定
- バックアップ:n8n_data(暗号化キー入り)を丸ごと+CLI のエクスポート
- 更新:月1回以上、バックアップしてから docker compose pull
まずはテスト用のサーバーで Docker Compose を動かし、Webhook に認証を付けたワークフローを1本作るところから始めてみてください。
