tva
← Insights

Fehlerbehebung für selbst betriebenes n8n 2025: Zu große Ausführungsdaten und Webhook-Probleme mit Traefik lösen

Zuletzt aktualisiert: 15. Oktober 2025

Das Self-Hosting von n8n bietet unbegrenzte Workflow-Ausführungen, vollständige Datenkontrolle und erhebliche Kosteneinsparungen im Vergleich zu Cloud-Plänen. Aber in der Realität stehen selbst gehostete Instanzen vor Herausforderungen, um die sich Nutzer von n8n Cloud meist nicht selbst kümmern müssen – insbesondere rund um die Verarbeitung großer Datenmengen und die Webhook-Konfiguration mit Reverse Proxys.

Im Juni 2025 haben wir zwei Fehlerbehebungsleitfäden veröffentlicht, die diese Probleme getrennt behandeln. Das Problem ist, dass kein umfassender Leitfaden für produktionsreife n8n-Deployments mit Traefik als Reverse Proxy existiert, der beide häufigen Probleme zusammen behandelt.

Dieser Leitfaden kombiniert beide ursprünglichen Korrekturen, bietet eine vollständige Traefik-Konfiguration mit WebSocket-Unterstützung, enthält die neuen Task-Runner-Anforderungen für 2025 und liefert produktionsreife Docker-Compose-Dateien, die Sie sofort bereitstellen können.

Inhaltsverzeichnis

  1. Schnelldiagnose: Welches Problem haben Sie?
  2. Die beiden Hauptprobleme verstehen
  3. Lösung #1: Fehler bei zu großen Ausführungsdaten
  4. Lösung #2: Webhook-URL-Probleme
  5. Vollständiges Setup für den Produktivbetrieb mit Traefik
  6. Anforderung 2025: Task Runners
  7. Umgebungsvariablen-Referenz
  8. Docker-Compose-Beispiele
  9. Ihr Setup testen
  10. Fehlerbehebung bei häufigen Problemen

Schnelldiagnose: Welches Problem haben Sie?

Symptom: „Existing execution data is too large“

Dieser Fehler tritt auf bei:

  • Klick auf „Execute Node“ während der Workflow-Entwicklung
  • Testen von Workflows mit großen Datensätzen oder vielen Elementen
  • Nutzung des Teilausführungsmodus (Testen einzelner Nodes)
  • Verarbeitung komplexer Transformationen mit mehreren Verzweigungen

Sie benötigen: Lösung #1: Größe der Ausführungsdaten

Symptom: Webhooks zeigen falsche URLs oder funktionieren nicht

Dies tritt auf, wenn:

  • Webhook-URLs mit Portnummern angezeigt werden (z. B. :5678)
  • Externe Dienste (Slack, GitHub, Stripe) Ihre Webhooks nicht erreichen können
  • Webhooks im Testmodus funktionieren, aber im Produktivbetrieb fehlschlagen
  • Sie einen Reverse Proxy (Nginx, Traefik, Caddy) verwenden

Sie benötigen: Lösung #2: Webhook-URL-Konfiguration

Symptom: Abkündigungswarnungen zu Task Runners

Sie sehen in den Logs:

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

Sie benötigen: Task-Runner-Konfiguration

Symptom: Sie möchten ein vollständiges, produktionsreifes Setup

Sie benötigen:

  • Beide Korrekturen angewendet
  • Traefik als Reverse Proxy mit automatischem HTTPS
  • Bewährte Verfahren für den Produktivbetrieb und Sicherheit
  • Ressourcenlimits und ordnungsgemäßes Monitoring

Springen Sie zu: Vollständiges Setup für den Produktivbetrieb

Die beiden Hauptprobleme verstehen

Warum Nutzer von n8n Cloud selten mit diesen Problemen zu tun haben

Auf n8n Cloud verwaltet n8n die Serverkonfiguration für Sie, etwa Webhook-URLs, Binärdatenspeicherung und Updates. Beim Self-Hosting sind Sie für diese Konfigurationen verantwortlich.

Die eigentlichen Ursachen

Problem #1: Limit für Ausführungsdatengröße

Das standardmäßige Limit von 16 MiB für an das Backend gesendete Anfrage-Nutzdaten, einschließlich Teilausführungsdaten löst Fehler aus, wenn mit großen Datensätzen, vielen Workflow-Verzweigungen oder komplexen Transformationen gearbeitet wird. Das macht die Workflow-Entwicklung frustrierend – Sie können einzelne Nodes während der Entwicklung nicht testen. Die Lösung ist unkompliziert: die Umgebungsvariable N8N_PAYLOAD_SIZE_MAX.

Problem #2: Webhook-URL-Generierung

n8n versucht, Ihre öffentliche URL automatisch zu erkennen, aber diese automatische Erkennung scheitert hinter einem Reverse Proxy. Externe Dienste erhalten falsche Webhook-URLs mit Ports oder internen Hostnamen – Integrationen brechen stillschweigend. Die Lösung: die Umgebungsvariable WEBHOOK_URL.

Lösung #1: Fehler bei zu großen Ausführungsdaten

Das Problem im Detail

Wenn Sie nur einen Teil eines Workflows ausführen (Klick auf „Execute Node“ im Editor), muss n8n vorherige Ausführungsdaten laden, um diesem Node Kontext zu geben. Standardmäßig begrenzt n8n diese Anfrage auf 16 MiB (N8N_PAYLOAD_SIZE_MAX=16; der Wert wird in MiB angegeben), um Speicherprobleme auf kleineren Servern zu vermeiden. Ist die Anfrage größer, antwortet n8n (oder ein Reverse Proxy mit einem niedrigeren Limit für den Anfrageinhalt) mit HTTP 413, woraufhin der Editor diesen Fehler anzeigt.

Die Fehlermeldung

Laut offizieller n8n-Dokumentation:

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

Dieser Fehler tritt auf bei der Verarbeitung Tausender Elemente in einem einzelnen Node, der Arbeit mit großen JSON-API-Antworten, der Transformation großer Datensätze mit Code-Nodes oder bei Workflows mit vielen parallelen Verzweigungen.

Die Lösung: N8N_PAYLOAD_SIZE_MAX

Die Lösung ist einfach, erfordert aber ein Verständnis der verfügbaren Ressourcen Ihres Servers.

Empfohlene Einstellungen nach Arbeitsspeicher des Servers

Arbeitsspeicher des ServersN8N_PAYLOAD_SIZE_MAXEinzustellender Wert (MiB)Prozent des RAM
2 GB oder weniger64 MB64~3 %
4 GB128 MB128~3 %
8 GB256 MB256~3 %
16 GB+512 MB512~3 %

Faustregel: Verwenden Sie weniger als 20 % Ihres verfügbaren RAM, um das System unter Last stabil zu halten.

Umsetzung mit 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:

Binärdatenmodus verstehen

Standard: Speicherung im Arbeitsspeicher (nicht empfohlen)

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

Probleme: Speichert Dateien (Bilder, PDFs usw.) im RAM, verschwendet wertvollen Speicher, nicht für Lasten im Produktivbetrieb geeignet, begrenzt die Anzahl verarbeitbarer Dateien.

Aus unseren Tests: Der Standardmodus verbrauchte im Leerlauf ~315 MB RAM gegenüber 211 MB im Dateisystemmodus – das sind ~100 MB weniger Speicherverbrauch im Leerlauf.

Empfohlen: Speicherung im Dateisystem

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

Vorteile: Speichert Dateien auf der Festplatte statt im RAM, deutlich bessere Performance mit großen Dateien, produktionsreif und von n8n empfohlen. Beachten Sie: N8N_BINARY_DATA_TTL hat seit n8n 1.9.0 keine Wirkung mehr. n8n löscht Binärdaten bei der Bereinigung von Ausführungen; daher steuern die Einstellungen zur Ausführungsbereinigung den Festplattenverbrauch.

Wichtig: Wenn Sie den Queue-Modus verwenden (Redis-basierte verteilte Ausführung), beachten Sie, dass n8n dort den Dateisystemmodus nicht unterstützt. Stand Oktober 2026 empfiehlt die n8n-Dokumentation den Modus database für den Queue-Modus.

Auswirkungen in der Praxis

Aus unseren Docker-Tests im Oktober 2025 mit n8n Version 1.115.2:

KonfigurationSpeicherverbrauchDifferenz
Standard (ohne Korrekturen)315 MBAusgangswert
Mit Lösung für die Nutzdatengröße + Dateisystemmodus211 MB-104 MB

Wichtigste Erkenntnis: In unseren Leerlaufmessungen verbrauchte die Konfiguration mit angepasstem Nutzdatenlimit und Dateisystemmodus für Binärdaten weniger Speicher als die Standardkonfiguration. Den Speicherverbrauch unter Last mit großen Nutzdaten haben wir nicht gemessen; er hängt von Ihren Workflows ab.

Lösung #2: Webhook-URL-Probleme

Das Problem im Detail

Wenn n8n Webhook-URLs generiert, um sie im Editor anzuzeigen und bei externen Diensten zu registrieren, versucht es, Ihre öffentliche URL automatisch zu erkennen. Hinter einem Reverse Proxy schlägt diese automatische Erkennung spektakulär fehl.

Was Sie sehen werden (die falschen URLs)

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

Probleme mit dieser URL:

  1. Portnummer enthalten (:5678) – externe Dienste können typischerweise Nicht-Standard-Ports nicht erreichen
  2. Falsches Protokoll (http statt https) – viele Dienste erfordern HTTPS
  3. Interner Hostname – könnte der Docker-Container-Name statt der öffentlichen Domain sein

Warum externe Dienste fehlschlagen

Dienste wie GitHub, Slack, Stripe, Zoom, Google Sheets und Hunderte weitere versuchen, Webhooks an diese falschen URLs zu senden, und scheitern stillschweigend. Sie richten die Integration ein, sie sieht in der Benutzeroberfläche korrekt aus, aber Benachrichtigungen kommen nie an.

Die Lösung: Umgebungsvariable WEBHOOK_URL

Laut offizieller n8n-Dokumentation:

„Die Umgebungsvariable WEBHOOK_URL wird verwendet, um die Webhook-URL manuell festzulegen, damit n8n sie in der Editor-UI anzeigen und die korrekten Webhook-URLs bei externen Diensten registrieren kann. Beim Betrieb von n8n hinter einem Reverse Proxy ist es wichtig, diese Variable zu setzen.“

Grundkonfiguration

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

Was jede Variable bewirkt

WEBHOOK_URL (WICHTIGSTE)

  • Die öffentliche URL für alle Webhook-Endpunkte
  • Wird bei der Registrierung von Webhooks bei externen Diensten verwendet
  • Muss exakt mit Ihrer Traefik-/Reverse-Proxy-Konfiguration übereinstimmen
  • Versionshinweis: Umbenannt von WEBHOOK_TUNNEL_URL in v0.227.0, alter Name entfernt in n8n 1.0

N8N_EDITOR_BASE_URL

  • Die URL für den Zugriff auf die n8n-Weboberfläche
  • Normalerweise identisch mit WEBHOOK_URL
  • Wird in der Browser-Adressleiste und E-Mail-Einladungen angezeigt

N8N_PROTOCOL

  • Auf https für den Produktivbetrieb setzen (mit SSL/TLS)
  • Nur für lokale Tests auf http setzen
  • Muss zur Protokollterminierung Ihres Reverse Proxys passen

N8N_HOST

  • Nur Ihr öffentlicher Domainname
  • Kein Protokoll (https://) oder Port angeben
  • Beispiel: n8n.yourdomain.com nicht https://n8n.yourdomain.com:443

N8N_TRUST_PROXY_HEADER

  • Keine dokumentierte n8n-Variable: Sie ist in der Referenz der n8n-Umgebungsvariablen nicht aufgeführt; ihr Setzen hat daher keine dokumentierte Wirkung
  • Das Vertrauen in Proxy-Header (für echte Client-IP-Adressen) wird über N8N_PROXY_HOPS gesteuert
  • Sie können diese Variable in den Beispielen dieses Leitfadens weglassen

N8N_PROXY_HOPS

  • Hinter einem Reverse Proxy auf 1 setzen
  • Hinter zwei Proxys auf 2 setzen (selten)
  • Teilt n8n mit, wie vielen Proxy-Schichten es vertrauen soll

Webhook-URLs testen

Vor der Korrektur

Erstellen Sie in der n8n-UI einen Webhook-Node und prüfen Sie die angezeigte URL:

http://n8n.example.com:5678/webhook/abc123  ❌ Falsch

Nach der Korrektur

Derselbe Webhook-Node zeigt jetzt:

https://n8n.example.com/webhook/abc123  ✔ Korrekt

Kritischer Unterschied: Externe Dienste können diese URL jetzt erreichen, weil sie den Standard-HTTPS-Port 443 (verarbeitet durch Ihren Reverse Proxy) verwendet statt des internen Ports 5678.

Vollständiges Setup für den Produktivbetrieb mit Traefik

Warum Traefik?

Traefik ist ein moderner Reverse Proxy, der perfekt für Docker-Deployments geeignet ist – automatisches HTTPS via Let's Encrypt ohne manuelle Zertifikatsverwaltung, Service Discovery, die Container automatisch über Docker-Labels erkennt, native WebSocket-Unterstützung für die Live-Verbindung des n8n-Editors, einfache Konfiguration nur mit Docker-Labels statt komplexer Konfigurationsdateien und ein integriertes Dashboard zur Echtzeitüberwachung von Routing und Zertifikaten.

Architekturübersicht

Internet
  ↓
[Traefik Reverse Proxy]
  ↓ HTTPS (Let's Encrypt)
  ↓ WebSocket Support
[n8n-Container]
  ↓ Internes Netzwerk
[PostgreSQL-Datenbank]

WebSocket-Unterstützung

Traefik leitet WebSocket-Verbindungen nativ weiter, einschließlich der Live-Verbindung des n8n-Editors. Zusätzliche Middleware ist daher nicht erforderlich. Webhooks sind gewöhnliche HTTPS-Anfragen und hängen nicht von WebSockets ab. Das folgende Produktionsbeispiel enthält optionale Labels für WebSocket-Header; Sie können sie weglassen.

Vollständige Docker-Compose-Konfiguration für den Produktivbetrieb

Diese Konfiguration kombiniert beide Korrekturen, enthält Traefik mit korrekter WebSocket-Unterstützung und folgt bewährten Verfahren für den Produktivbetrieb:

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-Setup

Falls Traefik noch nicht läuft, hier das vollständige Setup:

Schritt 1: Traefik-Netzwerk erstellen

docker network create traefik-net

Schritt 2: Traefik-Konfiguration erstellen

Erstellen Sie 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: {}

Schritt 3: Docker-Compose-Konfiguration für Traefik erstellen

Erstellen Sie 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"

Schritt 4: Umgebungsdatei erstellen

Erstellen Sie .env in Ihrem n8n-Verzeichnis:

# 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

Sichere Werte generieren:

# For DB_PASSWORD
openssl rand -base64 32

# For N8N_ENCRYPTION_KEY
openssl rand -hex 32

Schritt 5: Alles starten

# 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

Ihr Setup überprüfen

Traefik-Dashboard prüfen

Besuchen Sie http://your-server-ip:8080. Dies funktioniert nur, wenn Sie in traefik.yml zusätzlich api.insecure: true setzen (nur für Tests). Andernfalls konfigurieren Sie einen Router für das Dashboard (api@internal) unter einer eigenen Domain.

Sollte zeigen:

  • n8n-Router aktiv mit grünem Status
  • Zertifikat von Let's Encrypt erhalten
  • Dienst mit dem Status „healthy“ markiert

n8n-Zugriff prüfen

Besuchen Sie https://n8n.yourdomain.com

Sollte zeigen:

  • HTTPS funktioniert mit gültigem Let's Encrypt-Zertifikat
  • Keine Browser-Sicherheitswarnungen
  • n8n-Anmelde- bzw. Einrichtungsseite wird korrekt angezeigt

Webhook-URLs prüfen

  1. Bei n8n anmelden
  2. Neuen Workflow erstellen
  3. Webhook-Node hinzufügen
  4. Die angezeigte „Production URL“ prüfen

Erwartet:

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

NICHT dies (bedeutet Konfigurationsfehler):

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

Anforderung 2025: Task Runners

Was sind Task Runners?

Task Runners führen Code aus, der in Code-Nodes definiert ist, in isolierten Prozessen statt im Haupt-n8n-Prozess. Dies bietet bessere Sicherheit durch isolierte Ausführungsumgebungen, verbesserte Stabilität, da Code-Fehler den Hauptprozess nicht zum Absturz bringen, und Zukunftskompatibilität, da sie in kommenden n8n-Versionen erforderlich sind.

Warum das jetzt wichtig ist

Aus der offiziellen n8n-Dokumentation:

„Der Betrieb von n8n ohne Task Runners ist veraltet. Task Runners werden in einer zukünftigen Version standardmäßig aktiviert. Benutzern wird empfohlen, jetzt N8N_RUNNERS_ENABLED=true zu setzen, um potenzielle Probleme in der Zukunft zu vermeiden.“

Aus unseren Testlogs (Oktober 2025):

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

Konfiguration

Interner Modus (für einen einzelnen Server empfohlen)

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

n8n startet den Task Runner als Kindprozess – einfachste Konfiguration, für die keine zusätzliche Infrastruktur erforderlich ist, geeignet für die meisten selbst gehosteten Deployments, minimaler zusätzlicher Ressourcenverbrauch. Stand Oktober 2026 beschreibt die n8n-Dokumentation den internen Modus als grundsätzlich unsicher und kündigt ihn ab n8n 3.0 ab.

Externer Modus (für verteilte Setups)

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

Separate Task-Runner-Container bieten bessere Ressourcenisolierung für Workflows mit hohem Datenvolumen, ermöglichen horizontale Skalierung über mehrere Server, laufen als Sidecar-Container mit dem Image n8nio/runners, dessen Version mit der Ihres n8n-Images übereinstimmen muss. Ein Docker-Compose-Setup reicht aus; Docker Swarm oder Kubernetes sind nicht erforderlich.

Task Runners überprüfen

Prozessliste prüfen

docker exec n8n ps aux

Ohne Task Runners (3 Prozesse):

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

Mit Task Runners (4 Prozesse):

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

Nachweis: Task-Runner-Prozess sichtbar mit PID 18.

Logs prüfen

docker logs n8n | grep -i runner

Sollte zeigen:

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

Auswirkungen auf den Ressourcenverbrauch

Aus unseren Docker-Tests (Oktober 2025, n8n Version 1.115.2):

KonfigurationSpeicherCPUProzesse
Ohne Task Runners214 MB0,14 %3
Mit Task Runners289 MB0,29 %4
Differenz+75 MB+0,15 %+1

Minimaler zusätzlicher Ressourcenverbrauch. Die Vorteile – Sicherheit, Stabilität, Zukunftssicherheit – überwiegen die geringen Ressourcenkosten bei weitem.

Umgebungsvariablen-Referenz

Vollständige Variablenliste

VariableTypStandardZweckPriorität
Kritische Variablen
WEBHOOK_URLString–Öffentliche Webhook-URLERFORDERLICH mit Reverse Proxy
N8N_PAYLOAD_SIZE_MAXNumber16 (MiB)Maximale Größe der Anfrage-Nutzdaten in MiB, einschließlich TeilausführungsdatenERFORDERLICH für große Datenmengen
N8N_RUNNERS_ENABLEDBooleanfalseTask Runners aktivierenEmpfohlen auf 1.x (ab n8n 2.0 nicht erforderlich)
N8N_TRUST_PROXY_HEADER––Nicht unter den dokumentierten n8n-VariablenNicht erforderlich; N8N_PROXY_HOPS verwenden
Webhook-Konfiguration
N8N_EDITOR_BASE_URLString–Editor-UI-URLEmpfohlen
N8N_PROTOCOLStringhttpProtokoll (http/https)Produktivbetrieb
N8N_HOSTStringlocalhostÖffentlicher HostnameProduktivbetrieb
N8N_PORTNumber5678Interner PortOptional
N8N_PROXY_HOPSNumber0Anzahl der Reverse ProxysMit Proxy auf 1 setzen
Performance
N8N_DEFAULT_BINARY_DATA_MODEStringdefaultBinärspeichermodusEmpfohlen
N8N_BINARY_DATA_TTL––Seit n8n 1.9.0 ohne Wirkung (Binärdaten werden mit Ausführungen bereinigt)Kann entfernt werden
Task Runners
N8N_RUNNERS_MODEStringinternalTask-Runner-ModusWenn Task Runners aktiviert sind
N8N_RUNNERS_MAX_CONCURRENCYNumber10Max. gleichzeitige Aufgaben pro Task RunnerOptional

Vordefinierte Konfigurationen nach Szenario

Szenario A: Entwicklung (lokaler Rechner)

environment:
  - N8N_PORT=5678

Geeignet für: Lokales Testen, kein Reverse Proxy, keine Anforderungen an den Produktivbetrieb

Szenario B: Hinter einem Reverse Proxy (keine großen Datenmengen)

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

Geeignet für: Öffentliche n8n-Instanz, Webhooks benötigt, kleinere Workflows

Szenario C: Vollständiges Setup für den Produktivbetrieb

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}

Geeignet für: Deployment für den Produktivbetrieb mit allen Funktionen, große Workflows, öffentlicher Zugang

Docker-Compose-Beispiele

Alle vier Szenarien aus unserer Testumgebung sind verfügbar. Diese Konfigurationen wurden mit n8n Version 1.115.2 im Oktober 2025 validiert. Die Beispiele verwenden den Image-Tag latest; legen Sie n8nio/n8n:1.115.2 fest, um die getestete Version zu reproduzieren.

Ressourcenverbrauch im Vergleich (aus unseren Tests)

SzenarioSpeicherCPUProzesseBeschreibung
Standard315 MB0,00 %3Ohne Korrekturen, Ausgangswert
Lösung für die Nutzdatengröße211 MB0,00 %3Nutzdatengröße + Dateisystemmodus
Webhook-Lösung215 MB0,14 %3Nur Webhook-Konfiguration
Produktivbetrieb289 MB0,29 %4Alle Korrekturen + Task Runners

Wichtigste Erkenntnis: Im Leerlauf verbrauchte die Konfiguration für den Produktivbetrieb mit allen Korrekturen in unseren Tests weniger Speicher als die Standardkonfiguration. Dies sind Leerlaufmessungen, keine Ergebnisse unter Last mit großen Nutzdaten.

Ihr Setup testen

Checkliste vor dem Deployment

1. DNS-Konfiguration

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

# Should return your server's public IP

2. Verfügbarkeit der Ports

# 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-Installation

# Verify Docker
docker --version

# Verify Docker Compose
docker compose version

4. Umgebungsvariablen

# Verify .env file exists
cat .env

# Should show N8N_DOMAIN, DB_PASSWORD, N8N_ENCRYPTION_KEY

Deployment-Schritte

# 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

Tests nach dem Deployment

Test 1: HTTPS-Zugriff

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

Erwartet: HTTP/2 200 (oder HTTP/1.1 200)

Test 2: HTTP-zu-HTTPS-Weiterleitung

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

Erwartet: HTTP/1.1 308 Permanent Redirect mit Location: https://n8n.yourdomain.com

Test 3: Container-Zustand

docker ps

Erwartet: Sowohl n8n als auch n8n-postgres zeigen (healthy)-Status

Test 4: Webhook-URL-Format

  1. Bei der n8n-Weboberfläche anmelden
  2. Neuen Workflow erstellen
  3. Webhook-Node hinzufügen
  4. Die angezeigte „Production URL“ prüfen

Erwartetes Format:

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

NICHT erwartet (Konfigurationsfehler):

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

Test 5: Task Runners aktiv

docker logs n8n | grep -i runner

Erwartete Ausgabe:

Registered runner "JS Task Runner"

Test 6: Umgebungsvariablen angewendet

docker exec n8n env | grep N8N_PAYLOAD_SIZE_MAX

Erwartet: N8N_PAYLOAD_SIZE_MAX=256

Fehlerbehebung bei häufigen Problemen

Problem: HTTPS funktioniert nicht

Symptome: Browser zeigt „Nicht sicher“-Warnung, Zertifikatsfehler, Zugriff über HTTPS nicht möglich

Diagnose:

# 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

Lösungen:

  1. DNS zeigt nicht auf den Server: Aktualisieren Sie Ihren DNS-A-Eintrag auf die öffentliche IP des Servers, warten Sie auf die Verbreitung der DNS-Änderung (bis zu 24 Stunden, normalerweise viel schneller), testen Sie von einem anderen Netzwerk: dig n8n.yourdomain.com +short
  2. Port 80 blockiert: Let's Encrypt benötigt Port 80 für die HTTP-Challenge. Firewall prüfen: sudo ufw status. Bei Blockierung freigeben: sudo ufw allow 80/tcp && sudo ufw allow 443/tcp
  3. Ungültige E-Mail-Adresse in der Traefik-Konfiguration: Bearbeiten Sie traefik/traefik.yml, aktualisieren Sie certificatesResolvers.letsencrypt.acme.email auf eine gültige Adresse, starten Sie Traefik neu: docker compose restart

Problem: Webhooks liefern 404

Symptome: Externe Dienste melden Webhook-Fehler, Webhook-URLs sehen korrekt aus, funktionieren aber nicht, der Testmodus funktioniert, aber der Produktivmodus schlägt fehl

Diagnose:

# 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

Lösungen:

  1. WEBHOOK_URL nicht korrekt gesetzt: Umgebungsvariable prüfen: docker exec n8n env | grep WEBHOOK_URL. Sollte exakt mit Ihrer Domain übereinstimmen: WEBHOOK_URL=https://n8n.yourdomain.com
  2. Falsche Netzwerkkonfiguration: Prüfen Sie, ob n8n in traefik-net ist: docker inspect n8n | grep -A 5 Networks. Sollte „traefik-net“ in der Ausgabe zeigen

Problem: „Execution Data Too Large“ erscheint weiterhin

Symptome: Der Fehler tritt auch nach dem Setzen von N8N_PAYLOAD_SIZE_MAX auf, große Workflows scheitern bei „Execute Node“

Diagnose:

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

# Should show N8N_PAYLOAD_SIZE_MAX=256

Lösungen:

  1. Variable nicht angewendet (Container nicht neu erstellt): Erstellen Sie den Container neu, um Änderungen anzuwenden: docker compose up -d n8n (docker compose restart übernimmt keine geänderten Umgebungswerte). Prüfen Sie anschließend: docker exec n8n env | grep PAYLOAD
  2. Höheres Limit für Ihren Workflow nötig: Bei Servern mit 16 GB+ RAM auf 512 MB erhöhen: N8N_PAYLOAD_SIZE_MAX=512
  3. Traefik-Limit für die Anfragegröße zu niedrig: Auch das Traefik-Limit (in Bytes) entsprechend erhöhen: "traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=536870912"

Problem: Hoher Speicherverbrauch

Symptome: Container verbraucht >1,5 GB RAM im Leerlauf, der Speicherverbrauch steigt mit der Zeit, Out-of-Memory-Fehler

Diagnose:

# Monitor memory
docker stats n8n

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

Lösungen:

  1. Dateisystemmodus nicht aktiv: Zur Umgebung hinzufügen: N8N_DEFAULT_BINARY_DATA_MODE=filesystem. Auswirkung: ~100 MB weniger Speicherverbrauch im Leerlauf in unseren Tests
  2. Alte Ausführungen sammeln sich an: Aufbewahrungszeitraum reduzieren: EXECUTIONS_DATA_MAX_AGE=168 (7 Tage statt 14) und EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  3. Container-Limit zu niedrig: Erhöhen, wenn der Server Kapazität hat. Speicherlimit von 2G auf 4G im Abschnitt für Deployment-Ressourcen ändern

Fazit

Was wir gelöst haben

Dieser umfassende Leitfaden behandelt die beiden häufigsten Probleme selbst betriebener n8n-Instanzen:

  1. Fehler bei zu großen Ausführungsdaten – Behoben mit N8N_PAYLOAD_SIZE_MAX und Dateisystemmodus für Binärdaten
  2. Webhook-URL-Probleme – Behoben mit WEBHOOK_URL und korrekter Reverse-Proxy-Konfiguration

Plus diese kritischen Ergänzungen:

  1. Vollständiges Traefik-Setup – Produktionsreife Konfiguration mit WebSocket-Unterstützung
  2. Task-Runner-Konfiguration – Anforderung für 2025 zur Kompatibilität mit künftigen Versionen
  3. Bewährte Verfahren für den Produktivbetrieb – Ressourcenlimits, Healthchecks, Sicherheitsheader, Monitoring
  4. Validierte Konfigurationen – Alle Docker-Compose-Dateien getestet mit n8n 1.115.2 im Oktober 2025

Wichtigste Erkenntnisse

Für schnelle Fehlerbehebung:

  • Setzen Sie N8N_PAYLOAD_SIZE_MAX=256 bei Problemen mit Ausführungsdaten (256 MB für 8 GB+ RAM)
  • Setzen Sie WEBHOOK_URL=https://your-domain.com für Webhook-Probleme
  • Setzen Sie N8N_RUNNERS_ENABLED=true, um Abkündigungswarnungen zu beseitigen
  • Verwenden Sie N8N_DEFAULT_BINARY_DATA_MODE=filesystem (rund 100 MB weniger Speicherverbrauch im Leerlauf in unseren Tests)

Für das Deployment im Produktivbetrieb:

  • Verwenden Sie unsere vollständige docker-compose.yml mit Traefik-Konfiguration
  • Keine WebSocket-Middleware erforderlich – Traefik leitet WebSockets nativ weiter; Webhooks sind gewöhnliche HTTPS-Anfragen
  • PostgreSQL für bessere Performance unter Last einbeziehen
  • Angemessene Ressourcenlimits basierend auf Ihrer Serverkapazität setzen
  • Healthchecks implementieren, damit Monitoring und abhängige Dienste Fehler erkennen können (Docker allein markiert einen Container als fehlerhaft, startet ihn aber nicht neu)

Für Traefik-Nutzer (KRITISCH):

  • Traefik verarbeitet WebSockets ohne zusätzliche Middleware; Webhooks benötigen einen korrekten Router und WEBHOOK_URL
  • Größenlimit für den Anfrageinhalt so setzen, dass es der Nutzdatengröße entspricht oder sie übersteigt
  • Sicherheitsheader konfigurieren (X-Robots-Tag, X-Forwarded-Proto)
  • DNS vor dem Start von Traefik auf Ihren Server verweisen lassen (Let's Encrypt-Anforderung)

Was ist neu gegenüber den Beiträgen vom Juni 2025?

FunktionBeiträge Juni 2025Dieser Leitfaden
Ausführungsdaten-LösungDetailliertEnthalten + Ressourcenmessungen
Webhook-LösungDetailliertEnthalten + Traefik-Integration
Traefik-KonfigurationNicht abgedecktVollständiges Setup
WebSocket-UnterstützungNicht abgedecktHervorgehoben
Task RunnersNicht abgedecktAnforderung 2025
Kombinierte Docker-Compose-KonfigurationSeparatProduktionsreif
RessourcenmessungenTheoretischEchte Testdaten
UmgebungsvariablenAbgedecktVollständige Referenz

Tests und Validierung

Unsere Testumgebung (Oktober 2025):

  • n8n Version 1.115.2
  • Docker-Container liefen 2+ Stunden
  • Alle Umgebungsvariablen in laufenden Containern verifiziert
  • Ressourcenverbrauch gemessen mit docker stats
  • Task-Runner-Prozess in der Prozessliste bestätigt
  • HTTP-Endpunkte getestet und erreichbar
  • Konfigurationen als funktionierend validiert

Nächste Schritte

  1. Wählen Sie Ihr Szenario:
    • Entwicklung: Minimale Konfiguration
    • Hinter einem Reverse Proxy: Webhook-Lösung + Task Runners
    • Produktivbetrieb: Vollständiges Setup mit Traefik (empfohlen)
  2. Bereitstellen:
    • Entsprechende docker-compose.yml kopieren
    • .env-Datei mit Ihrer Domain und sicheren Passwörtern erstellen
    • Zuerst Traefik starten, dann n8n
    • Post-Deployment-Tests durchführen
  3. Validieren:
    • Prüfen, ob HTTPS mit einem gültigen Zertifikat funktioniert
    • Prüfen, ob die Webhook-URLs das richtige Format haben
    • Mit großem Datensatz testen (falls nötig)
    • Bestätigen, dass die Task Runners registriert sind
  4. Überwachen:
    • Ressourcenverbrauch mit docker stats beobachten
    • Healthcheck-Alarme einrichten (externes Monitoring)
    • Log-Rotation einrichten, damit Protokolle die Festplatte nicht füllen
    • Regelmäßige Backups der Datenvolumes planen

Weiterführende Ressourcen

Vom Juni 2025:

Offizielle n8n-Dokumentation:

Fragen oder Probleme?

Wenn Sie auf Probleme stoßen, die in diesem Leitfaden nicht behandelt werden:

  1. Lesen Sie unsere detaillierten Fehlerbehebungsbeiträge von Juni 2025 für zusätzliche Hilfestellungen
  2. Konsultieren Sie die offizielle n8n-Dokumentation zu den neuesten Funktionen
  3. Durchsuchen Sie die n8n-Community-Foren nach ähnlichen Problemen
  4. Prüfen Sie den obigen Abschnitt zur Fehlerbehebung bei häufigen Problemen
  5. Kontaktieren Sie tva für professionelle Implementierungsunterstützung

Reproduzierbare Tests

Alle Konfigurationen in diesem Leitfaden können in Ihrer eigenen Umgebung reproduziert werden – Docker-Compose-Dateien sind produktionsreif, Umgebungsvariablen sind dokumentiert und verifiziert, Testbefehle werden zur Validierung bereitgestellt, und erwartete Ausgaben sind klar spezifiziert. Sie können jede Aussage in diesem Leitfaden validieren, indem Sie die Konfigurationen selbst bereitstellen und die bereitgestellten Tests ausführen.

Brauchen Sie Hilfe bei der Implementierung?

Wenn Sie möchten, dass tva Ihr n8n-Deployment übernimmt, oder wenn Sie Unterstützung beim Setup für den Produktivbetrieb benötigen, nehmen Sie Kontakt mit uns auf. Wir implementieren diese Konfigurationen für Organisationen, die eine zuverlässige, produktionsreife n8n-Infrastruktur suchen.

Veröffentlicht: 15. Oktober 2025
Getestet mit: n8n v1.115.2, Docker Compose v3.8, Traefik v2.10
Serveranforderungen: 4 GB+ RAM, 2+ CPU-Kerne empfohlen für den Produktivbetrieb
Basierend auf: Offizielle n8n-Dokumentation, validierte Docker-Tests und Community-Best-Practices

Weiterführende Beiträge

n8n-Webhook-Probleme beheben: Der vollständige Leitfaden für selbst betriebene Instanzen

n8n-Fehler „Existing execution data is too large“: Die vollständige Lösung für selbst betriebene Instanzen

Selbst betriebenes n8n 2.x: Payload-Limits für Ausführungsdaten diagnostizieren und sicher erhöhen