n8nセルフホスティング完全トラブルシューティングガイド2025：Traefikでの実行データサイズとWebhookの問題を解決する

最終更新： 2025年10月15日

n8nのセルフホスティングは、無制限のワークフロー実行、完全なデータ管理、クラウドプランと比較した大幅なコスト削減を実現します。しかし実際には、セルフホスト型インスタンスは、n8n Cloudのユーザーは通常自分で対処する必要のない課題に直面します。特に大規模なデータ処理とリバースプロキシを使用したWebhook設定に関する問題です。

2025年6月、当社はこれらの問題をそれぞれ別々に解決する2つのトラブルシューティングガイドを公開しました。問題は、Traefikリバースプロキシを使用したn8nの本番環境へのデプロイについて、よくある2つの問題をまとめて解決する包括的なガイドが存在しなかったことです。

このガイドでは、元の2つの修正方法を組み合わせ、WebSocketサポート付きの完全なTraefik設定を提供し、2025年の新しいタスクランナー要件を含め、すぐにデプロイできる本番環境対応のdocker-composeファイルを提供します。

クイック診断：どの問題が発生していますか？
2つの主な問題を理解する
修正#1：実行データが大きすぎるエラー
修正#2：Webhook URLの問題
Traefikを使用した完全な本番セットアップ
2025年の要件：タスクランナー
環境変数リファレンス
Docker Composeの例
セットアップのテスト
よくある問題のトラブルシューティング

クイック診断：どの問題が発生していますか？

症状：「Existing execution data is too large」

このエラーが表示される状況：

ワークフロー開発中に「Execute Node」をクリックした時
大規模なデータセットや多数のアイテムでワークフローをテストしている時
部分実行モード（個々のノードのテスト）を使用している時
複数のブランチを持つ複雑な変換を処理している時

必要な修正： 修正#1：実行データサイズ

症状：WebhookのURLが正しくない、または機能しない

この問題が発生する状況：

Webhook URLにポート番号が表示される（例：:5678）
外部サービス（Slack、GitHub、Stripe）がWebhookに到達できない
テストモードでは動作するが本番モードで失敗する
リバースプロキシ（Nginx、Traefik、Caddy）を使用している

必要な修正： 修正#2：Webhook URL設定

症状：タスクランナーに関する非推奨の警告

ログに以下が表示される：

Running n8n without task runners is deprecated. Task runners will be
turned on by default in a future version.

必要な修正： タスクランナー設定

症状：完全な本番環境対応のセットアップが必要

必要なもの：

両方の修正が正しく適用されていること
自動HTTPSを備えたTraefikリバースプロキシ
本番環境のベストプラクティスとセキュリティ
リソース制限と適切なモニタリング

移動先： 完全な本番セットアップ

2つの主な問題を理解する

n8n Cloudのユーザーがこれらの問題に対処することが少ない理由

n8n Cloudでは、Webhook URL、バイナリデータストレージ、更新などのサーバー設定をn8nが管理します。セルフホスティングでは、これらの設定を自分で管理する必要があります。

根本原因

問題#1：実行データサイズの制限

部分実行データを含め、バックエンドに送信されるリクエストペイロードのデフォルト16 MiB制限は、大規模なデータセット、多数のワークフローブランチ、複雑な変換の処理時にエラーを引き起こします。問題は、ワークフロー開発が困難になることです。開発中に個々のノードをテストできません。修正は簡単です：環境変数N8N_PAYLOAD_SIZE_MAXを使用します。

問題#2：Webhook URLの生成

n8nはパブリックURLを自動検出しようとしますが、リバースプロキシの背後ではこの自動検出が失敗します。外部サービスはポートや内部ホスト名を含む誤ったWebhook URLを受け取り、エラーが表面化しないまま連携が機能しなくなります。修正：環境変数WEBHOOK_URLを使用します。

修正#1：実行データが大きすぎるエラー

問題の詳細

ワークフローの一部のみを実行する場合（エディターで「Execute Node」をクリック）、n8nはそのノードにコンテキストを提供するために以前の実行データを読み込む必要があります。デフォルトでは、n8nは小規模なサーバーでメモリの問題が起きないように、このリクエストを16 MiBに制限しています（N8N_PAYLOAD_SIZE_MAX=16、値の単位はMiB）。これを超えると、n8n（またはボディサイズの上限がより小さいリバースプロキシ）がHTTP 413を返し、エディターにこのエラーが表示されます。

エラーメッセージ

n8n公式ドキュメントによると：

Please execute the whole workflow, rather than just the node.
(Existing execution data is too large.)

このエラーは、単一のノードで数千のアイテムを処理する時、大きなJSON APIレスポンスを処理する時、Codeノードで大規模なデータセットを変換する時、多数の並列ブランチを持つワークフローを使用する時に発生します。

解決策：N8N_PAYLOAD_SIZE_MAX

修正はシンプルですが、サーバーの利用可能なリソースを理解する必要があります。

サーバーのRAM容量別の推奨設定

サーバーRAM	N8N_PAYLOAD_SIZE_MAX	設定する値（MiB）	RAMの割合
2GB以下	64MB	`64`	約3%
4GB	128MB	`128`	約3%
8GB	256MB	`256`	約3%
16GB以上	512MB	`512`	約3%

目安： 負荷時にシステムを安定させるため、利用可能なRAMの20%未満を使用してください。

Docker Composeの実装

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_PORT=5678

      # Payload size fix (256MB for 8GB+ RAM servers; value in MiB)
      - N8N_PAYLOAD_SIZE_MAX=256

      # Binary data optimization (highly recommended)
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_BINARY_DATA_TTL=1440  # 24 hours

    volumes:
      - n8n_data:/home/node/.n8n

    # Resource limits (adjust based on your server)
    deploy:
      resources:
        limits:
          memory: 2G
        reservations:
          memory: 1G

volumes:
  n8n_data:

バイナリデータモードの理解

デフォルト：メモリ内ストレージ（非推奨）

# This is the default - DON'T use in production
N8N_DEFAULT_BINARY_DATA_MODE=default

問題点： ファイル（画像、PDFなど）をRAMに保存し、貴重なメモリを浪費します。本番ワークロードには適しておらず、処理できるファイル数が制限されます。

テスト結果では、アイドル時のRAM使用量はデフォルトモードで約315MB、ファイルシステムモードで211MBでした。つまり、アイドル時のメモリ使用量が約100MB少ないという結果です。

推奨：ファイルシステムストレージ

N8N_DEFAULT_BINARY_DATA_MODE=filesystem
N8N_BINARY_DATA_TTL=1440  # Clean up after 24 hours (value in minutes)

利点： RAMではなくディスクにファイルを保存し、大きなファイルのパフォーマンスが大幅に向上します。本番環境対応でn8nが推奨しています。ただし、N8N_BINARY_DATA_TTLはn8n 1.9.0以降は効果がありません。n8nは実行データの削除時にバイナリデータも削除するため、ディスク使用量は実行データの自動削除設定で制御します。

重要： キューモード（Redisベースの分散実行）では、n8nはファイルシステムモードをサポートしていません。2026年10月時点のn8nドキュメントでは、キューモードにdatabaseモードを推奨しています。

実運用への影響

2025年10月のn8nバージョン1.115.2でのDockerテストから：

設定	メモリ使用量	差異
デフォルト（修正なし）	315 MB	ベースライン
ペイロード修正 + ファイルシステム保存モード	211 MB	-104 MB

主な発見： アイドル時の測定では、ペイロード設定の修正とファイルシステムのバイナリモードを適用した構成は、デフォルトより少ないメモリを使用しました。大きなペイロードを処理する負荷がかかった状態では測定していません。その場合の使用量はワークフローに依存します。

修正#2：Webhook URLの問題

問題の詳細

n8nがエディターに表示し、外部サービスに登録するためのWebhook URLを生成する際、パブリックURLを自動検出しようとします。リバースプロキシの背後では、この自動検出が完全に失敗します。

表示される内容（誤ったURL）

http://n8n.yourdomain.com:5678/webhook/abc123

このURLの問題：

ポート番号が含まれている（:5678）– 外部サービスは通常、非標準ポートに到達できません
プロトコルが間違っている（httpとhttps）– 多くのサービスはHTTPSを必要とします
内部ホスト名：パブリックドメインではなくDockerコンテナ名が表示される場合があります

外部サービスが失敗する理由

GitHub、Slack、Stripe、Zoom、Google Sheetsなどのサービスは、これらの誤ったURLにWebhookを送信しようとしてエラーが表面化しないまま失敗します。連携を設定し、UIでは正しく見えても、通知が届きません。

解決策：WEBHOOK_URL環境変数

n8n公式ドキュメントによると：

「WEBHOOK_URL環境変数は、n8nがエディターUIに表示し、外部サービスに正しいWebhook URLを登録できるように、Webhook URLを手動で設定するために使用されます。n8nをリバースプロキシの背後で実行する場合、この変数を設定することが重要です。」

基本設定

environment:
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - N8N_PROTOCOL=https
  - N8N_HOST=n8n.yourdomain.com
  - N8N_TRUST_PROXY_HEADER=true
  - N8N_PROXY_HOPS=1

各変数の役割

WEBHOOK_URL（最も重要）

すべてのWebhookエンドポイントのパブリックURL
外部サービスにWebhookを登録する際に使用されます
Traefik/リバースプロキシの設定と正確に一致する必要があります
バージョンに関する注意： v0.227.0でWEBHOOK_TUNNEL_URLから名前が変更され、旧名はn8n 1.0で削除されました

N8N_EDITOR_BASE_URL

n8nのWebインターフェースにアクセスするためのURL
通常はWEBHOOK_URLと同じです
ブラウザーのアドレスバーやメール招待に表示されます

N8N_PROTOCOL

本番環境ではhttpsに設定します（SSL/TLS使用時）
ローカルテスト時のみhttpに設定します
リバースプロキシの終端と一致する必要があります

N8N_HOST

パブリックドメイン名のみ
プロトコル（https://）やポートは含めないでください
例：n8n.yourdomain.com（https://n8n.yourdomain.com:443ではない）

N8N_TRUST_PROXY_HEADER

n8nのドキュメントに記載されていない変数： n8nの環境変数リファレンスに掲載されておらず、設定による効果は文書化されていません
プロキシヘッダーの信頼（実際のクライアントIPアドレスの取得）はN8N_PROXY_HOPSで制御します
このガイドの設定例では省略できます

N8N_PROXY_HOPS

1つのリバースプロキシの背後にある場合は1に設定します
2つのプロキシの背後にある場合は2に設定します（まれ）
信頼するプロキシレイヤーの数をn8nに通知します

Webhook URLのテスト

修正前

n8n UIでWebhookノードを作成し、表示されるURLを確認します：

http://n8n.example.com:5678/webhook/abc123  ❌ 間違い

修正後

同じWebhookノードに以下が表示されます：

https://n8n.example.com/webhook/abc123  ✅ 正しい

重要な違い： 内部ポート5678ではなく標準のHTTPSポート443（リバースプロキシで処理）を使用するため、外部サービスがこのURLに到達できるようになります。

Traefikを使用した完全な本番セットアップ

なぜTraefikなのか？

Traefikは、Dockerデプロイに最適な現代的なリバースプロキシです。手動の証明書管理不要のLet's Encryptによる自動HTTPS、Dockerラベルを介したコンテナの自動検出によるサービス検出、n8nエディターのライブ接続に対応するネイティブなWebSocketサポート、複雑な設定ファイルではなくDockerラベルだけで行える簡単な設定、ルーティングと証明書をリアルタイムで監視する組み込みダッシュボードを提供します。

アーキテクチャ概要

Internet
  ↓
[Traefik Reverse Proxy]
  ↓ HTTPS (Let's Encrypt)
  ↓ WebSocket Support
[n8nコンテナ]
  ↓ 内部ネットワーク
[PostgreSQLデータベース]

WebSocketサポート

TraefikはWebSocket接続を標準でプロキシします。n8nエディターのライブ接続も含まれるため、追加のミドルウェアは不要です。Webhookは通常のHTTPSリクエストであり、WebSocketには依存しません。以下の本番環境の設定例には任意のWebSocketヘッダーラベルが含まれていますが、省略できます。

完全な本番Docker Compose

この設定は両方の修正を組み合わせ、適切なWebSocketサポート付きのTraefikを含み、本番環境のベストプラクティスに従っています：

version: '3.8'

networks:
  traefik-net:
    external: true
  n8n-internal:
    internal: true

services:
  # PostgreSQL Database
  postgres:
    image: postgres:16-alpine
    container_name: n8n-postgres
    restart: unless-stopped
    networks:
      - n8n-internal
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 5
    deploy:
      resources:
        limits:
          memory: 512M

  # n8n Application
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - traefik-net
      - n8n-internal

    # Traefik Configuration Labels
    labels:
      # Enable Traefik for this container
      - "traefik.enable=true"
      - "traefik.docker.network=traefik-net"

      # Router configuration
      - "traefik.http.routers.n8n.rule=Host(`${N8N_DOMAIN}`)"
      - "traefik.http.routers.n8n.entrypoints=websecure"
      - "traefik.http.routers.n8n.tls.certresolver=letsencrypt"

      # Service configuration
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

      # Middleware: Request size limit in bytes (256MB, matches N8N_PAYLOAD_SIZE_MAX)
      - "traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=268435456"

      # Middleware: WebSocket headers (optional; Traefik proxies WebSockets natively)
      - "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Upgrade=websocket"
      - "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Connection=Upgrade"

      # Middleware: Security headers
      - "traefik.http.middlewares.n8n-security.headers.customResponseHeaders.X-Robots-Tag=noindex,nofollow"
      - "traefik.http.middlewares.n8n-security.headers.sslProxyHeaders.X-Forwarded-Proto=https"

      # Apply ALL middlewares
      - "traefik.http.routers.n8n.middlewares=n8n-buffering,n8n-websocket,n8n-security"

    environment:
      # Database Configuration
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}

      # FIX #2: Webhook URL Configuration
      - WEBHOOK_URL=https://${N8N_DOMAIN}
      - N8N_EDITOR_BASE_URL=https://${N8N_DOMAIN}
      - N8N_PROTOCOL=https
      - N8N_HOST=${N8N_DOMAIN}
      - N8N_PORT=5678
      - N8N_TRUST_PROXY_HEADER=true
      - N8N_PROXY_HOPS=1

      # FIX #1: Payload Size Configuration
      - N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB

      # Binary Data Management
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_BINARY_DATA_TTL=1440  # 24 hours

      # 2025 Requirement: Task Runners
      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNERS_MODE=internal
      - N8N_RUNNERS_MAX_CONCURRENCY=5

      # Production Optimizations
      - NODE_ENV=production
      - EXECUTIONS_DATA_MAX_AGE=168  # 7 days
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
      - N8N_LOG_LEVEL=info
      - N8N_LOG_OUTPUT=console

      # Timezone (adjust to your location)
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York

      # Security
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

    volumes:
      - n8n_data:/home/node/.n8n

    # Resource Limits (8GB+ RAM server)
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2.0'
        reservations:
          memory: 1G
          cpus: '1.0'

    # Health Check
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:5678/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

volumes:
  n8n_data:
  postgres_data:

Traefikのセットアップ

Traefikをまだ実行していない場合、完全なセットアップは以下の通りです：

ステップ1：Traefikネットワークの作成

docker network create traefik-net

ステップ2：Traefik設定の作成

traefik/traefik.ymlを作成します：

api:
  dashboard: true

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
  websecure:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
    network: traefik-net

certificatesResolvers:
  letsencrypt:
    acme:
      email: [email protected]  # CHANGE THIS
      storage: /letsencrypt/acme.json
      httpChallenge:
        entryPoint: web

log:
  level: INFO

accessLog: {}

ステップ3：Traefik Docker Composeの作成

traefik/docker-compose.ymlを作成します：

version: '3.8'

networks:
  traefik-net:
    external: true

services:
  traefik:
    image: traefik:v2.10
    container_name: traefik
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    networks:
      - traefik-net
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"  # Dashboard (secure this in production!)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yml:/traefik.yml:ro
      - ./letsencrypt:/letsencrypt
    labels:
      - "traefik.enable=true"

ステップ4：環境ファイルの作成

n8nディレクトリに.envを作成します：

# Domain Configuration
N8N_DOMAIN=n8n.yourdomain.com

# Database Password (generate secure password)
DB_PASSWORD=your_secure_db_password_here

# n8n Encryption Key (generate random string)
N8N_ENCRYPTION_KEY=your_encryption_key_here

安全な値の生成：

# For DB_PASSWORD
openssl rand -base64 32

# For N8N_ENCRYPTION_KEY
openssl rand -hex 32

ステップ5：すべてを起動する

# Start Traefik first
cd traefik
docker compose up -d

# Wait a few seconds, then start n8n
cd ../n8n
docker compose up -d

# Watch logs to verify startup
docker compose logs -f n8n

セットアップの確認

Traefikダッシュボードの確認

http://your-server-ip:8080にアクセスします。これは、traefik.ymlでapi.insecure: trueも設定した場合のみ機能します（テスト専用）。それ以外の場合は、専用ドメインにダッシュボード用ルーター（api@internal）を設定してください。

以下が表示されるはずです：

✅ n8nルーターが緑色のステータスで稼働中
✅ Let's Encryptから証明書を取得済み
✅ サービスが正常と表示

n8nアクセスの確認

https://n8n.yourdomain.comにアクセスします

以下が表示されるはずです：

✅ 有効なLet's Encrypt証明書でHTTPSが動作
✅ ブラウザーのセキュリティ警告なし
✅ n8nのログイン/セットアップページが正しく表示

Webhook URLの確認

n8nにログインします
新しいワークフローを作成します
Webhookノードを追加します
表示される「Production URL」を確認します

期待される形式：

https://n8n.yourdomain.com/webhook/abc123

次の形式は設定エラーを意味します：

http://n8n.yourdomain.com:5678/webhook/abc123  ❌

2025年の要件：タスクランナー

タスクランナーとは

タスクランナーは、メインのn8nプロセスではなく、分離されたプロセス内でCodeノードに定義されたコードを実行します。これにより、サンドボックス環境によるセキュリティの向上、コードエラーがメインプロセスの停止を防ぐ安定性の向上、今後のn8nバージョンで必須になることを見据えた互換性が提供されます。

なぜ今重要なのか

n8n公式ドキュメントより：

「タスクランナーなしでn8nを実行することは非推奨です。タスクランナーは将来のバージョンでデフォルトで有効になります。将来的な問題を回避するため、今すぐN8N_RUNNERS_ENABLED=trueを設定することをお勧めします。」

当社のテストログ（2025年10月）より：

There are deprecations related to your environment variables:
 - N8N_RUNNERS_ENABLED -> Running n8n without task runners is deprecated.

設定

内部モード（単一サーバーに推奨）

environment:
  - N8N_RUNNERS_ENABLED=true
  - N8N_RUNNERS_MODE=internal
  - N8N_RUNNERS_MAX_CONCURRENCY=5

n8nは子プロセスとしてタスクランナーを起動します。最もシンプルな構成で、追加のインフラストラクチャは不要です。ほとんどのセルフホスト型環境へのデプロイに適しており、性能面の追加負荷は最小限です。 2026年10月時点のn8nドキュメントでは、内部モードは設計上安全ではないと説明されており、n8n 3.0以降は非推奨とされています。

外部モード（分散セットアップ用）

environment:
  - N8N_RUNNERS_ENABLED=true
  - N8N_RUNNERS_MODE=external
  - N8N_RUNNERS_AUTH_TOKEN=your_secure_token

個別のタスクランナーコンテナは、大量のワークフローでリソース分離を強化し、複数サーバーでの水平スケーリングを可能にします。n8nio/runnersイメージからサイドカーコンテナとして実行し、そのバージョンはn8nイメージと一致させる必要があります。Docker Composeの構成で十分であり、Docker SwarmやKubernetesは不要です。

タスクランナーの確認

プロセスリストの確認

docker exec n8n ps aux

タスクランナーなし（3プロセス）：

PID   USER     TIME  COMMAND
    1 node      0:00 tini -- /docker-entrypoint.sh
    7 node      0:12 node /usr/local/bin/n8n

タスクランナーあり（4プロセス）：

PID   USER     TIME  COMMAND
    1 node      0:00 tini -- /docker-entrypoint.sh
    7 node      0:16 node /usr/local/bin/n8n
   18 node      0:10 node [...]/task-runner/dist/start.js

確認結果：タスクランナープロセスがPID 18で確認できます。

ログの確認

docker logs n8n | grep -i runner

以下が表示されるはずです：

n8n Task Broker ready on 127.0.0.1, port 5679
Registered runner "JS Task Runner" (zCWpF0Eb_LJsqWYvLm5t1)

リソース使用量への影響

当社のDockerテスト（2025年10月、n8nバージョン1.115.2）より：

設定	メモリ	CPU	プロセス
タスクランナーなし	214 MB	0.14%	3
タスクランナーあり	289 MB	0.29%	4
差異	+75 MB	+0.15%	+1

追加の負荷はわずかです。セキュリティ、安定性、将来への対応という利点は、わずかなリソースコストをはるかに上回ります。

環境変数リファレンス

環境変数の一覧

変数	型	デフォルト	目的	優先度
重要な変数
`WEBHOOK_URL`	String	–	パブリックWebhook URL	リバースプロキシ使用時必須
`N8N_PAYLOAD_SIZE_MAX`	Number	`16` (MiB)	部分実行データを含むリクエストペイロードの最大サイズ（MiB）	大規模データの場合必須
`N8N_RUNNERS_ENABLED`	Boolean	`false`	タスクランナーの有効化	1.xでは推奨（n8n 2.0以降は不要）
`N8N_TRUST_PROXY_HEADER`	–	–	n8nのドキュメントに記載された変数ではありません	不要。`N8N_PROXY_HOPS`を使用
Webhook設定
`N8N_EDITOR_BASE_URL`	String	–	エディターUI URL	推奨
`N8N_PROTOCOL`	String	`http`	プロトコル (http/https)	本番環境
`N8N_HOST`	String	`localhost`	パブリックホスト名	本番環境
`N8N_PORT`	Number	`5678`	内部ポート	オプション
`N8N_PROXY_HOPS`	Number	`0`	リバースプロキシの数	プロキシ使用時1に設定
パフォーマンス
`N8N_DEFAULT_BINARY_DATA_MODE`	String	`default`	バイナリストレージモード	推奨
`N8N_BINARY_DATA_TTL`	–	–	n8n 1.9.0以降は効果なし（バイナリデータは実行データとともに削除）	削除可能
タスクランナー
`N8N_RUNNERS_MODE`	String	`internal`	タスクランナーモード	ランナー有効時
`N8N_RUNNERS_MAX_CONCURRENCY`	Number	`10`	ランナーあたりの最大同時タスク数	オプション

シナリオ別設定プリセット

シナリオA：開発（ローカルマシン）

environment:
  - N8N_PORT=5678

用途： ローカルテスト、リバースプロキシなし、本番要件なし

シナリオB：リバースプロキシの背後（大規模データなし）

environment:
  - N8N_PORT=5678
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - N8N_PROTOCOL=https
  - N8N_HOST=n8n.yourdomain.com
  - N8N_TRUST_PROXY_HEADER=true
  - N8N_PROXY_HOPS=1
  - N8N_RUNNERS_ENABLED=true

用途： パブリックn8nインスタンス、Webhookが必要、小規模ワークフロー

シナリオC：完全な本番セットアップ

environment:
  # Database
  - DB_TYPE=postgresdb
  - DB_POSTGRESDB_HOST=postgres
  - DB_POSTGRESDB_PORT=5432
  - DB_POSTGRESDB_DATABASE=n8n
  - DB_POSTGRESDB_USER=n8n
  - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}

  # Webhooks
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - N8N_PROTOCOL=https
  - N8N_HOST=n8n.yourdomain.com
  - N8N_PORT=5678
  - N8N_TRUST_PROXY_HEADER=true
  - N8N_PROXY_HOPS=1

  # Performance
  - N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
  - N8N_BINARY_DATA_TTL=1440

  # Task Runners
  - N8N_RUNNERS_ENABLED=true
  - N8N_RUNNERS_MODE=internal
  - N8N_RUNNERS_MAX_CONCURRENCY=5

  # Production
  - NODE_ENV=production
  - EXECUTIONS_DATA_MAX_AGE=168  # 7 days
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - N8N_LOG_LEVEL=info

  # Security
  - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

用途： すべての機能を備えた本番デプロイ、大規模ワークフロー、パブリックアクセス

Docker Composeの例

テスト環境の4つのシナリオすべてが利用可能です。これらの設定は、2025年10月にn8nバージョン1.115.2で検証されています。設定例はlatestイメージタグを使用しています。検証済みのバージョンを再現するには、n8nio/n8n:1.115.2に固定してください。

リソース使用量の比較（当社テスト結果）

シナリオ	メモリ	CPU	プロセス	説明
デフォルト	315 MB	0.00%	3	修正なし、ベースライン
ペイロード修正	211 MB	0.00%	3	ペイロード + ファイルシステム保存モード
Webhook修正	215 MB	0.14%	3	Webhook設定のみ
本番環境	289 MB	0.29%	4	全修正 + タスクランナー

主な発見： テストのアイドル時には、すべての修正を適用した本番構成はデフォルト構成より少ないメモリを使用しました。これはアイドル時の測定値であり、大きなペイロードを処理する負荷がかかった状態での結果ではありません。

セットアップのテスト

デプロイ前チェックリスト

1. DNS設定

# Verify DNS points to your server
nslookup n8n.yourdomain.com

# Should return your server's public IP

2. ポートが利用可能か確認

# Check if required ports are free
sudo netstat -tlnp | grep -E '(80|443|5678)'

# Should show nothing or only Traefik on 80/443

3. Dockerのインストール

# Verify Docker
docker --version

# Verify Docker Compose
docker compose version

4. 環境変数

# Verify .env file exists
cat .env

# Should show N8N_DOMAIN, DB_PASSWORD, N8N_ENCRYPTION_KEY

デプロイ手順

# Step 1: Create Traefik network
docker network create traefik-net

# Step 2: Start Traefik
cd traefik
docker compose up -d

# Step 3: Wait for Traefik to be ready
sleep 10

# Step 4: Start n8n
cd ../n8n
docker compose up -d

# Step 5: Watch logs for any errors
docker compose logs -f n8n

デプロイ後のテスト

テスト1：HTTPSアクセス

curl -I https://n8n.yourdomain.com

期待される結果： HTTP/2 200（またはHTTP/1.1 200）

テスト2：HTTPからHTTPSへのリダイレクト

curl -I http://n8n.yourdomain.com

期待される結果： HTTP/1.1 308 Permanent Redirect（Location: https://n8n.yourdomain.com付き）

テスト3：コンテナの稼働状態

docker ps

期待される結果： n8nとn8n-postgresの両方が(healthy)ステータスを表示

テスト4：Webhook URLの形式

n8nのWebインターフェースにログインします
新しいワークフローを作成します
Webhookノードを追加します
表示されるProduction URLを確認します

期待される形式：

https://n8n.yourdomain.com/webhook/abc123

誤った形式（設定エラー）：

http://n8n.yourdomain.com:5678/webhook/abc123  ❌

テスト5：タスクランナーの稼働確認

docker logs n8n | grep -i runner

期待される出力：

Registered runner "JS Task Runner"

テスト6：環境変数の適用

docker exec n8n env | grep N8N_PAYLOAD_SIZE_MAX

期待される結果： N8N_PAYLOAD_SIZE_MAX=256

よくある問題のトラブルシューティング

問題：HTTPSが機能しない

症状： ブラウザーに「保護されていない通信」の警告が表示される、証明書のエラーメッセージ、HTTPSでアクセスできない

診断：

# Check Traefik logs for errors
docker logs traefik | grep -i error

# Check certificate file exists
ls -la traefik/letsencrypt/acme.json

# Verify DNS resolution
nslookup n8n.yourdomain.com

解決策：

DNSがサーバーを指していない： DNS AレコードをサーバーのパブリックIPに更新し、DNS伝播を待ちます（最大24時間、通常はもっと早い）。別のネットワークからテスト：dig n8n.yourdomain.com +short
ポート80がブロックされている： Let's EncryptにはHTTPチャレンジのためにポート80が必要です。ファイアウォールを確認：sudo ufw status。ブロックされている場合は許可：sudo ufw allow 80/tcp && sudo ufw allow 443/tcp
Traefik設定のメールアドレスが無効： traefik/traefik.ymlを編集し、certificatesResolvers.letsencrypt.acme.emailを有効なアドレスに更新し、Traefikを再起動：docker compose restart

問題：Webhookが404を返す

症状： 外部サービスがWebhookの失敗を報告、Webhook URLは正しく見えるが機能しない、テストモードでは動作するが本番モードでは失敗する

診断：

# Test webhook directly
curl -v https://n8n.yourdomain.com/webhook/test

# Check Traefik routing logs
docker logs traefik | grep webhook

# Verify n8n sees requests
docker logs n8n | grep webhook

解決策：

WEBHOOK_URLが正しく設定されていない： 環境変数を確認：docker exec n8n env | grep WEBHOOK_URL。ドメインと正確に一致する必要があります：WEBHOOK_URL=https://n8n.yourdomain.com
ネットワーク設定が間違っている： n8nがtraefik-net上にあることを確認：docker inspect n8n | grep -A 5 Networks。出力に「traefik-net」が表示されるはずです

問題：「Execution Data Too Large」がまだ表示される

症状： N8N_PAYLOAD_SIZE_MAXを設定した後もエラーが発生する、大規模なワークフローが「Execute Node」で失敗する

診断：

# Verify variable is set
docker exec n8n env | grep PAYLOAD

# Should show N8N_PAYLOAD_SIZE_MAX=256

解決策：

変数が適用されていない（コンテナを再作成していない）： 変更を適用するには、docker compose up -d n8nでコンテナを再作成してください（docker compose restartでは変更した環境変数の値は適用されません）。その後、docker exec n8n env | grep PAYLOADで確認してください。
ワークフローに対してより大きい上限値が必要： 16GB以上のRAMを搭載するサーバーの場合、512MBに増加：N8N_PAYLOAD_SIZE_MAX=512
Traefikのリクエストサイズが小さすぎる： Traefikの制限（バイト単位）も合わせて増加："traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=536870912"

問題：メモリ使用量が多い

症状： アイドル時にコンテナが1.5GB超のRAMを使用している、メモリ使用量が時間とともに増加する、メモリ不足エラー

診断：

# Monitor memory
docker stats n8n

# Check binary data mode
docker exec n8n env | grep BINARY_DATA_MODE

解決策：

ファイルシステムモードを使用していない： 環境変数にN8N_DEFAULT_BINARY_DATA_MODE=filesystemを追加してください。効果： テストではアイドル時のメモリ使用量が約100MB少なくなりました
古い実行データが蓄積されている： 保持期間を短縮：EXECUTIONS_DATA_MAX_AGE=168（14日ではなく7日）およびEXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
コンテナの制限が低すぎる： サーバーに余裕がある場合は増加してください。deployリソースセクションでメモリ制限を2Gから4Gに変更

まとめ

解決したこと

この包括的なガイドでは、セルフホスト型n8nの最も一般的な2つの問題に対処しています：

✅ 実行データが大きすぎるエラー：N8N_PAYLOAD_SIZE_MAXとバイナリデータのファイルシステム保存モードで修正
✅ Webhook URLの問題：WEBHOOK_URLと適切なリバースプロキシ設定で修正

さらに、次の重要な内容も含めています：

✅ 完全なTraefikセットアップ：WebSocketサポート付きの本番環境対応設定
✅ タスクランナー設定：将来の互換性のための2025年の要件
✅ 本番環境のベストプラクティス：リソース制限、ヘルスチェック、セキュリティヘッダー、モニタリング
✅ 検証済み設定：すべてのdocker-composeファイルが2025年10月にn8n 1.115.2でテスト済み

重要なポイント

すぐに修正する場合：

実行データの問題にはN8N_PAYLOAD_SIZE_MAX=256を設定（8GB以上のRAMに256MB）
Webhookの問題にはWEBHOOK_URL=https://your-domain.comを設定
非推奨警告をなくすにはN8N_RUNNERS_ENABLED=trueを設定
N8N_DEFAULT_BINARY_DATA_MODE=filesystemを使用（テストではアイドル時のメモリ使用量が約100MB少なくなりました）

本番環境にデプロイする場合：

Traefik設定付きの完全なdocker-compose.ymlを使用してください
WebSocketミドルウェアは不要 — TraefikはWebSocketを標準でプロキシし、Webhookは通常のHTTPSリクエストです
負荷時のパフォーマンス向上のためにPostgreSQLを構成に組み込んでください
サーバーの容量に基づいて適切なリソース制限を設定してください
監視と依存サービスが障害を検出できるようにヘルスチェックを実装（通常のDockerはコンテナを異常状態としてマークするだけで、再起動はしません）

Traefikユーザーの場合（重要）：

Traefikは追加のミドルウェアなしでWebSocketを処理します。Webhookには適切なルーターとWEBHOOK_URLが必要です
リクエストボディのサイズ制限をペイロードサイズ以上に設定してください
セキュリティヘッダー（X-Robots-Tag、X-Forwarded-Proto）を設定してください
Traefikを開始する前にDNSがサーバーを指していることを確認してください（Let's Encryptの要件）

2025年6月の投稿との比較

機能	2025年6月の投稿	このガイド
実行データの修正	✅ 詳細	✅ 含む + リソース測定
Webhookの修正	✅ 詳細	✅ 含む + Traefik統合
Traefik設定	❌ 未対応	✅ 完全なセットアップ
WebSocketサポート	❌ 未対応	✅ 重点的に記載
タスクランナー	❌ 未対応	✅ 2025年の要件
統合docker-compose	❌ 別々	✅ 本番環境対応
リソース測定	❌ 理論値	✅ 実測データ
環境変数	✅ 対応	✅ 完全なリファレンス

テストと検証

当社のテスト環境（2025年10月）：

✅ n8nバージョン1.115.2
✅ Dockerコンテナが2時間以上稼働
✅ 実行中のコンテナですべての環境変数を検証
✅ docker statsでリソース使用量を測定
✅ プロセスリストでタスクランナープロセスを確認
✅ HTTPエンドポイントのテストとアクセスを確認
✅ 設定が動作することを検証

次のステップ

シナリオを選択：
- 開発：最小限の設定
- リバースプロキシの背後：Webhook修正 + タスクランナー
- 本番環境：Traefikを使用した完全なセットアップ（推奨）
デプロイ：
- 適切なdocker-compose.ymlをコピー
- ドメインとセキュアなパスワードで.envファイルを作成
- Traefikを先に起動し、その後n8nを起動
- デプロイ後のテストを実行
検証：
- 有効な証明書でHTTPSが動作することを確認
- Webhook URLが正しい形式で表示されることを確認
- 大規模データセットでテスト（必要な場合）
- タスクランナーが登録されていることを確認
モニタリング：
- docker statsでリソース使用量を監視
- ヘルスチェックアラートを設定（外部モニタリング）
- ディスク容量の枯渇を防ぐためにログローテーションを実装
- データボリュームの定期バックアップを計画

ご質問や問題がありますか？

このガイドに記載されていない問題が発生した場合：

追加のガイダンスについては2025年6月の詳細なトラブルシューティング投稿をご確認ください
最新機能についてはn8n公式ドキュメントをご参照ください
類似の問題についてはn8nコミュニティフォーラムで検索してください
一般的な問題については上記のトラブルシューティングセクションを確認してください
専門家による導入支援についてはtvaにお問い合わせください

再現可能なテスト

このガイドのすべての設定はご自身の環境で再現可能です。Docker Composeファイルは本番環境対応であり、環境変数は文書化および検証済みで、検証用のテストコマンドが提供されており、期待される出力が明確に指定されています。設定をご自身でデプロイし、提供されたテストを実行することで、このガイドのすべての主張を検証できます。

導入支援が必要ですか？

tvaにn8nのデプロイを任せたい場合、または本番セットアップのサポートが必要な場合は、お問い合わせください。信頼性の高い本番環境対応のn8nインフラストラクチャを求める組織向けに、これらの設定を実装しています。

公開日： 2025年10月15日
テスト環境： n8n v1.115.2、Docker Compose v3.8、Traefik v2.10
サーバー要件： 本番環境には4GB以上のRAM、2つ以上のCPUコアを推奨
根拠： n8n公式ドキュメント、検証済みDockerテスト、コミュニティのベストプラクティス

目次

クイック診断：どの問題が発生していますか？

症状：「Existing execution data is too large」

症状：WebhookのURLが正しくない、または機能しない

症状：タスクランナーに関する非推奨の警告

症状：完全な本番環境対応のセットアップが必要

2つの主な問題を理解する

n8n Cloudのユーザーがこれらの問題に対処することが少ない理由

根本原因

修正#1：実行データが大きすぎるエラー

問題の詳細

エラーメッセージ

解決策：N8N_PAYLOAD_SIZE_MAX

サーバーのRAM容量別の推奨設定

Docker Composeの実装

バイナリデータモードの理解

デフォルト：メモリ内ストレージ（非推奨）

推奨：ファイルシステムストレージ

実運用への影響

修正#2：Webhook URLの問題

問題の詳細

表示される内容（誤ったURL）

外部サービスが失敗する理由

解決策：WEBHOOK_URL環境変数

基本設定

各変数の役割

Webhook URLのテスト

修正前

修正後

Traefikを使用した完全な本番セットアップ

なぜTraefikなのか？

アーキテクチャ概要

WebSocketサポート

完全な本番Docker Compose

Traefikのセットアップ

ステップ1：Traefikネットワークの作成

ステップ2：Traefik設定の作成

ステップ3：Traefik Docker Composeの作成

ステップ4：環境ファイルの作成

ステップ5：すべてを起動する

セットアップの確認

Traefikダッシュボードの確認

n8nアクセスの確認

Webhook URLの確認

2025年の要件：タスクランナー

タスクランナーとは

なぜ今重要なのか

設定

内部モード（単一サーバーに推奨）

外部モード（分散セットアップ用）

タスクランナーの確認

プロセスリストの確認

ログの確認

リソース使用量への影響

環境変数リファレンス

環境変数の一覧

シナリオ別設定プリセット

シナリオA：開発（ローカルマシン）

シナリオB：リバースプロキシの背後（大規模データなし）

シナリオC：完全な本番セットアップ

Docker Composeの例

リソース使用量の比較（当社テスト結果）

セットアップのテスト

デプロイ前チェックリスト

1. DNS設定

2. ポートが利用可能か確認

3. Dockerのインストール

4. 環境変数

デプロイ手順

デプロイ後のテスト

テスト1：HTTPSアクセス

テスト2：HTTPからHTTPSへのリダイレクト

テスト3：コンテナの稼働状態

テスト4：Webhook URLの形式

テスト5：タスクランナーの稼働確認

テスト6：環境変数の適用

よくある問題のトラブルシューティング

問題：HTTPSが機能しない

問題：Webhookが404を返す

問題：「Execution Data Too Large」がまだ表示される