n8n Queue Mode: mit Redis und Workern skalieren

n8n Queue Mode ist ein Ausführungsmodus für selbstgehostete n8n-Installationen, bei dem eine Hauptinstanz Workflows nicht mehr selbst ausführt, sondern Ausführungs-Aufträge über eine Redis-Warteschlange an separate Worker-Prozesse verteilt. Aktiviert wird der Modus mit der Umgebungsvariable EXECUTIONS_MODE=queue auf Haupt- und Worker-Instanz, als Datenbank empfiehlt n8n Postgres statt SQLite. Sinnvoll ist Queue Mode bei hoher Webhook-Last oder vielen parallelen Ausführungen, für kleine Setups mit wenigen täglichen Läufen ist er dagegen meist unnötiger Infrastruktur-Aufwand. Stand: Juli 2026.

Wie funktioniert n8n Queue Mode technisch?

Die Hauptinstanz übernimmt Trigger, Webhook-Aufrufe und die Oberfläche, führt Workflows im Queue Mode aber nicht mehr selbst aus, sondern erzeugt eine Ausführungs-ID und legt sie in einer Redis-Warteschlange ab. Ein verfügbarer Worker holt sich den Auftrag aus dieser Queue, lädt die Workflow-Details anhand der Ausführungs-ID aus der Datenbank, führt den Workflow aus und schreibt das Ergebnis zurück in die Datenbank. Redis meldet den Abschluss an die Hauptinstanz zurück. Worker sind eigenständige Node.js-Prozesse, die parallel zueinander laufen und einzeln gestartet werden, etwa über den Befehl n8n worker. Details zu diesem Ablauf beschreibt n8n in der Anleitung Enable queue mode.

Wann ist Queue Mode wirklich nötig?

Queue Mode lohnt sich, sobald eine einzelne n8n-Instanz an ihre Grenzen kommt, etwa weil sehr viele Webhooks gleichzeitig eingehen oder mehrere Workflows parallel laufen sollen, ohne sich gegenseitig auszubremsen. In der Standardkonfiguration ohne Queue Mode begrenzt n8n die Zahl gleichzeitiger Produktiv-Ausführungen nicht von sich aus, was bei hoher Last dazu führen kann, dass der Event Loop überlastet wird und die Instanz träge reagiert. Mit Queue Mode verteilen Sie diese Last auf mehrere Worker und können bei wachsendem Bedarf einfach weitere Worker hinzufügen, statt eine einzelne Instanz vertikal aufzurüsten. Auch für Hochverfügbarkeit mit mehreren Hauptinstanzen ist Queue Mode die Voraussetzung, dieses Multi-Main-Setup ist allerdings eine Enterprise-Funktion.

Wann ist Queue Mode für Ihr Setup Overkill?

Für die meisten kleinen und mittleren Unternehmen mit wenigen Dutzend Automatisierungen und überschaubarer Ausführungszahl pro Tag reicht eine einzelne n8n-Instanz ohne Queue Mode völlig aus. Statt Redis, mehrere Worker-Container und zusätzliches Monitoring aufzubauen, lässt sich drohende Überlastung oft schon mit der Umgebungsvariable N8N_CONCURRENCY_PRODUCTION_LIMIT abfangen, die parallele Produktiv-Ausführungen auf einer einzigen Instanz begrenzt, ohne dass eine separate Queue-Infrastruktur nötig wird. Jede zusätzliche Komponente wie Redis oder zusätzliche Worker-Prozesse ist auch ein zusätzlicher Bestandteil, der überwacht, aktualisiert und im Fehlerfall repariert werden muss. Wer nur gelegentlich Formulardaten verarbeitet, tägliche Reports verschickt oder ein CRM synchronisiert, bekommt durch Queue Mode keinen spürbaren Vorteil, aber deutlich mehr Betriebsaufwand.

Was müssen Sie bei der Einrichtung technisch beachten?

Für einen produktiven Queue-Mode-Betrieb braucht es laut n8n zwingend eine gemeinsame Redis-Instanz als Message Broker sowie Postgres als Datenbank, SQLite wird für den verteilten Betrieb nicht empfohlen. Der Verschlüsselungsschlüssel N8N_ENCRYPTION_KEY muss auf Haupt- und allen Worker-Instanzen identisch gesetzt sein, sonst können Worker gespeicherte Zugangsdaten nicht entschlüsseln. Jeder Worker verarbeitet standardmäßig bis zu zehn Jobs parallel, steuerbar über das Flag --concurrency, wobei n8n empfiehlt, den Wert nicht zu niedrig anzusetzen, da sonst bei vielen Workern der Verbindungspool der Datenbank erschöpft werden kann. Wichtig ist außerdem, dass Queue Mode Binärdaten nicht im lokalen Dateisystem des jeweiligen Workers ablegen kann, hierfür ist externer Speicher wie S3 vorgesehen. Die vollständige Liste der Umgebungsvariablen führt n8n unter Queue mode environment variables auf.

Wer unsicher ist, ob das eigene n8n-Setup tatsächlich Queue Mode braucht oder mit einer einzelnen, sauber konfigurierten Instanz auskommt, lässt das am besten im Rahmen einer technischen Bestandsaufnahme prüfen, etwa in der n8n-Beratung von NordFlux.

Häufige Fragen zu n8n Queue Mode

Brauche ich für n8n Queue Mode zwingend Redis?

Ja, Redis ist im Queue Mode fester Bestandteil der Architektur und übernimmt die Warteschlange, aus der Worker ihre Aufträge abholen. Ohne laufende Redis-Instanz können Hauptinstanz und Worker nicht miteinander kommunizieren, der Queue Mode lässt sich also nicht ohne Redis betreiben.

Kann ich Queue Mode mit SQLite als Datenbank nutzen?

Nein, für den Queue Mode empfiehlt n8n Postgres ab Version 13, SQLite wird für diesen verteilten Betrieb nicht empfohlen. Da mehrere Worker gleichzeitig lesend und schreibend auf dieselbe Datenbank zugreifen, ist eine dafür ausgelegte Server-Datenbank wie Postgres die sinnvollere Wahl.

Wie viele Worker sollte ich einplanen?

Es gibt keinen pauschalen Richtwert, jeder Worker verarbeitet standardmäßig bis zu zehn Jobs gleichzeitig, konfigurierbar über das --concurrency-Flag. Sinnvoller als von Anfang an viele Worker zu starten ist es, mit einem oder zwei Workern zu beginnen und bei steigender Last gezielt weitere hinzuzufügen.

Was passiert mit Dateien und Anhängen im Queue Mode?

Binärdaten wie hochgeladene Dateien lassen sich im Queue Mode nicht im lokalen Dateisystem eines Workers speichern, weil der nächste Verarbeitungsschritt auf einem anderen Worker laufen kann. Stattdessen muss externer Speicher wie S3 eingebunden werden, damit alle Worker auf dieselben Binärdaten zugreifen können.