n8nのプライバシーとSelf-hosted運用の考え方

n8nのsecurityを考えるとき、CloudとSelf-hostedを同じ条件で見ることはできません。

Cloudではn8n側がhosting、storage、backup、platform securityを管理します。

Self-hostedではdataの置き場所を自分でcontrolできる一方、TLS、disk encryption、update、backup、network securityなどの責任も自分たちへ移ります。

n8n CloudはEUのAzureでhostされている

2026年10月7日に確認した公式Security pageでは、n8n CloudはMicrosoft Azureを利用し、platform dataはEuropean Union内でhostされていると説明されています。

Cloud database、OAuth token、key-based credential、backupは暗号化され、storage encryptionにはAES-256が使われています。

通信もTLSで保護されます。

Cloudではplatform securityをn8n側が管理する

n8nはSOC 2に沿ったsecurity programを運用し、SOC 3 reportも公開しています。

network control、WAF、intrusion detection、backup、disaster recovery、security loggingなどをn8n側が管理します。

自分でserverをmaintenanceしたくない場合、Cloudを使う理由は単なるinstall不要だけではありません。

security operationもservice側へ寄せられます。

Self-hostedでは責任範囲が大きく変わる

Self-hostedでもn8n user passwordはsalt / hashされます。

しかし公式Security pageでは、その他のdata-at-rest encryptionはself-hoster側の責任とされています。

またTLSについても、reverse proxyなどを用意してHTTPS化する必要があります。

「自社serverに置けば安全」ではなく、自社で安全に運用できることが前提です。

credentialsの扱いは特に重要

n8nは外部serviceへ接続するためOAuth tokenやAPI keyを保持します。

workflow本体だけでなく、このcredential storeが攻撃対象になります。

Self-hostedでは、

instanceをpublic internetへ不用意に公開しない

strong authenticationを使う

不要なportを閉じる

backupを保護する

secretをrepositoryへ置かない

といった基本運用が重要です。

security auditを実行できる

n8nにはsecurity audit機能があります。

CLI、API、n8n nodeからauditを実行し、

unused credentials

database query上のrisk

file system access

risky nodes

community / custom nodes

unprotected webhooks

missing security settings

outdated instance

などを確認できます。

Self-hostedでは定期的にauditを回す価値があります。

Self-hostedでもusage telemetryはある

n8n Privacy Policyでは、Self-hosted deploymentでも初期状態では一部Usage Dataをn8nへ送信する場合があると説明しています。

対象にはuser identifier、account setting、user event、workflow usage metric、enabled integrationなどが含まれます。

このtelemetryはDocsに従ってopt outできます。

有料licenseを使う場合、Usage Dataをopt outしても、EULAではlicense compliance / billing用のlicensing metadataを別送するとしています。End User Contentはそのmetadataに含まれないため、「opt outで全通信が止まる」とは言えません。

Self-hostedだからn8n側へ一切metadataが送られない、と決めつけない方が安全です。

n8nは個人dataをAI trainingへ使わないと説明している

2026年10月9日に確認したPrivacy Policyでは、personal dataやthird-party serviceから受け取ったdataをAI / ML modelの開発・改善・trainingへ使用しないと説明しています。

ただしworkflow内から外部AI providerを呼ぶ場合は別です。

OpenAI、Anthropic、Googleなどへ送ったdataは、それぞれのprovider契約・privacy policyに従います。

Self-hostedでも第三者serviceへdataは出る

n8n本体を自社serverへ置いても、workflowで外部APIを呼べばdataはそのserviceへ送られます。

たとえばSelf-hosted n8nからOpenAI APIへcustomer dataを送れば、n8nのhosting場所だけでprivacyは完結しません。

data flow全体を図にして確認する方が安全です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  n8n

  公式サイトを見るTool詳細を見る

community nodeもriskになる

Self-hostedではcommunity nodeやcustom nodeを追加できます。

自由度は高い一方、nodeがfile system、network、credentialへどこまでaccessできるかを確認する必要があります。

security auditでもcommunity / custom nodeがrisk reportの対象になります。

先に決めるdata境界

「Self-hostedならdataは安全」と一言では決められません。serverを自社で管理しても、workflowが接続する外部API、通知先、execution log、backup、monitoring基盤へ情報が流れることがあります。まず一つのworkflowを選び、何がどこへ移るかを書き出します。

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

場所	確認するもの	決める担当
Trigger	webhook URL、入力値、認証、公開範囲	workflow owner
n8n database	workflow設定、credential、execution data	instance operator
AI provider	prompt、添付、output、保持条件	data owner / legal
接続API	OAuth scope、作成・更新可能なresource	integration owner
Logs / monitoring	request body、error detail、識別子	security owner
Backup / archive	保存先、暗号化、世代数、復元権限	infra owner

n8n公式SecurityページはCloudのhostingや保存の説明を掲載しますが、その説明をSelf-hostedへそのまま適用できません。Self-hostedではOS、network、database、暗号化、backup、patchingを運用者が確認します。外部AI providerのdata handlingも、n8nのhosting設定だけでなくprovider側の契約・設定が対象です。

セキュリティ台帳を埋める

分からない項目は「確認済み」にせず、担当者と期限を置きます。

• 公開URLと管理UIへ接続できるnetwork範囲

• n8n version、更新担当、security advisoryの確認頻度

• admin・editor・viewerのaccountとMFA条件

• master encryption keyの保管・rotation・復旧方法

• database / binary dataの保存場所とbackup暗号化

• OAuth refresh token、API key、webhook secretのaccess権

• execution dataの保存期間、cleanup、log masking

• community nodeやCode nodeを追加できる人

• TLS終端、reverse proxy、firewall

• 障害時に誰がinstanceを止め、どのbackupから戻すか

workflow単位で最小権限にする

Workflow AがGmailの問い合わせを読み、分類結果をSheetへ追加するなら、Gmailの読み取りとSheetの行追加だけを許可します。メール削除、Drive全体、Sheetの任意編集まで必要とは限りません。test credentialとproduction credentialを分け、共有accountでも担当者を追跡できる状態を残します。

AIへ送るdataは用途に必要な項目に絞ります。顧客名や連絡先が不要なら送信前に除き、prompt、output、execution historyのどこに残るか確かめます。debugのためfull payloadを長期保存すると、便利さと個人情報の露出範囲が同時に増えます。本文を伏せ、event idとerror codeだけ残す方法も検討します。

事故と復旧を小さく試す

test instanceで、管理者credential失効、外部API timeout、database容量不足を想定します。「どのalertを受けるか」「同じ処理を安全に再開できるか」「queueに残った実行を誰が判断するか」「顧客へ重複連絡しないか」を確認します。backupがあるだけでは復旧可能とは言えません。空のtest環境へrestoreし、credential、workflow、dataの復元範囲を記録します。

有効化前の判断

本番前の合格条件は、すべてのriskがゼロであることではなく、risk、担当者、期限、暫定策が明示されていることです。未管理のpublic webhook、復元できないdatabase、担当者のいないsecurity updateが残るなら、機密dataを扱うworkflowを有効化しないでください。管理責任を引き受ける体制がない場合、Cloudを選ぶか、より限定された業務から試す判断もあります。

AIものさしの判断

data controlを最優先するならSelf-hostedは強力です。

ただし、それは「securityをn8nへ任せず、自分たちで持つ」選択でもあります。

Cloudではplatform securityをn8n側へ寄せる。

Self-hostedではnetwork、TLS、storage、backup、update、access controlを自分たちで設計する。

この責任分界を理解して選ぶことが重要です。