Dockerを使ったn8n:インストールとセルフホスティング 無料で
Dockerを使ったn8nは、再起動や更新後も動作し続けるセルフホスト型の自動化インスタンスを最短で構築する方法です。このガイドでは、あえて基盤部分に絞ります。Docker Composeファイル、データ用ボリューム、ご自身で管理する暗号化キー、バックアップと更新の手順、そして慎重なHTTPS公開を扱います。AIノードとOllamaへの接続は別のガイドで扱います。ここでの目標は、作り直す必要のないクリーンなインストールです。
#npmではなくDockerでn8nをインストールする理由
n8nはNode.jsアプリケーションです。npmやnpxで起動でき、ドキュメントでも簡単な試用方法として紹介されています。継続的に稼働させるインスタンスには、プロジェクトが推奨する公式Dockerイメージが適しています。適切なバージョンのNode.jsが含まれ、n8nをマシンの他の部分から分離でき、イメージを変更するだけで簡単に更新できます。また、n8nのホスティングに関するドキュメントでも、すべてのサーバー例でこの形式が使われています。
二つ目の利点は再現性です。docker-compose.ymlファイルには、イメージ、ポート、環境変数、データボリュームなど、設定全体が記述されます。これをバージョン管理したり、別のマシンにコピーしたり、六か月後に読み返して何が動いているかを正確に確認したりできます。npmでインストールする場合、この情報はシステム、ユーザープロファイル、サービスマネージャーに分散します。
- このガイドの対象範囲
- ローカルまたは小規模サーバーへのインストール、データの永続化、暗号化キー、バックアップ、更新、HTTPSアクセス。
- 対象外の内容
- n8nのAIノード、Ollamaへの接続、MCPサーバー、キューモードでのスケーリングです。最初の2項目にはそれぞれ専用のガイドがあり、記事の末尾でリンクしています。
- 主張していないこと
- インストール時間、測定済みの消費量、固定されたバージョン番号はいずれも提示していません。これらの値はリリースごとに変わるため、インストール時点で公式ソースを確認してください。
#コミュニティ版のライセンスと制限
あなたのマシンで動作するエージェント:エージェント型 Cline、MCP、n8n + Ollama、ローカル自動化。
- 永久に利用できるオンラインスペース
- PDF + ファイル
- 30日間返金対応
n8nは、OSIの意味でのオープンソースライセンスでは提供されていません。コードはSustainable Use Licenseの下で公開されており、提供元はこれを「fair-code」と呼んでいます。大まかに言えば、内部利用、個人利用、または自社の用途であれば、n8nを自由に使用、変更、ホスティングできます。制限されているのは再販売です。n8nを第三者向けのホスティングサービスとして提供したり、商用製品に組み込んだりするには、提供元との合意が必要です。全文とFAQはdocs.n8n.io/sustainable-use-license/に掲載されています。利用が社内自動化の範囲を超える場合は、確認してください。
Dockerでインストールするバージョンはコミュニティ版です。完全なエディター、数百の連携用node、webhook、スケジュールされたトリガー、AI node、ユーザー管理が含まれています。一部の機能は、セルフホスト型の有料プランに限定されています。具体的には、シングルサインオン(SSO)、Git同期付きの環境、外部シークレット、外部ツールへのログ送信、コラボレーション機能の一部です。また、提供元は「登録済みコミュニティ」と呼ばれる無料キーを提供しています。設定でメールアドレスを入力して取得でき、いくつかの追加機能が利用可能になります。正確な一覧は変更されるため、docs.n8n.io/hosting/community-edition-features/のページを確認してください。
#前提条件
- DockerとDocker Compose
- LinuxではComposeプラグイン付きのDocker Engine、WindowsとmacOSではDocker Desktopを使用します。docker compose versionで確認してください。このコマンドは、古いツールのハイフン付き形式ではなく、二語の形式(docker compose)でバージョン番号を返す必要があります。
- 電源を入れたままにしておくマシン
- n8nは、予定した時刻になるか、webhookを受信するとワークフローを実行します。夜に電源が切れるPCでは、夜間のトリガーは実行されません。ミニPC、Docker対応のNAS、または小規模なVPSで十分です。単純なワークフローをいくつか実行するだけなら、必要なメモリも少なくて済みます。
- 空いているポート
- n8nはコンテナ内部でポート5678をリッスンします。ホスト側でも同じ番号で公開しますが、別のサービスがすでに使用している場合は変更してください。
- HTTPSの手順のみ
- マシンを指すドメイン名と、インターネットから到達可能なポート80および443が必要です。これらがない場合はローカルアクセスにとどめるか、VPNを使用してください。HTTPSのセクションで両方の選択肢を詳しく説明します。
#Docker Composeでn8nをインストールする手順
n8nのドキュメントでは、まず試用に便利な一行のdocker runコマンドを示しています。ここでは直接Composeを使います。ファイルは少し長くなるだけで、インストールの基準になります。以下の値はすべてn8nで文書化されているものです。タイムゾーンとポートの値だけは、このガイドで選択しています。
- 01プロジェクトのフォルダーを作成する専用のディレクトリにComposeファイルと.envファイルを置き、後でバックアップも保存します。n8n自体のデータはこのディレクトリではなく、名前付きのDockerボリュームに保存されます。
- 02暗号化キーを生成する初回起動の前に、ランダムなキーを生成して.envファイルに配置します。次のセクションでは、この順序が重要な理由を説明します。
- 03docker-compose.ymlを記述する以下のファイルをコピーします。この設定では、n8nをマシンのポート5678で公開しますが、ローカルアドレス127.0.0.1に限定されます。また、n8n_dataボリュームをコンテナ内の/home/node/.n8nディレクトリにマウントします。ここはn8nがSQLiteデータベース、設定、ファイルを保存する場所です。
- 04開始するdocker compose up -d télécharge l'image et lance le conteneur en arrière-plan. La première exécution prend le temps du téléchargement de l'image ; les suivantes sont immédiates.
- 05所有者アカウントを作成するブラウザーでhttp://localhost:5678を開きます。n8nから最初のアカウントの作成を求められ、そのアカウントがインスタンスの所有者になります。バージョン1.0以降は、このアカウントがアクセスを保護します。環境変数による従来の基本認証は廃止されています。
変数について少し説明します。GENERIC_TIMEZONEは、Schedule Triggerノードと日付式で使用するタイムゾーンを設定します。TZはコンテナ内のシステム時計を合わせます。N8N_RUNNERS_ENABLEDはタスクランナーを有効にします。これはCodeノードのコードを別プロセスで実行する仕組みです。ドキュメントでは有効化が推奨されており、最近のバージョンでは設定されていない場合に警告が表示されます。N8N_DIAGNOSTICS_ENABLED=falseは、テレメトリーデータのエディターへの送信を停止します。2つのEXECUTIONS_DATA_*変数は、実行履歴を336時間、つまり十四日を超えて保持しないようn8nに指示し、データベースが際限なく肥大化するのを防ぎます。
./local-files:/filesのマウントは任意です。ホストマシンと共有するフォルダーをn8nに提供し、ファイルの読み書きを行うnodeに便利です。使用しない場合は、この行を削除してください。
#暗号化キー:失ってはいけない変数
n8nは、インターフェースに保存するすべての認証情報、つまり連携サービスのAPIトークン、パスワード、OAuthキーを暗号化します。使用する暗号化キーはN8N_ENCRYPTION_KEYです。これを設定しない場合、n8nは初回起動時にキーを生成し、/home/node/.n8nフォルダーのconfigファイル、つまりボリューム内に書き込みます。これは機能しますが、その場合キーはこのボリューム内にしか存在しません。ボリュームを失った場合、またはキーなしでインスタンスを再作成した場合、すべての認証情報が読み取れなくなり、再入力が必要になります。
そのため、このガイドでは初回起動前に.envファイルでキーを固定します。キーを自分で管理でき、Composeファイルと一緒にバックアップできるうえ、認証情報を失わずに別のマシンでデータベースを復元できます。ここから二つのルールが導かれます。
- 後からキーを絶対に変更しないでください
- 暗号化に使用したものと異なるキーを使うと、既存の認証情報はすべて使用できなくなります。キーを交換する必要がある場合は、まずexport:credentialsコマンドで復号済みの認証情報をエクスポートし、変更後に再インポートしてください。
- .envファイルを別途バックアップする
- キーのコピーをパスワードマネージャーに保管してください。キーなしのボリュームバックアップは、ワークフローを読み取れる場合でも、認証情報については役に立ちません。
#データの永続化とバックアップ
n8nが保持する必要のあるすべてのデータは、/home/node/.n8nに保存されます。ここには、ワークフロー、暗号化された認証情報、実行履歴を含むSQLiteデータベース、configファイル、インストール済みのコミュニティnode、ディスクストレージモードで使用するバイナリファイルが含まれます。名前付きボリュームn8n_dataは、docker compose downやコンテナの削除後も残ります。ただし、docker compose down -vやdocker volume rmの実行後は残りません。この二つのコマンドはデータを消去します。
バックアップには、二つの方法を組み合わせて使えます。第一の方法ではボリューム全体をアーカイブします。書き込み中のSQLiteデータベースを取得しないよう、ファイルをコピーする間だけn8nを停止します。第二の方法では、n8nのコマンドラインツールを使い、ワークフローと認証情報をJSONとしてエクスポートします。これらは個別に読み取り、再インポートできます。
エクスポートコマンドの--backupオプションは、要素ごとに読み取り可能な形式のファイルを生成するオプションをまとめたものです。エクスポートされた認証情報は、--decryptedを追加しない限りキーで暗号化されたままです。追加した場合は、ファイルを秘密情報として扱ってください。復元するには、import:workflowコマンドとimport:credentialsコマンドで、--separateオプションを指定して同じディレクトリを受け入れます。CLIの完全なリファレンスはdocs.n8n.io/hosting/cli-commands/にあります。
別のマシンで完全に復元するには、同じdocker-compose.ymlと同じ.envを使ってディレクトリを再作成し、docker compose up -dを実行して空のボリュームを作成した後、docker compose stopを実行します。バックアップ時とは逆のコマンドでアーカイブをボリュームに展開し、再起動してください。認証情報を復元するには、同じ暗号化キーが必要です。
#インスタンスを壊さずにn8nを更新する
n8nは頻繁にバージョンを公開します。イメージのlatestタグは最新の安定版を指し、nextタグはテスト版を指します。番号付きタグを使えば、特定のバージョンを固定できます。Composeでは、更新は三つのコマンドで完了します。新しいイメージを取得し、古いコンテナを停止し、同じ設定で新しいコンテナを作成します。データはボリュームに残り、変更されません。データベーススキーマの移行が必要な場合は、起動時に自動的に実行されます。
三つの注意点を守れば、主なトラブルを避けられます。まずバックアップを取ってください。データベースの移行は後戻りできません。github.com/n8n-io/n8n/releasesのリリースノートと、ドキュメントの更新ページdocs.n8n.io/hosting/installation/updating/を確認してください。メジャーバージョンでは環境変数が削除されたり、デフォルトの動作が変更されたりすることがあり、ドキュメントには破壊的変更専用のページもあります。最後に、インスタンスが重要な場合はlatestよりも番号付きタグを選んでください。次回のpullで変更を強いられるのではなく、バージョンアップのタイミングを自分で選べます。
#n8nを慎重にHTTPSで公開する
n8nをホストマシンまたはローカルネットワークから利用する限り、前述のインストールで十分です。webhookを使う場合、つまり外部サービスからインスタンスを呼び出す必要がある場合や、外部からアクセスする場合には、公開が必要になります。方法は二つありますが、第一の方法が適していることが多いです。
- 公開ではなくVPNを使う
- Tailscale、WireGuard、またはルーターのVPNを使えば、インターネット上でポートを開かずに、どこからでもn8nへアクセスできます。公開webhookを使わない個人利用では、これが最も安全で簡単な方法です。インスタンスはプライベートネットワーク上でHTTPのまま動作し、VPNアドレス経由でアクセスする場合はN8N_SECURE_COOKIE=falseが必要になります。
- 証明書付きのリバースプロキシ
- 公開Webhookを受信するには、ドメイン名、TLSを終端するリバースプロキシ、証明書が必要です。n8nの公式例ではTraefikを使用していますが、ここでは設定が三行で済み、Let's Encryptの証明書を自動取得するCaddyを紹介します。
以下の構成では、n8nはポートを一切公開しません。80と443で接続できるのはCaddyだけで、Composeの内部ネットワークを通じてn8nコンテナへ転送します。N8N_HOST、N8N_PROTOCOL、WEBHOOK_URLの各変数は、n8nに対して、提供元となる公開アドレスを示します。これらを設定しないと、エディターに表示されるwebhookのURLがlocalhostを指し、OAuthのリダイレクトが失敗します。
docker compose up -dを実行する前に、n8n.votre-domaine.frのDNSレコードがマシンのパブリックアドレスを指し、ポート80と443がそのマシンに転送されている必要があります。するとCaddyがLet's Encryptに証明書を要求し、手動操作なしで更新します。caddy_dataとcaddy_configのボリュームにより、再起動後も証明書と状態が保持されます。
#トラブルシューティング:よくある障害
- 開いたときに表示されるセキュアCookieに関するメッセージ
- localhostではないアドレスからHTTPでn8nにアクセスしています。HTTPSに移行するか、プライベートネットワーク上でのみN8N_SECURE_COOKIE=falseを追加してください。
- /home/node/.n8nの権限エラー
- コンテナはrootではなく、nodeユーザーで実行されます。これは、名前付きボリュームを、権限が一致しないホスト側のディレクトリに置き換えた場合に起こります。名前付きボリュームを使い続けるか、ディレクトリの所有者をイメージ内のnodeのユーザーIDである1000に合わせてください。
- スケジュール済みのワークフローが間違った時刻に実行される
- GENERIC_TIMEZONEが設定されていないか、スペルが間違っています。期待される値は、Europe/ParisのようなIANAタイムゾーン名です。各ワークフローでは、設定から独自のタイムゾーンを指定することもできます。
- Webhookにlocalhostアドレスが表示される
- WEBHOOK_URLが定義されていないか、サードパーティーサービスが接続してくるアドレスと一致していません。値の末尾はスラッシュで終わり、プロトコルを含める必要があります。
- データベースが際限なく大きくなる
- 実行データの削除が無効になっているか、期間が長すぎます。EXECUTIONS_DATA_PRUNEとEXECUTIONS_DATA_MAX_AGEを確認し、成功した実行のデータを保持するオプションも確認してください。このオプションはワークフローごとに無効化できます。
- 更新後、n8nが起動を拒否する
- docker compose logs n8nでログを確認してください。通常、メッセージには削除された変数や失敗した移行が示されます。リリースノートと照合し、必要に応じてバックアップを復元してください。
- n8nが同じマシン上のOllamaを認識しない
- コンテナ内では、localhostはホストではなくコンテナ自身を指します。使用するアドレスは、システムとOllamaの起動方法によって異なります。詳しくは、以下で参照するn8nのガイドとOllamaで説明しています。
ドキュメントで答えが見つからない質問については、フォーラムcommunity.n8n.ioが活発で、エディターも回答しています。正確なバージョン、インストール方法、ログの行を記載してください。最初に求められるのはこの三つです。
#さらに詳しく
インスタンスは稼働し、バックアップされ、最新の状態になっています。次の自然な手順は、ローカルモデルに接続し、その後より大きなスタックに統合することです。このガイドで参照した公式ソースは、n8nドキュメントのホスティングのセクション(docs.n8n.io/hosting/)、Dockerのインストールページ(docs.n8n.io/hosting/installation/docker/)、更新ページ、ライセンスのページ、コミュニティ版の機能に関するページです。これらのページはバージョンに応じて更新されます。このガイドと相違する場合は、これらのページを優先してください。
- n8n + Ollama:100 % ローカル AI で自動化する
- 次に読むガイド:AIノード、コンテナからOllamaへの接続、翻訳と要約の最初のワークフロー。https://quelllm.fr/guide/n8n-ollama-automatisation-workflow
- Docker で Ollama を使う
- Ollamaもn8nの隣でコンテナとして動かし、GPUにアクセスさせたい場合。https://quelllm.fr/guide/ollama-docker-installation-guide
- Docker Compose で LLM を本番環境にデプロイ
- 完全なスタックをOllama、Open WebUI、Qdrant、n8n、Traefikとともに一つのComposeファイルにまとめ、単独のインスタンスの先へ進めます。https://quelllm.fr/guide/deployer-llm-docker-compose-production
- Ollamaサーバーのセキュリティ強化
- 認証、ファイアウォール、リバースプロキシ:公開に関するルールは、n8nを含むすべてのセルフホストサービスに適用されます。https://quelllm.fr/guide/securiser-serveur-ollama
ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。