n8n Cloud vs Self-host

Self-hostできることと、Self-hostした方が安いことは別

n8nはCloudとSelf-hostedの両方を用意しています。Cloudはhostingをn8n側へ寄せ、Self-hostは実行環境を自社側へ戻します。

Self-hostで増えるのはserver代だけではありません。version update、backup/restore、security、monitoring、障害対応、network、secret管理を誰が持つかまで設計します。

Software subscriptionが0または低いことと、総コストが低いことは同じではありません。Serverは請求書を送ってきますし、保守担当者はさらに現実的です。

• Cloud：hosting/基盤運用をn8n側へ寄せる
• Self-host：deployment controlとinfra運用を自社へ寄せる
• Self-host TCO：server + backup + update + security + monitoring + 担当工数
• 必要なBusiness/Enterprise機能はCommunityと同一と仮定しない

Self-host可能でも、利用目的とSustainable Use Licenseは確認する

n8nはSustainable Use Licenseに基づくfair-codeとして説明されており、Self-hostできることと、用途制限のない一般的なopen-source licenseであることは同じではありません。

内部業務での利用は許容例がありますが、n8nそのものを顧客向けにホストして有料提供するような用途などでは条件が変わります。外部提供を伴う構成では、技術設計より先に現行Licenseと契約条件を確認します。

『sourceが見える』『自分でhostできる』『open source』を同義語として扱わないことが重要です。

• 内部業務利用と顧客向け提供を分ける
• Self-host可能 = 無制限利用ではない
• Business/Enterprise機能の必要性を確認
• 外部提供前に現行Licenseを再確認

Cloudとの差額ではなく、自社へ戻す仕事を金額と時間にする

Self-hostの比較では、VMやContainerの料金だけでは不十分です。月次update、security patch、backup確認、restore test、monitoring、incident対応に必要な時間を別に記録します。

既存のPlatform/DevOps運用へ自然に載せられるなら追加工数は小さくなる可能性があります。逆にAutomation担当が初めてserver運用まで持つなら、Cloudとの差額以上に時間を使う場合があります。

人件費の仮定は公式FACTではありません。FineInTheory側のEDITORIAL/TCO計算として明示し、実測できるようになったら置き換えます。

• Infrastructure費
• Update/patch工数
• Backup/restore
• Monitoring/alert
• Incident対応
• License/Edition費

技術力があるからSelf-hostではなく、運用要件があるからSelf-hostにする

Developerがいることだけを理由にSelf-hostを選ぶと、運用対象が1つ増えます。データ配置、private network、security policy、deployment controlなど、自社で持つ必要がある要件を先に確認します。

要件が明確ならSelf-hostの価値があります。要件がないならCloudで減らせる運用負担も立派なコスト削減です。自由度は、使う予定があって初めて価値になります。

• Self-host理由が『無料だから』だけなら再確認
• data/network/deployment要件があるならSelf-hostを評価
• 専任運用者がいないならCloudのmanaged costを評価
• 移行時はWorkflowだけでなくCredentials/environmentも洗い出す