Hunderte inaktive n8n-Workflows können wenig Ressourcen brauchen, während wenige schwere Workflows hohe Execution-Last erzeugen. Aktuelle n8n-Doku empfiehlt Queue Mode für beste Skalierbarkeit: Main legt Jobs in Redis, Worker führen aus, Postgres speichert persistent.
Queue Mode verteilt Execution-Last vom Main auf Worker. Worker können horizontal skaliert werden; `--concurrency` steuert Jobs pro Worker. Queue Mode benötigt Redis und eine unterstützte Production-DB.
Main koordiniert Workflows und Trigger/Webhooks, Jobs landen in Redis, Worker führen aus und persistenter State liegt in der Datenbank.
Kurzer HTTP-Workflow und Code-/Datei-intensiver Workflow verbrauchen sehr unterschiedliche CPU/RAM-Zeit.
n8n Queue-Worker unterstützen Concurrency-Steuerung. CPU-intensive Code Tasks und IO-bound API-Workflows brauchen ggf. unterschiedliche Concurrency. Task Runner benötigen zusätzliche Worker-seitige Planung.
Container-Namen variieren; Main, Worker, Redis und Postgres separat beobachten.
docker compose psdocker stats --no-streamdocker compose logs --tail=100 workerdocker compose logs --tail=100 n8nredis-cli PING 2>/dev/null || truepg_isready 2>/dev/null || trueBei Migration müssen Encryption Key, DB-State, Binary Data und Webhook URLs konsistent bleiben.
Ja. Queue Mode verteilt Execution Jobs zwischen Main und Workern über eine Redis-basierte Queue.
Abhängig von Execution Rate, Duration, Concurrency und Workload-Typ; Workflow-Anzahl allein reicht nicht.
Aktuelle n8n-Doku bezeichnet Queue Mode als beste Skalierbarkeit.
Teilen Sie Executions pro Minute, Workflow-Dauer, Binary Payloads, Code Nodes und Webhook-Volumen; Main/Redis/Postgres/Worker planen.