n8n in Produktion betreiben: Docker Compose, Queue Mode und Postgres-Backend

Warum n8n in der Produktion

n8n ist die führende Open-Source-Plattform für Workflow-Automatisierung. In kleinem Rahmen funktionieren SQLite und der Single-Process-Modus einwandfrei. Sobald man jedoch etwa 50 aktive Workflows überschreitet oder Zuverlässigkeitsgarantien benötigt, erfordert ein Production-Deployment:

• PostgreSQL-Backend: Gleichzeitige Schreibzugriffe, bessere Performance, Point-in-Time-Recovery
• Redis-Queue: Trennung der Webhook-Verarbeitung von den Execution-Workern
• Persistente verschlüsselte Credentials: Gemountete Secrets, die Container-Neustarts überstehen
• Execution Pruning: Automatische Bereinigung abgeschlossener Ausführungen, um ein Anwachsen der Festplatte zu verhindern

Architektur

Kernkonfiguration

Umgebungsvariablen

Die kritischen Konfigurationsparameter für ein n8n Production-Deployment:

DB_TYPE=postgresdb
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=change-me

# Queue — Redis for multi-process mode
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

# Encryption — MUST be set, auto-generated if missing
ENCRYPTION_KEY=your-32-char-encryption-key

# Security
N8N_METRICS=false
N8N_DIAGNOSTICS_ENABLED=false
N8N_PERSONALIZATION_ENABLED=false
N8N_HIRING_BANNER_ENABLED=false
N8N_DISABLE_PRODUCTION_MAIN_PROCESS=false

Queue Mode vs. Single Process

Die wichtigste Entscheidung ist der Ausführungsmodus:

Modus	Funktionsweise	Bestens geeignet für
Single (Standard)	Alles in einem Prozess	Entwicklung, <50 Workflows
Queue (Produktion)	Web-Prozess delegiert an Worker	Produktion, >50 Workflows

Im Queue-Modus:

• Der Hauptprozess verwaltet das Web-UI, die API, Webhooks und das Credential-Management
• Worker-Prozesse ziehen Execution-Jobs aus Redis und führen diese unabhängig aus
• Worker können horizontal skaliert werden – fügen Sie weitere hinzu, um die Kapazität für parallele Ausführungen zu erhöhen

PostgreSQL Tuning

n8n erzeugt durch Execution-Logs eine erhebliche Datenbanklast. Optimieren Sie PostgreSQL für diese Arbeitslast:

# Recommended postgres.conf tweaks for n8n
shared_buffers = '1GB'           # 25% of available RAM
effective_cache_size = '3GB'     # 75% of available RAM
work_mem = '64MB'                # Per-operation sort memory
maintenance_work_mem = '256MB'   # For VACUUM
wal_buffers = '16MB'
random_page_cost = 1.1           # SSD-optimized
effective_io_concurrency = 200   # SSD-optimized

Die Execution-Tabellen von n8n wachsen schnell. Eine ausgelastete Instanz mit 1000 Ausführungen pro Tag generiert etwa 500 MB an Execution-Daten pro Monat. Planen Sie den Speicher entsprechend ein.

Execution Pruning

Ein produktives n8n muss über ein konfiguriertes Execution Pruning verfügen. Ohne dieses füllt sich die Festplatte innerhalb weniger Wochen:

# Automatically delete executions older than N days
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168      # Hours (7 days)

# Optional: save only failed/saved executions, discard successful
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_MANUAL=all

Dies hält die Datenbank schlank, während fehlgeschlagene Ausführungen für das Debugging erhalten bleiben.

Worker skalieren

Im Queue-Modus sind Worker-Prozesse vollständig zustandslos. Skalieren Sie, indem Sie weitere Worker-Container hinzufügen:

# In docker-compose.yml, multiple workers
n8n-worker-1:
  <<: *n8n-base
  command: worker --concurrency=10
  depends_on:
    - redis

n8n-worker-2:
  <<: *n8n-base
  command: worker --concurrency=10
  depends_on:
    - redis

Das --concurrency Flag steuert, wie viele Ausführungen jeder Worker parallel ausführt. Der Standardwert ist 10. Skalieren Sie die Worker, wenn Sie Waiting for execution in den Logs sehen, während CPU-Ressourcen verfügbar sind.

Production-Checkliste

• ENCRYPTION_KEY auf einen zufälligen 32-Zeichen-String setzen (nutzen Sie openssl rand -hex 16)
• Starkes PostgreSQL-Passwort festlegen
• EXECUTIONS_DATA_PRUNE aktivieren — Standard ist AUS, was die Festplatte füllt
• N8N_ENCRYPTION_KEY als Docker-Secret konfigurieren, nicht als Klartext-Umgebungsvariable
• ~/.n8n als Persistent Volume für Verschlüsselungs-Keys mounten
• Health Checks einrichten: /healthz gibt 200 zurück, wenn bereit
• Tägliche Datenbank-Backups konfigurieren (pg_dump für Postgres, RDB für Redis)
• n8n-Version auf ein spezifisches Release fixieren, nicht :latest

Key Takeaways

• PostgreSQL + Redis + Queue mode ist das einzige Production-Setup für n8n — alles andere ist nur temporär
• Execution Pruning ist obligatorisch — ohne dieses füllt sich die Festplatte in 2-4 Wochen
• Worker skalieren horizontal — fügen Sie weitere Container hinzu, wenn die Queues ansteigen
• Credentials sind im Ruhezustand verschlüsselt via ENCRYPTION_KEY — bewahren Sie diesen sicher auf