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

最終更新： 2025年10月15日

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

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

このガイドでは、両方のオリジナルの修正を組み合わせ、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、最適化されたバイナリデータストレージ、すべての新要件を含む自動更新を自動的に処理します。セルフホスティングの場合、これらの設定はお客様の責任となります。

根本原因

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

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

問題 #2：Webhook URLの生成

n8nはパブリックURLを自動検出しようとしますが、リバースプロキシの背後ではこの自動検出が失敗します。外部サービスはポートや内部ホスト名を含む誤ったWebhook URLを受け取り、統合が暗黙的に壊れます。修正：環境変数WEBHOOK_URLを使用します。

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

問題の詳細

ワークフローの一部のみを実行する場合（エディタで“Execute Node”をクリック）、n8nはそのノードにコンテキストを提供するために以前の実行データを読み込む必要があります。デフォルトでは、n8nはメモリの問題を防ぐためにこのデータ転送を16MBに制限しています。

エラーメッセージ

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	バイト値	RAMの割合
2GB以下	64MB	`67108864`	約3%
4GB	128MB	`134217728`	約3%
8GB	256MB	`268435456`	約3%
16GB以上	512MB	`536870912`	約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)
      - N8N_PAYLOAD_SIZE_MAX=268435456

      # 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に保存し、貴重なメモリを浪費します。本番ワークロードには適しておらず、処理できるファイル数が制限されます。

当社のテストから：デフォルトモードは約315MBのRAMを使用するのに対し、ファイルシステムモードでは211MBです。約100MBのRAMを節約できます。

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

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

利点： RAMではなくディスクにファイルを保存し、大きなファイルのパフォーマンスが大幅に向上します。本番環境対応でn8nが推奨しており、TTLによる自動クリーンアップでディスクの肥大化を防止します。

重要： キューモード（Redisベースの分散実行）を使用する場合、ファイルシステムストレージはキューモードでサポートされていないため、デフォルトのバイナリデータモードを維持する必要があります。

実運用への影響

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

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

重要な発見： ペイロードサイズの増加とファイルシステムバイナリモードの組み合わせにより、データがRAMではなくディスクでより効率的に処理されるため、実際にはメモリ使用量が減少します。

修正 #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

リバースプロキシの背後ではtrueにする必要があります
プロキシヘッダーから実際のクライアントIPアドレスをn8nが参照できるようにします
適切なリクエスト処理とセキュリティに必要です

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 Webhook機能に不可欠なWebSocketサポート、複雑な設定ファイルではなくDockerラベルだけで行える簡単な設定、ルーティングと証明書をリアルタイムで監視する組み込みダッシュボードを提供します。

アーキテクチャ概要

Internet
  ↓
[Traefik Reverse Proxy]
  ↓ HTTPS (Let's Encrypt)
  ↓ WebSocket Support

[n8n Container]

↓ Internal Network [PostgreSQL Database]

重要な設定：WebSocketサポート

これは最もよく見落とされる設定であり、Webhookの障害を引き起こします：

labels:
  # WebSocket middleware (ABSOLUTELY REQUIRED)
  - "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Upgrade=websocket"
  - "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Connection=Upgrade"

  # Apply middleware to router
  - "traefik.http.routers.n8n.middlewares=n8n-websocket"

WebSocketヘッダーなしの場合：

❌ リアルタイムWebhookが失敗します
❌ 本番Webhookがタイムアウトします
❌ 外部サービスが永続的な接続を維持できません
❌ 統合エラーが断続的かつ予測不可能に発生します

完全な本番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 (100MB)
      - "traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=104857600"

      # Middleware: WebSocket support (CRITICAL - DO NOT SKIP)
      - "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=268435456  # 256MB

      # 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: your-email@example.com  # 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にアクセスします（またはダッシュボード用にドメインを設定）

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

✅ 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は子プロセスとしてタスクランナーを起動します。最もシンプルな構成で、追加のインフラストラクチャは不要です。ほとんどのセルフホスティングデプロイに適しており、パフォーマンスオーバーヘッドは最小限です。

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

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

個別のタスクランナーコンテナは、大量ワークフロー向けのリソース分離の改善、複数サーバー間での水平スケーリングを可能にしますが、オーケストレーション（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	`16777216`(16MB)	最大実行データサイズ	大規模データの場合必須
`N8N_RUNNERS_ENABLED`	Boolean	`false`	タスクランナーの有効化	2025年必須
`N8N_TRUST_PROXY_HEADER`	Boolean	`false`	リバースプロキシヘッダーの信頼	プロキシ使用時必須
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`	Number	`60`	バイナリクリーンアップ（分）	推奨
タスクランナー
`N8N_RUNNERS_MODE`	String	`internal`	タスクランナーモード	ランナー有効時
`N8N_RUNNERS_MAX_CONCURRENCY`	Number	`5`	最大同時タスクランナー	オプション

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

シナリオ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=268435456  # 256MB
  - 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で検証されています。

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

シナリオ	メモリ	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=268435456

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

問題：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

解決策：

WebSocketミドルウェアがない： docker-compose.ymlでこれらのラベルを確認してください：

- "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Upgrade=websocket"
- "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Connection=Upgrade"
- "traefik.http.routers.n8n.middlewares=n8n-websocket"

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=268435456

解決策：

変数が適用されていない（コンテナが再起動されていない）： 変更を適用するために再起動：docker compose restart n8n。再起動後に確認：docker exec n8n env | grep PAYLOAD
ワークフローに対してより高い制限が必要： 16GB以上のRAMサーバーの場合、512MBに増加：N8N_PAYLOAD_SIZE_MAX=536870912
Traefikのリクエストサイズが小さすぎる： Traefikの制限も合わせて増加："traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=209715200"

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

症状： アイドル時にコンテナが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とN8N_BINARY_DATA_TTL=1440。影響： 当社のテストに基づき約100MBのRAMを節約
古い実行データが蓄積されている： 保持期間を短縮：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=268435456を設定（8GB以上のRAMに256MB）
Webhookの問題にはWEBHOOK_URL=https://your-domain.comを設定
非推奨警告をなくすにはN8N_RUNNERS_ENABLED=trueを設定
約100MBのRAMを節約するにはN8N_DEFAULT_BINARY_DATA_MODE=filesystemを使用

本番デプロイの場合：

Traefik設定付きの完全なdocker-compose.ymlを使用してください
WebSocketミドルウェアは省略しないでください – Webhookに絶対に必要です
負荷時のパフォーマンス向上のためにPostgreSQLを含めてください
サーバーの容量に基づいて適切なリソース制限を設定してください
自動回復のためにヘルスチェックを実装してください

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

WebSocketミドルウェアはWebhook機能に不可欠です
リクエストボディのサイズ制限をペイロードサイズ以上に設定してください
セキュリティヘッダー（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”がまだ表示される