n8nをSelf-hostedするメリット・デメリット｜運用負荷とデータ管理で判断

n8nはSelf-hostedできることが大きな特徴です。

ただしSelf-hostedは「Cloud料金を払わずに無料で同じものを使う方法」と考えると判断を誤りやすくなります。

data、network、customizationを自分でcontrolできる代わりに、server operationとsecurity responsibilityも自分たちで持つ選択です。

メリット1：dataを自分のenvironmentへ置ける

Self-hostedではn8n instanceとdatabaseを自分のinfrastructureへ配置できます。

on-prem、private cloud、VPCなど、自社security requirementに合わせた構成を取りやすくなります。

社内systemやprivate databaseと接続するときに、network設計を自分でcontrolできるのは大きなメリットです。

メリット2：network制御の自由度が高い

internal API、private subnet、VPN内serviceなど、public internetへ出したくないsystemと接続しやすくなります。

n8n公式product pageでもon-premやair-gapped deploymentを選択肢として案内しています。

外部SaaSだけでなく、社内networkを含むautomationでSelf-hostedの価値が出ます。

メリット3：customizationしやすい

Self-hostedではcommunity node、custom node、runtime設定などを自分の要件へ寄せやすくなります。

特殊なlibrary、internal integration、独自nodeが必要な場合、managed Cloudより自由度があります。

メリット4：Cloudの実行上限だけで設計しなくてよい

Community Editionでは自分のserver resourceを基準に運用できます。

もちろんexternal API側のrate limitやinfrastructure capacityはありますが、Cloud planのexecution allocationだけで設計する必要はなくなります。

大量workflowを回す場合でも、infra costとperformanceを自分で最適化できます。

デメリット1：server管理が必要

OS、container、database、storage、network、DNS、TLSなどを自分で管理します。

Dockerで起動するだけなら難しくありませんが、production operationは別です。

restart policy、health check、monitoring、log、backup、restoreまで考える必要があります。

デメリット2：security責任が増える

n8n公式Security pageでは、Self-hosted環境のTLSとdata-at-rest encryptionをself-hoster側で管理する必要があると説明しています。

public internetへ露出する場合はreverse proxy、certificate、firewall、authentication、updateが重要になります。

credentialを保持するautomation serverなので、一般的なinternal tool以上にsecurityを意識すべきです。

デメリット3：update対応が必要

n8nは継続的にversion updateされます。

古いversionを放置するとsecurity issueやintegration compatibilityのriskが増えます。

一方、updateでnode behaviorやdependencyが変わる可能性もあるため、productionではbackupとstaging確認を用意した方が安全です。

デメリット4：backupとrestoreを自分で設計する

workflow、credential、execution data、databaseをどこまでbackupするか決める必要があります。

backupを取っていてもrestore testをしていなければ、障害時に戻せる保証はありません。

Cloudではservice側に寄る運用が、Self-hostedでは自分たちの責任になります。

デメリット5：scale設計も自分で行う

execution数が増えると、single instanceだけでは足りなくなる場合があります。

queue、worker、database、binary storage、concurrencyなどを考える必要があります。

Self-hosted Enterpriseではexternal binary storageなどのscaling featureもありますが、Community Editionと使える機能は同一ではありません。

telemetryはopt-out可能

Self-hostedでも一部Usage Dataはn8nへ送られる場合がありますが、Privacy Policyではopt-out可能と説明されています。

完全に自社environmentへ置くことと、telemetry設定は別なので、privacy requirementが厳しい場合は設定を確認します。

ただし、有料licenseではUsage Dataをopt outしても、license compliance / billing用metadataが別送されます。EULAではEnd User Contentはそのmetadataに含まれないとしています。

licenseも確認する

Community EditionをSelf-hostした場合でもSustainable Use Licenseが適用されます。

Community editionのSULでは、顧客向けworkflowを自社instanceで構築・実行しても、顧客がeditorやlogicへアクセスしない形は許容される場合があります。一方、顧客にworkflowを作成・設定させる、n8nをserviceとしてhostする、white-label化する形はcommercial licenseを確認します。個別条件は現行FAQと契約で判断してください。

Self-hosted＝無条件で自由なcommercial licenseではありません。

Cloudの方が向くケース

次のような場合はCloudの方が運用しやすいです。

infra担当がいない

backupやupdateを持ちたくない

まず小さくautomationを始めたい

network要件が一般的

platform operationよりworkflow作成へ集中したい

月額料金だけでなく、運用工数を含めて比較する必要があります。

Self-hostedが向くケース

一方、

private networkへ接続したい

data locationをcontrolしたい

custom nodeが必要

on-prem requirementがある

infra運用できるteamがいる

場合はSelf-hostedのメリットが大きくなります。

Self-hostedの費用をserver代だけで比べない

Self-hostedでは、n8nを置くserverやdatabaseの料金だけで総費用は決まりません。監視、backup、更新、障害対応、TLS、network、log retention、担当者の時間が必要です。使う機能によってはCommunity Editionと有料Self-hosted planのlicense条件も別に確認します。現在のn8n pricing pageではBusiness planがSelf-hosted onlyとされていますが、利用できるfeatureや契約条件はplan・order formで確認してください。

表は横にスクロールできます

費用・作業	Cloud	Self-hosted
hosting / OS	planに含まれる範囲	server、OS、database、storageを自社負担
backup / restore	providerの範囲とretention	構成、暗号化、世代数、restore test
version update	provider更新と告知	test、互換性試験、rollbackを担当
network / TLS	providerと接続要件	reverse proxy、証明書、firewall
障害対応	support範囲とplan条件	on-call、log、復旧時間を自社定義
license / feature	subscription terms	edition、license key、提供形態を確認

同じ業務で月間負荷を試算する

月間実行数を、業務量から見積もります。平日20日、1日300件の問い合わせ、1件につきworkflowを一回起動するなら通常ケースは約6,000 executionsです。retry、再実行、error workflow、手動再処理の余裕は分けて上乗せします。Cloudは実行枠を確認し、model APIはtoken等の別料金として扱います。Self-hostedなら同じ件数とピーク同時数でCPU、memory、database、diskを試し、必要な運用時間も記録します。

これは料金確定額ではありません。実費はregion、冗長化、storage、backup、AI model、retry率、support条件で変わります。試算表には「仮定」と「確認済み」を分け、契約画面や見積書の金額を採用します。

運用責任を引き受けられるか

Self-hostedへ移る前に、以下の担当者と所要時間を書き出します。

• security advisoryを確認し、影響versionを評価する担当

• test environmentで更新し、本番適用する担当

• backup失敗とdisk逼迫を検知する担当

• databaseとbinary dataを整合した時点へ戻す方法

• credential encryption keyの保管者と復旧方法

• public webhookや管理UIの外部露出を点検する方法

• execution失敗を受け取り手動処理へ戻す担当

• n8nを停止・再起動する権限と顧客通知の手順

「運用チーム」のような曖昧な役割ではなく、role、連絡先、対応期限を置きます。主担当が休みのとき、誰がkeyへアクセスし復旧を判断するかも決めます。

小さく移行する判定手順

1. read-onlyまたは社内test workflowを一つ選ぶ。

2. Cloudで実行数、ピーク同時数、失敗率を一定期間記録する。

3. Self-hosted test instanceで同じinputを再生し、network・credential・logの差を調べる。

4. backupを別環境へrestoreし、workflowとdatabaseの整合性を確認する。

5. updateとrollbackを手順書どおりに試す。

6. 実行担当と障害担当を確保できた場合だけ段階移行する。

restore test未実施、keyの保管者不明、security updateの担当不在があれば、本番移行を先送りする判断が妥当です。移行理由が「Cloudより安そう」だけなら、運用時間と障害時の影響を含めて比較し直します。

AIものさしの判断

n8n Self-hostedの最大のメリットはcostではなくcontrolです。

data、network、runtimeを自分で決められます。

その代わり、security、backup、update、monitoring、scaleも自分で決めなければなりません。

「server代が安いか」ではなく、その運用責任を自分たちで持ちたいかで判断するのが本質です。