エディターを保護
エディターをHTTPSとサポート対象の認証の背後に配置してください。管理者アクセスを制限し、不要な場合は公開登録を避けてください。Webhookルートには、独自の公開と認証の判断が必要です。
認証情報キーを保持する
構成済みの暗号化キーを適切な保護のもとでバックアップしてください。正しいキーなしでデータベースを復元すると、保存された認証情報が使用できなくなる可能性があります。キーをスクリーンショット、リポジトリ、フィルタリングされていないログに残さないでください。
実行パスを意図的にスケールする
多忙な構成では、サポートされるデータベース、キュー、ワーカーモデルを確認してください。Redisと個別のワーカーは、それぞれ独自のアクセス要件と永続化要件を追加します。急増時にVPSや外部のAPI予算を使い果たさないよう、同時ジョブを制限してください。
有用な実行データのみを保持する
ワークフローはトークン、個人記録、ドキュメントを扱えます。実行履歴の削除、機密値の秘匿、リトライの定義を慎重に行ってください。Webhookの重複が、意図しない2回目の支払いやメッセージを引き起こしてはなりません。
暗号化キーをデータベースの一部として扱う
保存された認証情報はn8nの暗号化キーに依存します。自動生成されたキーを含む状態ディレクトリを保持するか、非公開のシークレットストアからN8N_ENCRYPTION_KEYを設定してください。すべてのキューワーカーはメインプロセスと同じキーを必要とします。使い捨ての認証情報で復元をテストしてください。復元されたデータベースだけでは正常に見えても、認証情報が読めないままの可能性があります。
- 鍵は公開ディレクトリとリポジトリの外に保管する
- データベースを一貫してバックアップする
- 本番環境での導入には、サポート対象のPostgreSQLを使用してください
公式ドキュメント: n8n 暗号化キー設定
Webhookに公開アドレスを設定する
CaddyなどのリバースプロキシがHTTPSを終端し、n8nは内部で待ち受けることができます。現在のドキュメントでは外部WebhookオリジンにN8N_WEBHOOK_URLを使用し、バージョン2.35.0の古いWEBHOOK_URL名を置き換えています。信頼するプロキシホップ数を実際の経路に設定してください。単一プロキシではN8N_PROXY_HOPS=1を使用します。転送されたホスト、プロトコル、クライアント情報を保持してください。サーバー外部からWebhookをテストし、その本番URLを確認してください。
- ワークフローのタイムゾーンを意図的に設定する
- 機密入力を含む実行履歴を削除する
- キュー ワーカーと Redis は、必要なプライベート アクセス制御がある場合にのみ使用してください
# Example: one HTTPS reverse proxy
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1公式ドキュメント: リバースプロキシ背後の n8n
ワークロードと許可される連携を定義する
トリガー、外部アカウント、想定される実行量、および各ワークフローが生み出し得る最大の支出または副作用を洗い出してください。実際の用途について n8n ライセンスを確認してください。特に他者へのサービスとして提供する場合は重要です。小規模なスケジュール済みワークフローと公開 Webhook プロセッサでは、必要なリソースが異なります。サポートされているリリース、プライベートで永続的な状態、TLS 名、およびデプロイに適したデータベースから始めてください。エディタでデータベースのポートを公開しないようにしてください。
- 各統合に個別の制限付き認証情報を使用してください。
- 想定するワークフローのタイムゾーンと実行履歴の保持期間を設定します。
- エクスポートしたワークフローには、実際のシークレットを埋め込まないでください。
公式ドキュメント: n8n Docker デプロイ
インストール済みリリースの公開Webhookオリジンを設定する
Caddyなどのリバースプロキシはn8nに内部的に到達し、外部サービスはそのHTTPS Webhookオリジンを呼び出します。インストール済みリリース向けに文書化されたWebhook URL変数を使用してください。現在のドキュメントではN8N_WEBHOOK_URLと命名されていますが、古いリリースではWEBHOOK_URLが使われていました。任意の転送ヘッダーを信頼せず、実際のプロキシホップ数を設定してください。エディターのアクセスポリシーをWebhook認証と分離し、本番コールバックに内部ホストやポートが含まれていないことを確認してください。
# Example values for a supported current release, behind one proxy:
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1公式ドキュメント: n8n Webhookリバースプロキシ設定
書き込みアクセスを付与する前に無害なワークフローをテストする
読み取り専用のリクエストまたは使い捨てのテストレコードから始めてください。VPS の外部から本番Webhookをテストし、認証拒否と意図的なリトライを確認してください。繰り返しのリクエストが誤って2回目の重大なアクションを発生させてはなりません。実行ログに漏えいした入力がないか確認し、保持ポリシーを適用してください。Webhookがエディターのテストモードでのみ機能する場合は、ワークフローが公開・有効になっているか、本番とテストの経路が正しいプロセスに到達しているかを確認してください。
- 使い捨ての統合認証情報を使用して復元をテストしてください。
- N8N_ENCRYPTION_KEY または生成されたキー状態の独立した暗号化コピーを保管してください。
- サンプルのパスワードやAPIトークンを、保持されるデバッグ出力に送信しないでください。
公式ドキュメント: n8n暗号化キー
実行時のボトルネックを確認してからスケールする
キューモードはRedis、ワーカー、共有データベースを追加します。メインプロセスがトリガーを受信し、ワーカーが実行を担います。すべてのワーカーが同じ認証情報暗号化キーを使用する必要があります。ファイルを含むワークフローをキューモードへ移行する前に、現在のバイナリデータストレージ要件に従ってください。同時実行数と上流のAPI予算を制限し、キューの滞留時間と失敗を監視してください。データベース、状態、キーをまとめてバックアップしてください。コンテナの再起動は、読み取れない保存済み認証情報に対する復旧計画ではありません。
公式ドキュメント: n8n キューモード · 実行履歴の削除設定