tva
← Insights

Vollständiger n8n Self-Hosted Fehlerbehebungsleitfaden 2025: Execution Data Size & Webhook-Probleme mit Traefik lösen

Letztes Update: 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 einzigartigen Herausforderungen, die Cloud-Nutzer nie erleben – insbesondere rund um die Verarbeitung großer Daten und die Webhook-Konfiguration mit Reverse Proxys.

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

Dieser Leitfaden kombiniert beide ursprünglichen Fixes, 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. Fix #1: Fehler bei zu großen Ausführungsdaten
  4. Fix #2: Webhook-URL-Probleme
  5. Vollständiges Produktions-Setup mit Traefik
  6. Anforderung 2025: Task Runners
  7. Umgebungsvariablen-Referenz
  8. Docker Compose Beispiele
  9. Ihr Setup testen
  10. Fehlerbehebung häufiger Probleme

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: Fix #1: Execution Data Size

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 in der Produktion fehlschlagen
  • Sie einen Reverse Proxy (Nginx, Traefik, Caddy) verwenden

Sie benötigen: Fix #2: Webhook-URL-Konfiguration

Symptom: Deprecation-Warnungen 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 Fixes korrekt angewendet
  • Traefik Reverse Proxy mit automatischem HTTPS
  • Produktions-Best-Practices und Sicherheit
  • Ressourcenlimits und ordnungsgemäßes Monitoring

Springen Sie zu: Vollständiges Produktions-Setup

Die beiden Hauptprobleme verstehen

Warum n8n Cloud diese Probleme nicht hat

n8n Cloud verarbeitet automatisch höhere Speicherlimits für Teilausführungen, korrekte Webhook-URLs, optimierte Binärdatenspeicherung und automatische Updates einschließlich aller neuen Anforderungen. Beim Self-Hosting sind Sie für diese Konfigurationen verantwortlich.

Die Grundursachen

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

Das Standard-16-MB-Limit für an das Backend gesendete Teilausführungsdaten löst Fehler aus, wenn mit großen Datensätzen, vielen Workflow-Verzweigungen oder komplexen Transformationen gearbeitet wird. Das Problem ist, dass die Workflow-Entwicklung frustrierend wird – 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.

Fix #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 diesen Datentransfer auf 16 MB, um Speicherprobleme auf kleineren Servern zu vermeiden.

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

Der Fix ist einfach, erfordert aber ein Verständnis der verfügbaren Ressourcen Ihres Servers.

Empfohlene Einstellungen nach Server-RAM

Server-RAMN8N_PAYLOAD_SIZE_MAXWert in BytesProzent des RAM
2 GB oder weniger64 MB67108864~3 %
4 GB128 MB134217728~3 %
8 GB256 MB268435456~3 %
16 GB+512 MB536870912~3 %

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

Docker Compose Implementierung

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:

Binärdaten-Modus verstehen

Standard: In-Memory-Speicherung (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 Produktionslasten geeignet, begrenzt die Anzahl verarbeitbarer Dateien.

Aus unseren Tests: Der Standardmodus verbraucht ~315 MB RAM gegenüber 211 MB im Dateisystemmodus – das sind ~100 MB RAM gespart.

Empfohlen: Dateisystem-Speicherung

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, automatische Bereinigung mit TTL verhindert Festplattenaufblähung.

Wichtig: Bei Verwendung des Queue-Modus (Redis-basierte verteilte Ausführung) müssen Sie den Standard-Binärdatenmodus beibehalten, da Dateisystem-Speicherung im Queue-Modus nicht unterstützt wird.

Praxisauswirkungen

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

KonfigurationSpeicherverbrauchDifferenz
Standard (keine Fixes)315 MBBaseline
Mit Payload-Fix + Dateisystemmodus211 MB-104 MB

Kernerkenntnis: Die Kombination aus erhöhter Payload-Größe und Dateisystem-Binärmodus reduziert den Speicherverbrauch tatsächlich, weil Daten effizienter auf der Festplatte statt im RAM verarbeitet werden.

Fix #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 UI 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 Produktion setzen (mit SSL/TLS)
  • Nur für lokale Tests auf http setzen
  • Muss mit Ihrer Reverse-Proxy-Terminierung übereinstimmen

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

  • Muss true sein hinter einem Reverse Proxy
  • Ermöglicht n8n, echte Client-IP-Adressen aus Proxy-Headern zu sehen
  • Erforderlich für korrekte Anfrageverarbeitung und Sicherheit

N8N_PROXY_HOPS

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

Webhook-URLs testen

Vor dem Fix

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 dem Fix

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 Produktions-Setup 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, WebSocket-Unterstützung, die für die n8n-Webhook-Funktionalität kritisch ist, einfache Konfiguration nur mit Docker-Labels statt komplexer Konfigurationsdateien und ein integriertes Dashboard zur Echtzeitüberwachung von Routing und Zertifikaten.

Architekturübersicht

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

[n8n Container]

\u2193 Internes Netzwerk [PostgreSQL-Datenbank]

Kritische Konfiguration: WebSocket-Unterstützung

Dies ist die am häufigsten vergessene Konfiguration und verursacht Webhook-Ausfälle:

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"

Ohne WebSocket-Header:

  • Echtzeit-Webhooks schlagen fehl
  • Produktions-Webhooks laufen in Timeouts
  • Externe Dienste können keine persistenten Verbindungen aufrechterhalten
  • Integrationsfehler treten intermittierend und unvorhersehbar auf

Vollständige Produktions-Docker-Compose

Diese Konfiguration kombiniert beide Fixes, enthält Traefik mit korrekter WebSocket-Unterstützung und folgt Produktions-Best-Practices:

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-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: your-email@example.com  # CHANGE THIS
      storage: /letsencrypt/acme.json
      httpChallenge:
        entryPoint: web

log:
  level: INFO

accessLog: {}

Schritt 3: Traefik Docker Compose 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 (oder konfigurieren Sie eine Domain für das Dashboard)

Sollte zeigen:

  • n8n-Router aktiv mit grünem Status
  • Zertifikat von Let's Encrypt erhalten
  • Service als gesund 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 Login-/Setup-Seite wird korrekt angezeigt

Webhook-URLs prüfen

  1. Bei n8n einloggen
  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 Sandboxed-Umgebungen, 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 (Empfohlen für Einzelserver)

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

n8n startet den Task Runner als Kindprozess – einfachste Konfiguration ohne zusätzliche Infrastruktur erforderlich, geeignet für die meisten selbst gehosteten Deployments, minimaler Performance-Overhead.

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 Hochvolumen-Workflows, ermöglichen horizontale Skalierung über mehrere Server, erfordern aber Orchestrierung (Docker Swarm, Kubernetes).

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 Overhead. 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_MAXNumber16777216(16 MB)Max. AusführungsdatengrößeERFORDERLICH für große Daten
N8N_RUNNERS_ENABLEDBooleanfalseTask Runners aktivierenERFORDERLICH für 2025
N8N_TRUST_PROXY_HEADERBooleanfalseReverse-Proxy-Header vertrauenERFORDERLICH mit Proxy
Webhook-Konfiguration
N8N_EDITOR_BASE_URLString–Editor-UI-URLEmpfohlen
N8N_PROTOCOLStringhttpProtokoll (http/https)Produktion
N8N_HOSTStringlocalhostÖffentlicher HostnameProduktion
N8N_PORTNumber5678Interner PortOptional
N8N_PROXY_HOPSNumber0Anzahl Reverse ProxysAuf 1 mit Proxy setzen
Performance
N8N_DEFAULT_BINARY_DATA_MODEStringdefaultBinärspeichermodusEmpfohlen
N8N_BINARY_DATA_TTLNumber60Binärbereinigung (Minuten)Empfohlen
Task Runners
N8N_RUNNERS_MODEStringinternalTask-Runner-ModusWenn Runners aktiviert
N8N_RUNNERS_MAX_CONCURRENCYNumber5Max. gleichzeitige Task RunnersOptional

Konfigurations-Presets nach Szenario

Szenario A: Entwicklung (Lokaler Rechner)

environment:
  - N8N_PORT=5678

Verwenden wenn: Lokales Testen, kein Reverse Proxy, keine Produktionsanforderungen

Szenario B: Hinter Reverse Proxy (Keine großen Daten)

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

Verwenden wenn: Öffentliche n8n-Instanz, Webhooks benötigt, kleinere Workflows

Szenario C: Vollständiges Produktions-Setup

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}

Verwenden wenn: Produktions-Deployment mit allen Features, 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.

Ressourcenverbrauch im Vergleich (Aus unseren Tests)

SzenarioSpeicherCPUProzesseBeschreibung
Standard315 MB0,00 %3Keine Fixes, Baseline
Payload Fix211 MB0,00 %3Payload + Dateisystemmodus
Webhook Fix215 MB0,14 %3Nur Webhook-Konfiguration
Produktion289 MB0,29 %4Alle Fixes + Task Runners

Kernkenntnis: Die Produktionskonfiguration mit allen Fixes verbraucht WENIGER Speicher als die Standardkonfiguration dank des Dateisystem-Binärmodus.

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. Port-Verfügbarkeit

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

docker ps

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

Test 4: Webhook-URL-Format

  1. Bei n8n-Weboberfläche einloggen
  2. Neuen Workflow erstellen
  3. Webhook-Node hinzufügen
  4. 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=268435456

Fehlerbehebung häufiger Probleme

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-Record auf die öffentliche IP des Servers, warten Sie auf DNS-Propagierung (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 in 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, Testmodus funktioniert, aber Produktionsmodus scheitert

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. WebSocket-Middleware fehlt: Überprüfen Sie diese Labels in 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"
  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: Fehler tritt weiterhin auf nach Setzen von N8N_PAYLOAD_SIZE_MAX, große Workflows scheitern bei „Execute Node“

Diagnose:

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

# Should show N8N_PAYLOAD_SIZE_MAX=268435456

Lösungen:

  1. Variable nicht angewendet (Container nicht neu gestartet): Neustart zur Anwendung der Änderungen: docker compose restart n8n. Nach Neustart prüfen: docker exec n8n env | grep PAYLOAD
  2. Höheres Limit für Ihren Workflow nötig: Für 16 GB+ RAM-Server auf 512 MB erhöhen: N8N_PAYLOAD_SIZE_MAX=536870912
  3. Traefik-Anfragengröße zu klein: Auch das Traefik-Limit entsprechend erhöhen: "traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=209715200"

Problem: Hoher Speicherverbrauch

Symptome: Container verbraucht >1,5 GB RAM im Leerlauf, Speicherverbrauch wächst über die 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 und N8N_BINARY_DATA_TTL=1440. Auswirkung: Spart ~100 MB RAM basierend auf 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 deploy-resources-Bereich ändern

Fazit

Was wir gelöst haben

Dieser umfassende Leitfaden adressiert die zwei häufigsten Self-Hosted-n8n-Probleme:

  1. Fehler bei zu großen Ausführungsdaten – Behoben mit N8N_PAYLOAD_SIZE_MAX und Dateisystem-Binärmodus
  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 2025 für Zukunftskompatibilität
  3. Produktions-Best-Practices – 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 Fixes:

  • Setzen Sie N8N_PAYLOAD_SIZE_MAX=268435456 für Ausführungsdaten-Probleme (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 Deprecation-Warnungen zu beseitigen
  • Verwenden Sie N8N_DEFAULT_BINARY_DATA_MODE=filesystem um ~100 MB RAM zu sparen

Für Produktions-Deployment:

  • Verwenden Sie unsere vollständige docker-compose.yml mit Traefik-Konfiguration
  • WebSocket-Middleware nicht überspringen – absolut erforderlich für Webhooks
  • PostgreSQL für bessere Performance unter Last einbeziehen
  • Angemessene Ressourcenlimits basierend auf Ihrer Serverkapazität setzen
  • Healthchecks für automatische Wiederherstellung implementieren

Für Traefik-Nutzer (KRITISCH):

  • WebSocket-Middleware ist für die Webhook-Funktionalität unverzichtbar
  • Request-Body-Größenlimit so setzen, dass es der Payload-Größ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 im Vergleich zu den Juni-2025-Beiträgen

FeatureBeiträge Juni 2025Dieser Leitfaden
Ausführungsdaten-FixDetailliertEnthalten + Ressourcenmessungen
Webhook-FixDetailliertEnthalten + Traefik-Integration
Traefik-KonfigurationNicht abgedecktVollständiges Setup
WebSocket-UnterstützungNicht abgedecktHervorgehoben
Task RunnersNicht abgedecktAnforderung 2025
Kombinierte Docker-ComposeSeparatProduktionsreif
RessourcenmessungenTheoretischEchte Testdaten
UmgebungsvariablenAbgedecktVollständige Referenz

Testen 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 Reverse Proxy: Webhook-Fix + Task Runners
    • Produktion: 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:
    • HTTPS funktioniert mit gültigem Zertifikat überprüfen
    • Webhook-URLs zeigen korrektes Format prüfen
    • Mit großem Datensatz testen (falls nötig)
    • Task Runners sind registriert bestätigen
  4. Überwachen:
    • Ressourcenverbrauch mit docker stats beobachten
    • Healthcheck-Alerts einrichten (externes Monitoring)
    • Log-Rotation implementieren, um Festplattenfüllung zu verhindern
    • Regelmäßige Backups der Datenvolumes planen

Verwandte Ressourcen

Von 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 für neueste Features
  3. Durchsuchen Sie die n8n-Community-Foren nach ähnlichen Problemen
  4. Prüfen Sie den Fehlerbehebungsabschnitt oben für häufige Probleme
  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 Produktions-Setup 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 Produktion
Basierend auf: Offizielle n8n-Dokumentation, validierte Docker-Tests und Community-Best-Practices