社内の業務システム間でAPI連携やデータ連携を自動化したいが、SaaS型の自動化ツールに業務データを預けるのは避けたい、という場面があります。n8nは「フェアコード」というライセンス形態で公開されているワークフロー自動化ツールで、Webhook（外部からのHTTP通知を受け取る仕組み）やスケジュール実行を起点に、複数のAPIやAIモデルを視覚的なフローでつなげます。自社のUbuntuサーバーにDocker Composeで構築する場合、どんな構成要素が必要で、どこに注意すべきかを整理します。
n8nはクラウド版もありますが、業務データを扱う連携基盤を外部SaaSに置くことに抵抗がある現場は少なくありません。自社ホスト（セルフホスト）であれば、ネットワーク経路や保存先を自社の管理下に置けます。一方で、HTTPS終端やファイアウォール設計、バージョン更新の運用まで自分たちで担う必要があり、選定前に構成の全体像を把握しておく価値があります。
自社ホスト構成の中身を分解する
Ubuntu 24.04 LTS上にDocker Composeで構築する場合、サーバー上で動くコンポーネントは主に4つです。それぞれの役割を分けて見ていきます。
一つ目はCaddyです。Caddyはリバースプロキシ兼Webサーバーで、80番・443番ポートでインターネットからの接続を受け付け、TLS証明書（通信を暗号化するための電子証明書）を自動取得してHTTPS終端を担います。NginxやApacheと役割は近いですが、Let's Encryptとの連携が標準で組み込まれており、証明書更新の手動運用がほぼ不要になる点が特徴です。
二つ目はn8n本体のコンテナです。これは5678番ポートで動きますが、重要なのは「127.0.0.1（ループバックアドレス、サーバー自身からしかアクセスできないアドレス）にのみ公開する」という設計です。インターネットからの直接アクセスはCaddy経由に限定し、n8n自体は外部に直接さらしません。
三つ目はタスクランナーです。n8nのCode node（フロー内でコードを実行する機能）が動かすユーザーコードを、n8n本体とは別のコンテナ（n8nio/runnersイメージ）で実行します。n8n本体のコンテナには認証情報（APIキーや接続情報）が保持されているため、ユーザーが書いたコードをそこで直接実行すると、意図しない形で認証情報にアクセスされるリスクがあります。これを避けるために実行環境を分離する「外部モード」が、本番運用では推奨されています。
四つ目はPostgreSQL 18です。n8nはワークフロー定義や実行履歴の保存先として、デフォルトのSQLite（ファイルベースの軽量データベース）ではなくPostgreSQLを使う構成が、複数ユーザーや実行量の多い環境では現実的な選択になります。コンテナ間通信はDocker Composeが作る内部ネットワークに閉じており、5432番ポートが外部に露出することはありません。
なぜこの構成がファイアウォール設計とぶつかりやすいか
ここで業務システム担当者が見落としやすい落とし穴があります。UbuntuのファイアウォールであるUFW（Uncomplicated Firewall）で「5678番ポートを拒否」と設定しても、それだけでは不十分な場合があるという点です。
Dockerはiptables（Linuxのパケットフィルタリング機構）のルールを自分で書き換えて、コンテナが公開しているポートへの通信を直接許可してしまうことがあります。UFWの設定はiptablesの上に乗る形で動くため、Dockerが追加したルールがUFWのポリシーより先に評価され、結果としてUFWで「拒否」していたはずのポートが外部からアクセス可能なまま、ということが起こり得ます。
これに対する現実的な対処は、そもそも公開範囲を絞ることです。n8nコンテナを127.0.0.1:5678のようにループバックアドレス限定で公開すれば、Dockerのポートバインディング自体がホスト外からの到達を物理的に遮断します。UFWのルール競合を気にする前に、Compose側のports設定でバインド先アドレスを明示しておく方が確実です。
既存の社内システムでDocker Composeを使っている場合、この「公開ポートの既定値がUFWを素通りする」という挙動は、n8nに限らず他のコンテナ構成にも共通する注意点として確認しておく価値があります。
既存の自動化基盤・RPAツールとの比較で考える選定基準
業務システムの連携手段としては、n8nのほかにもいくつかの選択肢があります。判断軸を整理すると以下のようになります。
| 選択肢 | 強み | 向いている場面 |
|---|---|---|
| n8nセルフホスト | データを自社管理下に置ける、API連携の柔軟性が高い | 複数システム間のAPI連携・条件分岐を伴う処理 |
| n8nクラウド版 | 運用負荷が低い | インフラ担当が薄いチーム |
| RPAツール | 画面操作の自動化に強い | APIがない旧式システムの操作自動化 |
| ジョブスケジューラ＋スクリプト | 既存運用基盤との親和性 | 定型バッチ処理のみで足りる場合 |
API連携が中心で、かつ処理フローを非エンジニアも含めて可視化したいなら、n8nのような視覚的ワークフローツールは検討に値します。一方、画面操作しかできない旧システムが相手なら、RPAツールの方が適している場合もあります。自社の連携対象がAPIベースかUIベースかを、まず棚卸ししておくと選定がぶれません。
今日確認できること
導入を検討する、あるいは既に動かしている場合に、確認しておきたいポイントを挙げます。
- サーバーのバージョンを
docker compose versionとdocker exec経由でn8nのバージョン確認コマンドを実行し、現在稼働中のn8nバージョンを把握する .envファイルにN8N_ENCRYPTION_KEY（認証情報の暗号化キー）が設定されているか確認する。これが変わると過去の認証情報が復号できなくなるN8N_WEBHOOK_URLが設定されているか確認する。これはn8n 2.35.0で旧来のWEBHOOK_URLから置き換わった変数で、Webhook受信URLの生成に使われる- リバースプロキシ経由で動かしている場合は
N8N_PROXY_HOPS=1の設定有無を確認する。プロキシ経由のクライアントIP解決に関わる設定 ufw statusとdocker psの公開ポート一覧を突き合わせ、意図しないポートが外部公開されていないか確認する
バージョン更新については、.env内のイメージタグ（バージョン番号）を1行書き換えてdocker compose pull && docker compose up -dを実行する運用が基本です。ただし、n8n 1.0でN8N_BASIC_AUTH系の環境変数が廃止されている点や、今後のメジャーバージョンでDockerベースのインストールのみがサポート対象になる方針も示されているため、更新前にはリリースノートで破壊的変更（設定の非互換な変更）の有無を確認してから着手する方が安全です。
まとめ
n8nの自社ホスト構成は、Caddyによる公開窓口、n8n本体、タスクランナー、PostgreSQLという4つの役割を分けて理解すると見通しが立ちます。
ファイアウォール設計では、UFWの拒否ルールがDockerの公開ポート設定を素通りする可能性がある点を踏まえ、127.0.0.1限定公開を基本線にする判断が実務的です。
導入検討中なら、連携対象がAPIベースかUI操作ベースかを先に整理し、RPAツールや既存ジョブスケジューラとの使い分けを決めてから構成を組むと手戻りが少なくなります。
既に運用中なら、.envの暗号化キーとWebhook URL設定、公開ポートの実態を一度棚卸ししておく価値があります。