n8nはクラウド版とセルフホストのどちらにするか:運用負担で比べる

まず前提:どちらも同じn8nで、違うのは「運用の担当」

n8nの公式ドキュメントでは、利用方法はn8n Cloud(n8nが運営する形態)とセルフホスト(自分の環境で動かす形態)の2つと整理されています。Cloudは導入作業が不要で、ホスティング・更新・スケーリングをn8n側が担います。セルフホストはCommunity Editionを無料で使えますが、保守は自分たちの責任です。

また、セルフホストの公式手順には「サーバーやコンテナの設定、リソース管理とスケーリング、サーバーとアプリのセキュリティ確保、n8nの設定」といった技術知識が必要だと書かれています(Docker Composeでのセットアップ)。つまり選択の軸は「機能の差」より「この作業を誰がやるか」です。なお、SSOや共有などの有料機能は、どちらの形態でも有料契約が必要で、提供状況は時期で変わると公式に注記されています。

運用作業の担当を書き出す比較表

下表は、公式ドキュメントで確認できた内容に、編集部の整理(読み取り)を加えたものです。「要確認」は、契約前に提供条件を確認する項目です。

• サーバー・OSの用意と保守、クラウド版：n8n側、セルフホスト(Linuxサーバー上のDocker Composeの例)：自分たち
• n8n本体の更新、クラウド版：n8n側が自動更新。ただしインスタンスオーナーがリリーストラックや頻度、メンテナンス時間帯を設定できる、セルフホスト(Linuxサーバー上のDocker Composeの例)：自分たちで新しいイメージを取得し、コンテナを再作成する
• 更新の失敗への備え、クラウド版：大きなバージョン更新やDB移行を伴う更新は、確認後に実行。元に戻せない旨の警告あり、セルフホスト(Linuxサーバー上のDocker Composeの例)：更新前に自分でデータを退避しておく必要がある(編集部の整理)
• ドメイン・DNS・SSL証明書、クラウド版：提供範囲と利用者側の作業は要確認、セルフホスト(Linuxサーバー上のDocker Composeの例)：自分たち。公式例ではサブドメインのDNS設定とLet's Encryptの証明書用メールアドレスを維持する
• データの保存と暗号化キー、クラウド版：基盤の保守はn8n側。認証情報を含むデータの復元条件は要確認、セルフホスト(Linuxサーバー上のDocker Composeの例)：自分たち。/home/node/.n8nのボリュームに暗号化キー等が入る
• バックアップ、クラウド版：n8n側が自動作成。取得できるワークフローのバックアップには認証情報が含まれない。PostgreSQLのインスタンスは画面から取得できず、サポートへの依頼が必要。頻度・保持期間は要確認、セルフホスト(Linuxサーバー上のDocker Composeの例)：自分たち(公式手順は永続化の方法を示すが、バックアップ運用までは設計しない)
• タイムゾーン設定、クラウド版：管理画面で設定、セルフホスト(Linuxサーバー上のDocker Composeの例)：環境変数で設定。スケジュール実行の時刻に影響
• 障害の一次切り分け、クラウド版：状況に応じてn8nへ問い合わせ、セルフホスト(Linuxサーバー上のDocker Composeの例)：自分たちで監視・ログ確認
• 課金・実行回数の管理、クラウド版：プランごとの上限を確認、セルフホスト(Linuxサーバー上のDocker Composeの例)：サーバー費用は自分たち。有料エディションは別途ライセンス

この表を自社用にするなら、右端に「担当者名」と「対応できる時間帯(平日昼のみ、夜間も、など)」の列を足してください。空欄が残る行が、そのままセルフホストの危険箇所です。

クラウド版で「楽になる」ことと、残る作業

クラウド版では、更新の主導権が完全には自分たちにありません。公式ドキュメントによると、どの設定にしていても、n8nは少なくとも2週間に1回はインスタンスを自動更新します。設定できるのはリリーストラック(BetaかStable)、更新頻度、メンテナンス時間帯です。更新時には1〜2分程度の停止が生じるとも書かれています(Cloudの更新)。

つまりクラウド版でも、次の確認は人の仕事として残ります。

• 更新後に、重要なワークフローが動いているかを確認する担当
• メンテナンス時間帯を、業務への影響が小さい時間に設定する担当
• 大きな更新の警告を読み、実行してよいか判断する担当(この種の更新は元に戻せないと公式に明記されています)

加えて、Cloudはプランごとに実行回数や同時実行数の上限があります。料金ページには、1回の実行をステップ数に関係なく数える方式や、プラン別の実行履歴の保持期間が載っていました。自動化が増えたときに上限へ当たらないか、契約前に見積もってください。

セルフホストで「自分の仕事になる」こと

公式のDocker手順から読み取れる、継続的な作業は次のとおりです。ただし、参照したDocker手順には内容が古いとの注意があるため、構築時には現在の推奨手順も確認してください。

1. 更新:Docker Composeなら、イメージを取得し、コンテナを停止して再作成する手順です(Dockerの旧手順)。Docker Composeの公式ページには、多くの週に新しいマイナーバージョンが出ると書かれています。どの頻度で追うか、安定版に固定するかを自分たちで決めます。
2. データの永続化と暗号化キー:既定のデータベースはSQLiteで、認証情報・実行履歴・ワークフローが入ります。PostgreSQLを使う場合でも、/home/node/.n8nは暗号化キーなどが入るため永続化が推奨されています。ここを失うと、保存した認証情報を復元できなくなるおそれがあります(この影響の説明は編集部の整理です)。
3. 時刻設定:GENERIC_TIMEZONEはスケジュール関連ノード、TZはコンテナ内のシステム時刻に使われます。業務で使うタイムゾーンに合わせて設定します。
4. 証明書とDNS:公式の例では、Traefik経由でLet's Encryptの証明書を自動管理しますが、通知用メールアドレスやDNSの維持は利用者側です。
5. 監視とログ:公式ドキュメントでも、セルフホストの運用には監視、ログ、インスタンス更新が含まれるとされています(ホスティングの概要)。

バックアップについては、公式のDocker手順ページ上で「これが推奨バックアップ手順」と読める記述は確認できませんでした。そのため、セルフホストを選ぶなら、バックアップ方法と復元の試験を自分たちで設計するものとして計画してください。

判断表:どちらを選ぶか

次の質問に「はい」がいくつあるかで、おおまかに判断できます(編集部の提案です)。

• サーバー・Docker・DNSを扱える担当者が、継続的にいる、はい →：セルフホスト寄り
• 担当者が休んだ日に障害が起きても、代わりに対応できる人がいる、はい →：セルフホスト寄り
• 社内ネットワーク内のシステムなど、自分の環境に置く必要がある、はい →：セルフホスト寄り
• 無停止に近い運用より、まず早く動かしたい、はい →：クラウド寄り
• 担当者は業務部門の人で、サーバー作業は本業ではない、はい →：クラウド寄り
• 更新やバックアップの失敗が、売上や顧客対応に直結する、はい →：クラウド寄り(または専任体制のセルフホスト)

セルフホストに寄った場合でも、最初の1か月は小さな自動化だけで運用してみて、更新とバックアップ復元を一度試すと、負担の実感がつかめます。

選択前に確認する公式資料の一覧

今回の自動校閲で、ページを開いて本文を確認した資料です。契約や構築の前に、自分の目で最新の記述を確かめてください。

• 形態の違い全体、資料：Choose how to use n8n、見るポイント：保守の担当、有料機能の扱い
• セルフホストの方法、資料：Host n8n、見るポイント：導入方法、運用項目
• Linuxサーバーの構成例、資料：Use Docker Compose、見るポイント：必要な技術知識、DNS・SSL
• 現在の推奨導入手順、資料：Install using Docker Compose、見るポイント：構成、データの永続化、PostgreSQLの利用
• データ保存・更新の旧手順、資料：Install with Docker、見るポイント：内容が古いとの注意あり。ボリューム、DB、暗号化キー、時刻設定
• Cloudの更新、資料：Update your version、見るポイント：自動更新の頻度、停止時間、元に戻せない更新
• Cloudのワークフロー取得、資料：Download workflows、見るポイント：オーナーの取得手順、認証情報を含まないこと、PostgreSQLの場合の制限
• プランと上限、資料：Pricing、見るポイント：実行回数、同時実行、履歴の保持期間

ほかに、ライセンス(Community Editionを業務でどう使えるか)、Cloudのバックアップの頻度・保持期間や認証情報を含む完全復元の条件、データを置く地域は、今回の確認範囲に含まれていません。社内規程や契約が関わる場合は、n8nの公式ライセンス資料と利用規約を別途確認してください。

社内で共有する依頼文の例

担当表の空欄を埋めるために、次の文面を情報システム担当や上長へ送る使い方ができます(説明用の例です)。

n8nの導入形態を決めたいので、次の3点を教えてください。1. 更新作業(月1回程度)と、更新後の動作確認を担当できる人はいますか。2. バックアップの保存先と、復元を試せる時間は確保できますか。3. 障害時(夜間・休日を含む)の連絡先は決められますか。3つとも「はい」なら、セルフホストも検討します。1つでも不明ならクラウド版で試用します。

回答が曖昧なら、それが現時点の答えです。まずクラウド版で業務フローを固め、体制が整ってからセルフホストへ移る順序でも遅くありません。移行時はワークフローの書き出しや認証情報の再設定が必要になる可能性があるため、その手順は移す前に公式資料で確認してください。