{"id":29285,"date":"2026-02-16T09:53:00","date_gmt":"2026-02-16T08:53:00","guid":{"rendered":"https:\/\/contabo.com\/blog\/n8n-queue-modus-einrichtungsanleitung-fuer-vps-skalierbarkeit\/"},"modified":"2026-03-23T10:46:20","modified_gmt":"2026-03-23T09:46:20","slug":"n8n-queue-modus-einrichtungsanleitung-fuer-vps-skalierbarkeit","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/de\/n8n-queue-modus-einrichtungsanleitung-fuer-vps-skalierbarkeit\/","title":{"rendered":"Setup-Guide f\u00fcr den n8n Queue-Modus"},"content":{"rendered":"\n
\"Setup-Guide<\/figure>\n\n\n\n

Eine einzelne n8n-Instanz hat etwa sechs Monate lang einwandfrei funktioniert. Dann erreichten wir \u00fcber 200 Workflow-Ausf\u00fchrungen pro Tag und alles wurde qu\u00e4lend langsam: Webhooks liefen in Timeouts, die UI hing beim \u00d6ffnen des Editors, neue Workflows warteten 30 Sekunden, bis sie \u00fcberhaupt starten konnten, weil irgendein CSV-Verarbeitungsjob den einzigen verf\u00fcgbaren Thread blockierte. Die Skalierbarkeit von n8n war schlicht nicht gegeben.<\/p>\n\n\n\n

Der n8n Queue-Modus l\u00f6st das Problem, indem er die Aufgaben in deinem n8n-Docker-Setup aufteilt. Ein n8n-Prozess k\u00fcmmert sich um die Web-Oberfl\u00e4che und lauscht auf eingehende Trigger wie Webhooks, Zeitpl\u00e4ne und manuelle Ausf\u00fchrungen. Separate Worker-Prozesse – ob drei oder zehn – holen sich Jobs aus einer Redis-Queue und f\u00fchren die Workflows tats\u00e4chlich aus. So k\u00f6nnen jetzt zehn Workflows gleichzeitig laufen, statt nacheinander in der Warteschlange zu stehen. Das ist echte Workflow-Automatisierung.<\/p>\n\n\n\n

Du konfigurierst das Ganze mit Docker Compose, Redis als Job-Queue und PostgreSQL, weil SQLite mit mehreren Prozessen nicht klarkommt (genauer gesagt: \u00fcberhaupt nicht). Umgebungsvariablen m\u00fcssen in allen Containern exakt \u00fcbereinstimmen, sonst funktioniert nichts. Du brauchst VPS-Zugang und Docker-Kenntnisse. Rechne mit Fehlersuche. Am Ende hast du aber ein Setup, das hunderte gleichzeitige Workflow-Ausf\u00fchrungen wegsteckt, ohne ins Stocken zu geraten.<\/a><\/p>\n\n\n\n

Bereit loszulegen?<\/p>\n\n\n\n

So funktioniert der n8n Queue-Modus<\/h2>\n\n\n\n

Standard-n8n packt alles in einen einzigen Prozess. Die Weboberfl\u00e4che l\u00e4uft dort. Webhook-Listener laufen dort. Workflow-Ausf\u00fchrungen laufen dort. Alle k\u00e4mpfen um CPU und Arbeitsspeicher. Starte einen Workflow, der eine 50-MB-Datei verarbeitet, und alles andere wartet. Dein Kollege versucht, einen Workflow im Editor zu \u00f6ffnen: 15 Sekunden Ladekreisel. Ein Webhook von Stripe trifft deinen Endpunkt und du bekommst einen Timeout, weil der Prozess ausgelastet ist.<\/p>\n\n\n\n

Der Queue-Modus trennt die Zust\u00e4ndigkeiten in der n8n-Queue-Modus-Architektur. Der Hauptprozess bedient die Web-UI und lauscht auf Trigger. Wenn ein Workflow ausgef\u00fchrt werden muss, fasst der Hauptprozess ihn nicht an. Er schiebt einfach eine Jobbeschreibung in Redis, mit Details wie Workflow-ID, Trigger-Daten und den zu verwendenden Zugangsdaten. Dann widmet er sich der n\u00e4chsten Aufgabe.<\/a><\/p>\n\n\n\n

Worker \u00fcberwachen den Redis-Message-Broker permanent. Sie laufen in einer engen Schleife: Queue pr\u00fcfen, Job holen falls vorhanden, ausf\u00fchren, Ergebnisse in PostgreSQL schreiben, Queue erneut pr\u00fcfen. Redis (intern mit Bull) verwaltet diese Queues, in denen Jobs warten, bis ein Worker frei ist. Wenn zehn Workflows gleichzeitig getriggert werden und du zehn Worker laufen hast, werden alle zehn auf einmal ausgef\u00fchrt.<\/p>\n\n\n\n

Alles verbindet sich mit derselben PostgreSQL-Datenbank. Dort liegen Zugangsdaten, Workflow-Definitionen und die Ausf\u00fchrungshistorie. Dieser gemeinsame State bedeutet: Jeder Worker kann jeden Workflow ausf\u00fchren. Es gibt kein Festpinnen bestimmter Jobs auf bestimmte Maschinen, was f\u00fcr die Workflow-Orchestrierung ein Albtraum w\u00e4re. Die Datenbank trackt den Ausf\u00fchrungsstatus in Echtzeit. Der Hauptprozess zeigt dir Fortschrittsupdates in der UI, obwohl die Ausf\u00fchrung auf einem v\u00f6llig anderen Container stattfindet.<\/p>\n\n\n\n

Die parallele Ausf\u00fchrung ist der Grund, warum sich dieser ganze Aufwand lohnt. Ein Workflow, der 10.000 Tabellenzeilen durcharbeitet, blockiert nicht einen anderen Workflow, der nur eine Slack-Nachricht senden muss. Schwere Dateioperationen f\u00fchrst du am besten auf dedizierten Workern mit mehr RAM aus, w\u00e4hrend reine API-Workflows auf kleineren Workern laufen. Das h\u00e4ngt aber von deinen Workflows ab.<\/p>\n\n\n\n

Voraussetzungen<\/h2>\n\n\n\n

Du brauchst ein n8n VPS<\/a> oder einen Dedicated Server<\/a> mit mindestens 2 CPU-Kernen und 4 GB RAM. F\u00fcr den Produktionsbetrieb mit echtem Workflow-Automatisierungsvolumen solltest du 4+ Kerne und 8 GB+ einplanen. Ein Cloud VPS 10 von Contabo ist ein guter Ausgangspunkt. Redis und PostgreSQL zusammen verbrauchen rund 1 GB. Jeder Worker-Prozess belegt zwischen 200 MB und 500 MB, je nachdem, was deine Workflows machen. Komplexe Workflows mit vielen Datentransformationen brauchen mehr.<\/p>\n\n\n\n

Docker und Docker-Compose m\u00fcssen installiert und funktionsf\u00e4hig sein. Diese Anleitung setzt Docker 24+ und Compose v2 voraus. Wenn du noch (mit Bindestrich) statt (mit Leerzeichen) tippst, nutzt du die alte Version und solltest upgraden. Die Syntax des n8n Docker-Compose hat sich k\u00fcrzlich ge\u00e4ndert.<\/a><\/p>\n\n\n\n

Du solltest die Grundlagen von n8n Self-Hosted bereits kennen. Das hier ist nicht „deine erste n8n-Installation“. Du musst Workflows verstehen, wissen, wie Zugangsdaten funktionieren, und mit den n8n-Konzepten rund um Umgebungsvariablen vertraut sein. Der Queue-Modus baut auf diesem Fundament auf und f\u00fcgt weitere Komplexit\u00e4t hinzu. Wenn du neu bist, fang einfach an: Such nach „n8n“ in unserem Blog, dort findest du viele hilfreiche Artikel f\u00fcr den Einstieg.<\/p>\n\n\n\n

PostgreSQL-Kenntnisse sind hilfreich, aber nicht zwingend n\u00f6tig. Du bringst ein PostgreSQL-Docker-Setup zum Laufen, aber die eigentlichen Datenbankoperationen passieren automatisch, sobald die Verbindungsstrings stimmen. SQLite funktioniert mit dem Queue-Modus \u00fcberhaupt nicht. Mehrere Prozesse, die gleichzeitig auf dieselbe SQLite-Datei zugreifen, f\u00fchren zu Datenkorruption. PostgreSQL ist Pflicht, kein Vorschlag.<\/p>\n\n\n\n

Sicherheit auf der Kommandozeile ist essenziell. Du wirst docker-compose.yml-Dateien bearbeiten, Umgebungsvariablen setzen (jede Menge davon) und Docker-Befehle ausf\u00fchren, um Worker hoch- und herunterzufahren. Au\u00dferdem musst du Logs pr\u00fcfen, wenn Container nicht starten. Falls dich das Navigieren durch Verzeichnisse im Terminal und das Lesen von Fehlermeldungen nerv\u00f6s macht, arbeite dich da erst einmal ein.<\/p>\n\n\n\n

n8n Queue-Modus konfigurieren<\/h2>\n\n\n\n

Die n8n-Konfiguration f\u00fcr den Queue-Modus folgt einer bestimmten Reihenfolge. Du gehst das n8n Docker-Compose-Setup systematisch durch: Zuerst Redis, weil Worker sich sofort beim Start verbinden wollen. Dann die n8n-Umgebungsvariablen, die in allen Containern \u00fcbereinstimmen m\u00fcssen. Dann PostgreSQL, dann der n8n-Hauptprozess und zum Schluss die Worker. Wenn du Schritte \u00fcberspringst, bekommst du Abh\u00e4ngigkeitsfehler: Container st\u00fcrzen ab, weil sie sich mit Diensten verbinden wollen, die noch nicht existieren. Wenn du sp\u00e4ter Kapazit\u00e4t brauchst, nutzt du Docker Compose-Scale-Befehle, um weitere Worker hochzufahren. Aber das initiale Setup muss in genau dieser Reihenfolge passieren.<\/p>\n\n\n\n

Redis-Container vorbereiten<\/h3>\n\n\n\n

Redis ist das Fundament f\u00fcr die Jobverteilung von n8n. Worker holen Jobs aus der Redis-Queue. Der Hauptprozess schiebt neue Ausf\u00fchrungen in diese Queues. Ohne laufendes Redis funktioniert der Queue-Modus schlicht nicht.\u200b<\/p>\n\n\n\n

Erstelle ein Verzeichnis f\u00fcr dein Setup und f\u00fcge Redis zu deiner Docker-Compose-Konfiguration hinzu. Hier die grundlegende Service-Definition:<\/p>\n\n\n\n

redis:
  image: redis:7-alpine
  container_name: n8n_redis
  ports:
    - \"6379:6379\"
  volumes:
    - redis_data:\/data
  command: redis-server --appendonly yes
  restart: unless-stopped
<\/code><\/pre>\n\n\n\n
Das --appendonly yes<\/code> Flag aktiviert die Redis-Persistenz. Ohne dieses Flag bedeutet ein Neustart der Redis-Container-Instanz, dass alle Jobs in der Queue verloren gehen. Endg\u00fcltig weg. Der Volume-Mount speichert diese persistenten Daten auf der Festplatte.\u200b<\/p>\n\n\n\n
F\u00fcr die n8n-Redis-Verbindung verwenden Worker und Hauptprozess als Hostnamen redis<\/code>\u00a0, da sie alle im selben Docker-Netzwerk laufen. Port 6379 ist der Redis-Standard. Du kannst Passwort-Authentifizierung mit im Befehl --requirepass yourpassword<\/code> hinzuf\u00fcgen, wobei das f\u00fcr Container in einem privaten Docker-Netzwerk optional ist.<\/p>\n\n\n\n
Starte nur Redis: docker compose up -d redis<\/code>. Pr\u00fcfe die Logs sofort: docker logs n8n_redis<\/code>. Du solltest „Ready to accept connections“ ohne Fehler sehen. Teste es von deinem Host mit redis-cli ping<\/code>, bevor du weitermachst. Erkenne Verbindungsprobleme lieber jetzt als nach der Konfiguration von sechs weiteren Containern.<\/p>\n\n\n\n
Umgebungsvariablen konfigurieren<\/h3>\n\n\n\n
Umgebungsvariablen steuern, wie n8n im Queue-Modus arbeitet. Bei falscher n8n-Konfiguration kommunizieren Prozesse nicht miteinander, Worker starten nicht, oder schlimmer: Worker funktionieren teilweise, besch\u00e4digen aber Daten, weil der Encryption-Key nicht \u00fcbereinstimmt.\u200b<\/p>\n\n\n\n
Hier die kritischen n8n-Umgebungsvariablen f\u00fcr das Setup:<\/a><\/p>\n\n\n\n
EXECUTIONS_MODE=queue<\/strong> schaltet n8n vom Standard- in den Queue-Modus. Setze das sowohl beim Hauptprozess als auch bei allen Workern. Ohne diese Variable l\u00e4uft n8n im normalen Einzelprozessmodus und ignoriert Redis komplett.<\/a><\/p>\n\n\n\n
N8N_ENCRYPTION_KEY<\/strong> muss beim Hauptprozess und jedem einzelnen Worker identisch sein. Damit werden Zugangsdaten in der Datenbank verschl\u00fcsselt. Worker mit einem anderen Key k\u00f6nnen Zugangsdaten nicht entschl\u00fcsseln. Workflows laufen dann zwar, scheitern aber beim Zugriff auf APIs oder Datenbanken. Stille Fehler sind die schlimmste Art von Fehlern. Generiere einmal einen langen zuf\u00e4lligen String, verwende ihn \u00fcberall und \u00e4ndere ihn nach dem Deployment nie mehr, es sei denn, du willst alle verschl\u00fcsselten Daten manuell migrieren.<\/a><\/p>\n\n\n\n
QUEUE_BULL_REDIS_HOST<\/strong> und QUEUE_BULL_REDIS_PORT<\/strong> zeigen auf Redis. Verwende den Docker-Servicenamen  als Host, da Container \u00fcber Dockers internes Netzwerk kommunizieren. Der Port ist , sofern du ihn nicht ge\u00e4ndert hast.<\/a><\/p>\n\n\n\n
DB_TYPE=postgresdb<\/strong> schaltet von SQLite auf PostgreSQL um. Dann erg\u00e4nze: DB_POSTGRESDB_HOST<\/strong>, DB_POSTGRESDB_DATABASE<\/strong>, DB_POSTGRESDB_USER<\/strong> und DB_POSTGRESDB_PASSWORD<\/strong>. Alle Prozesse verbinden sich mit derselben Datenbank und denselben Zugangsdaten.<\/a><\/p>\n\n\n\n
Lege diese in eine .env<\/code>-Datei oder direkt in die docker-compose.yml unter den Environment-Abschnitten. Die Konfiguration bleibt bei Haupt- und Worker-Prozessen konsistent, bis auf einige Worker-spezifische Einstellungen.<\/a>\u200b<\/p>\n\n\n\n
Hauptprozess von n8n bereitstellen<\/h3>\n\n\n\n
Der n8n-Hauptprozess verwaltet die Web-UI, stellt die API bereit und reiht Workflow-Ausf\u00fchrungen in die Queue ein, f\u00fchrt sie aber nicht selbst aus. Nutzer greifen \u00fcber Port 5678 darauf zu. Das ist der Kern deines n8n-Deployments.\u200b<\/p>\n\n\n\n
Hier die n8n-Docker-Service-Definition in der docker-compose.yml f\u00fcr die n8n-Installation:<\/a><\/p>\n\n\n\n
n8n:
  image: n8nio\/n8n:latest
  container_name: n8n_main
  ports:
    - \"5678:5678\"
  environment:
    - EXECUTIONS_MODE=queue
    - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    - QUEUE_BULL_REDIS_HOST=redis
    - QUEUE_BULL_REDIS_PORT=6379
    - DB_TYPE=postgresdb
    - DB_POSTGRESDB_HOST=postgres
    - DB_POSTGRESDB_DATABASE=n8ndb
    - DB_POSTGRESDB_USER=n8n
    - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
  volumes:
    - n8n_data:\/home\/node\/.n8n
  depends_on:
    - postgres
    - redis
  restart: unless-stopped
<\/code><\/pre>\n\n\n\n
Das depends_on stellt sicher, dass PostgreSQL und Redis starten, bevor n8n sich verbinden will. Volume-Mounts persistieren Workflow-Dateien und Custom Nodes au\u00dferhalb des Containers.<\/a>\u200b<\/p>\n\n\n\n
Starte es: docker compose up -d n8n<\/code>. Pr\u00fcfe die Logs direkt: docker logs -f n8n_main<\/code>. Du solltest erfolgreiche Datenbankverbindungs-Meldungen und „Editor is now accessible via“ ohne Fehler sehen. Redis-Verbindungsfehler oder Datenbankfehler bedeuten: Stopp. Erst beheben, bevor du mit den Workern weitermachst. Wenn der Hauptprozess seine Abh\u00e4ngigkeiten nicht erreicht, funktioniert nichts korrekt.<\/p>\n\n\n\n
Rufe die Web-UI auf unter http:\/\/your-vps-ip:5678<\/code>. Erstelle einen Test-Workflow, f\u00fchre ihn aber noch nicht aus. Worker laufen noch nicht, Ausf\u00fchrungen w\u00fcrden also ewig in der Queue h\u00e4ngen.<\/p>\n\n\n\n
PostgreSQL-Datenbank bereitstellen<\/h3>\n\n\n\n
PostgreSQL speichert Workflows, Zugangsdaten, Ausf\u00fchrungshistorie und Queue-Status. Der Queue-Modus braucht PostgreSQL, weil mehrere Prozesse gleichzeitig auf die n8n-Datenbank zugreifen. SQLite kann das nicht sicher handhaben. Genauer gesagt: Es schafft das gar nicht, ohne Daten zu besch\u00e4digen.<\/p>\n\n\n\n
F\u00fcge den n8n-PostgreSQL-Service zur docker-compose.yml hinzu:<\/p>\n\n\n\n
postgres:
  image: postgres:15-alpine
  container_name: n8n_postgres
  environment:
    - POSTGRES_USER=n8n
    - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    - POSTGRES_DB=n8ndb
  volumes:
    - postgres_data:\/var\/lib\/postgresql\/data
  restart: unless-stopped
<\/code><\/pre>\n\n\n\n
Die Datenbank-Zugangsdaten hier m\u00fcssen mit denen in deiner n8n-Hauptkonfiguration \u00fcbereinstimmen. Der PostgreSQL-Container persistiert Daten in einem Docker-Volume, sodass Inhalte Neustarts \u00fcberstehen.<\/p>\n\n\n\n
Beim PostgreSQL-Docker-Setup initialisiert sich die Datenbank beim ersten Start automatisch. Du musst keine SQL-Skripte manuell ausf\u00fchren. n8n \u00fcbernimmt die Schema-Erstellung beim ersten Verbindungsaufbau. Starte PostgreSQL: docker compose up -d postgres<\/code>. Pr\u00fcfe die Logs: docker logs n8n_postgres<\/code>. Achte auf „database system is ready to accept connections.“\u200b<\/p>\n\n\n\n
Wenn du den n8n-Hauptprozess bereits gestartet hast, verbindet er sich automatisch mit PostgreSQL und initialisiert die Tabellen. Pr\u00fcfe die n8n-Logs erneut auf erfolgreiche Datenbankmigrationen.<\/p>\n\n\n\n
n8n Worker-Prozesse starten<\/h3>\n\n\n\n
Worker sind n8n-Instanzen, die im Worker-Modus laufen. Keine Weboberfl\u00e4che. Keine offenen Ports. Sie holen Jobs aus Redis, f\u00fchren Workflows aus und schreiben Ergebnisse in PostgreSQL. Das war’s.<\/a>\u200b<\/p>\n\n\n\n
Hier die n8n-Worker-Service-Definition, \u00e4hnlich wie die Hauptdefinition, aber mit den entscheidenden Unterschieden:<\/p>\n\n\n\n
n8n-worker:
  image: n8nio\/n8n:latest
  command: worker
  environment:
    - EXECUTIONS_MODE=queue
    - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    - QUEUE_BULL_REDIS_HOST=redis
    - QUEUE_BULL_REDIS_PORT=6379
    - DB_TYPE=postgresdb
    - DB_POSTGRESDB_HOST=postgres
    - DB_POSTGRESDB_DATABASE=n8ndb
    - DB_POSTGRESDB_USER=n8n
    - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
  depends_on:
    - postgres
    - redis
    - n8n
  restart: unless-stopped
<\/code><\/pre>\n\n\n\n
Der Worker-Befehl weist n8n an, im Worker-Modus zu laufen statt die Web-UI bereitzustellen. Der n8n Encryption-Key muss exakt mit dem des Hauptprozesses \u00fcbereinstimmen. Worker entschl\u00fcsseln mit diesem Key die Zugangsdaten aus der Datenbank. Bei Abweichung laufen Workflows zwar, k\u00f6nnen aber nicht auf Zugangsdaten zugreifen. Das erzeugt stille Fehler, die extrem schwer zu debuggen sind.<\/p>\n\n\n\n
Starte zun\u00e4chst einen Worker: docker compose up -d n8n-worker<\/code>. Pr\u00fcfe die Logs: docker logs n8n-worker<\/code>. Du solltest „n8n worker is now ready“ sowie Verbindungsmeldungen f\u00fcr Redis und PostgreSQL sehen. n8n-Worker protokollieren, wenn sie Jobs aufnehmen. Anfangs siehst du also nur Initialisierungsmeldungen.<\/p>\n\n\n\n
Skaliere die Worker mit Docker-Compose: docker compose up -d --scale n8n-worker=3<\/code>. Das erstellt drei Worker-Container aus derselben Service-Definition. Jeder verbindet sich mit derselben Redis-Queue und PostgreSQL-Datenbank und holt Jobs unabh\u00e4ngig.<\/a>\u200b<\/p>\n\n\n\n
Wie viele Worker du brauchst, h\u00e4ngt von deiner tats\u00e4chlichen Last ab, nicht von der Theorie. Starte mit einem oder zwei. Beobachte Queue-Tiefe und Ausf\u00fchrungszeiten unter realer Last. Skaliere hoch, wenn sich Jobs stauen. Jeder Worker verbraucht 200-500 MB RAM. Zehn Worker auf einem 4-GB-VPS f\u00fchren zu OOM-Kills.<\/a>\u200b<\/p>\n\n\n\n
n8n Queue-Setup testen<\/h3>\n\n\n\n
Erstelle einen Workflow mit einem Wait-Node, der auf 10 Sekunden eingestellt ist. F\u00fcge einfache HTTP-Request-Nodes davor und danach ein, damit du den Ausf\u00fchrungsfluss beobachten kannst. Speichern und aktivieren.<\/a>\u200b<\/p>\n\n\n\n
L\u00f6se den Workflow manuell dreimal schnell hintereinander \u00fcber die n8n-Weboberfl\u00e4che aus. Im Standardmodus w\u00fcrde das nacheinander ablaufen: insgesamt 30+ Sekunden. Mit laufenden Workern werden sie parallel ausgef\u00fchrt.<\/p>\n\n\n\n
Pr\u00fcfe die Ausf\u00fchrungsliste in der n8n-Web-UI. Alle drei sollten gleichzeitig den Status „Running“ zeigen, wenn die Worker parallel arbeiten. Schau dir die Worker-Logs mit docker logs n8n-worker<\/code> an: das zeigt dir, welcher Worker welche Ausf\u00fchrung \u00fcbernommen hat. Du siehst Meldungen wie „Job picked up“ mit Ausf\u00fchrungs-IDs.<\/p>\n\n\n\n
Das n8n-Automatisierungs-Monitoring in der Web-UI zeigt die Ausf\u00fchrungszeiten. Vergleiche mit dem Standardmodus. Der Queue-Modus hat oft etwas l\u00e4ngere Ausf\u00fchrungszeiten pro Einzellauf wegen des Queuing-Overheads. Der Gesamtdurchsatz steigt aber massiv, weil Workflows parallel laufen.<\/p>\n\n\n\n
n8n Worker \u00fcberwachen und skalieren<\/h3>\n\n\n\n
Beobachte Ausf\u00fchrungszeiten und Queue-Tiefe im realen Betrieb. Wenn die Redis-Queue zu Spitzenzeiten konstant w\u00e4chst, kommen Workflows schneller rein, als die Worker sie abarbeiten k\u00f6nnen. Hochskalieren.<\/a>\u200b<\/p>\n\n\n\n
Worker im laufenden Betrieb hinzuf\u00fcgen: docker compose up -d --scale n8n-worker=5<\/code>. Neue Worker starten sofort und beginnen, Jobs aus der Redis-Queue abzuholen. Keine Workflow-Unterbrechung. Keine Konfigurations\u00e4nderungen. Einfach mehr Kapazit\u00e4t. Hier zeigt sich die Skalierbarkeit von n8n wirklich.<\/a>\u200b<\/p>\n\n\n\n
In ruhigen Zeiten herunterskalieren: docker compose up -d --scale n8n-worker=2<\/code>. Docker stoppt \u00fcberz\u00e4hlige Worker sanft: Sie beenden laufende Jobs, bevor sie herunterfahren. Keine abgebrochenen Ausf\u00fchrungen.<\/p>\n\n\n\n
\u00dcberwache die Ressourcennutzung pro Worker mit docker stats<\/code>. Das zeigt CPU und RAM f\u00fcr jeden Worker-Container. Wenn Worker dauerhaft die CPU auslasten oder ans Speicherlimit sto\u00dfen: entweder Workflows optimieren oder einen gr\u00f6\u00dferen VPS nehmen. n8n-Performance zu verstehen bedeutet, diese Metriken \u00fcber die Zeit zu verfolgen.<\/p>\n\n\n\n
Aktiviere Metriken f\u00fcr tieferes Monitoring. Setze N8N_METRICS=true<\/code> und N8N_METRICS_INCLUDE_API_ENDPOINTS=true<\/code> in den Umgebungsvariablen. Das stellt Prometheus-kompatible Metriken am \/metrics<\/code>-Endpunkt bereit. Dort kannst du Queue-Tiefe, Ausf\u00fchrungsz\u00e4hler und Worker-Performance \u00fcber die Zeit verfolgen.<\/a>\u200b<\/p>\n\n\n\n
Fazit<\/h2>\n\n\n\n
Der Queue-Modus macht aus n8n ein System, das produktionsreife Workloads bew\u00e4ltigen kann. Die Trennung von Web-UI, Job-Queuing und verteilter Ausf\u00fchrung schafft echte n8n-Skalierbarkeit, die mit deinen Anforderungen w\u00e4chst, statt im ung\u00fcnstigsten Moment an harte Grenzen zu sto\u00dfen.<\/a><\/p>\n\n\n\n
Das Setup ist nicht trivial. Du hast Docker Compose \u00fcber mehrere Services hinweg orchestriert, Umgebungsvariablen synchronisiert, die perfekt \u00fcbereinstimmen m\u00fcssen, PostgreSQL- und Redis-Infrastruktur bereitgestellt und Worker-Prozesse gestartet. Aber jetzt hast du ein Workflow-Automatisierungssystem, das hunderte gleichzeitige Ausf\u00fchrungen verarbeitet, ohne einzubrechen.<\/a><\/p>\n\n\n\n
Was als N\u00e4chstes kommt, ist genauso wichtig wie das initiale Setup. Richte automatische PostgreSQL-Backups ein: Workflows, Zugangsdaten und Ausf\u00fchrungshistorie liegen dort. \u00dcberwache die Ressourcennutzung der Worker und skaliere proaktiv anhand von Traffic-Mustern. Bringe Log-Aggregation zum Laufen, damit du Probleme \u00fcber verteilte Worker hinweg analysieren kannst. Sichere Redis ab, wenn dein VPS in Netzwerken h\u00e4ngt, die du nicht kontrollierst.<\/p>\n\n\n\n
VPS-Hosting bedeutet: Du triffst die Skalierungsentscheidungen. Cloud-Dienste mit gemanagtem n8n rechnen pro Ausf\u00fchrung ab oder limitieren Workflows. Den Queue-Modus auf eigener Infrastruktur zu betreiben bedeutet, nach tats\u00e4chlichen Ressourcenkosten zu skalieren statt nach Abo-Stufen. Der Kompromiss: Du tr\u00e4gst die Komplexit\u00e4t. Daf\u00fcr hast du die volle Kontrolle.<\/a>\u200b<\/p>\n\n\n\n
n8n Queue-Modus FAQ<\/h2>\n\n\n\n
Was ist der n8n Queue-Modus?<\/h3>\n\n\n\n
Der n8n Queue-Modus trennt die Weboberfl\u00e4che von der Workflow-Ausf\u00fchrung: \u00fcber eine Redis-basierte Job-Queue und separate Worker-Prozesse. Der n8n-Hauptprozess verwaltet die UI und eingehende Trigger und schiebt Workflow-Jobs in Redis-Queues. Worker-Prozesse \u00fcberwachen diese Queues permanent, holen Jobs ab und f\u00fchren Workflows parallel aus.<\/p>\n\n\n\n
Das erm\u00f6glicht horizontale Skalierung: Du f\u00fcgst mehr Worker hinzu, um h\u00f6here Lasten zu bew\u00e4ltigen, ohne am Workflow-Code etwas \u00e4ndern zu m\u00fcssen. Voraussetzung ist PostgreSQL statt SQLite, da mehrere Prozesse gleichzeitigen Datenbankzugriff brauchen. Redis koordiniert die Jobverteilung \u00fcber die Worker. Alle Prozesse teilen denselben Encryption-Key, um Zugangsdaten aus der Datenbank zu entschl\u00fcsseln.<\/a><\/p>\n\n\n\n
Das Ergebnis: Dutzende oder hunderte Workflows laufen gleichzeitig, statt hinter einem einzelnen Ausf\u00fchrungsthread Schlange zu stehen.<\/p>\n\n\n\n
Wann setzt du den n8n Queue-Modus ein?<\/h3>\n\n\n\n
Kurz gesagt: Wenn du an die Grenzen einer Einzelinstanz st\u00f6\u00dft. Typische Anzeichen sind langsame Workflow-Ausf\u00fchrungen, Webhook-Timeouts, UI-Verz\u00f6gerungen beim \u00d6ffnen von Workflows und sich stauende Ausf\u00fchrungsqueues zu Spitzenzeiten. Wenn du mehr als 100 Ausf\u00fchrungen pro Stunde verarbeitest oder lang laufende Workflows andere Aufgaben blockieren, ergibt der Queue-Modus Sinn.<\/p>\n\n\n\n
F\u00fcr den pers\u00f6nlichen Gebrauch oder leichte Automatisierung mit wenigen t\u00e4glichen L\u00e4ufen ist das \u00fcberdimensioniert. Der Standardmodus reicht v\u00f6llig, wenn Ausf\u00fchrungen selten sind und Workflows schnell durchlaufen. Der Queue-Modus bringt Komplexit\u00e4t mit: Redis, PostgreSQL, mehrere Container, synchronisierte Umgebungsvariablen. Das zahlt sich nur unter realer Last aus.\u200b<\/p>\n\n\n\n
Produktionsumgebungen mit gesch\u00e4ftskritischer Automatisierung brauchen den Queue-Modus f\u00fcr Zuverl\u00e4ssigkeit. Selbst wenn die aktuelle Last es nicht erfordert, bietet die Architektur Redundanz. Ein Worker st\u00fcrzt ab, die anderen arbeiten weiter. Datenbankwartung l\u00e4uft, Worker verlieren kurz die Verbindung und setzen dann ohne Datenverlust fort, weil der Queue-Status in Redis und PostgreSQL persistiert wird.<\/a>\u200b<\/p>\n\n\n\n
Was ist die beste Serverkonfiguration f\u00fcr n8n?<\/h3>\n\n\n\n
Die beste Serverkonfiguration f\u00fcr n8n im Queue-Modus startet bei 2 CPU-Kernen und 4 GB RAM f\u00fcr kleine Deployments. Damit l\u00e4uft der Hauptprozess, PostgreSQL, Redis und ein bis zwei Worker f\u00fcr leichte Workflows. Du brauchst etwa 1 GB f\u00fcr Redis und PostgreSQL zusammen, 500 MB f\u00fcr den n8n-Hauptprozess und 200-500 MB pro Worker, je nach Workflow-Komplexit\u00e4t.<\/a>\u200b<\/p>\n\n\n\n
Produktionssetups mit ernsthafter Last brauchen mindestens 4-8 CPU-Kerne und 8-16 GB RAM. Das erm\u00f6glicht mehrere Worker gleichzeitig, ohne Ressourcenkonflikte. PostgreSQL profitiert deutlich von dedizierten CPU-Kernen und ausreichend RAM f\u00fcr Caching. Redis ist leichtgewichtig, profitiert aber von schnellem Storage f\u00fcr Queue-Persistenz.<\/a>\u200b<\/p>\n\n\n\n
Erst \u00fcberwachen, dann anhand der tats\u00e4chlichen Nutzung skalieren statt zu raten. F\u00fchre echte Workflows unter der erwarteten Last aus und beobachte CPU, RAM und Disk-I\/O mit  und Monitoring-Tools. Wenn Worker die CPU auslasten: Kerne erg\u00e4nzen oder Workflows optimieren. Wenn der RAM voll wird: Worker-Anzahl reduzieren oder mehr Speicher einbauen. Storage ist wichtig, denn die PostgreSQL-Ausf\u00fchrungshistorie w\u00e4chst \u00fcber die Zeit. Plane Datenbankwachstum in deine Sch\u00e4tzung der Festplattenkapazit\u00e4t ein.<\/p>\n","protected":false},"excerpt":{"rendered":"
Der n8n Queue-Modus verwandelt ein Einzelinstanz-Setup zur Workflow-Automatisierung in ein verteiltes System, das hunderte gleichzeitige Ausf\u00fchrungen verarbeiten kann. Diese Anleitung f\u00fchrt dich Schritt f\u00fcr Schritt durch die komplette Einrichtung mit Docker Compose auf einem VPS. Du erf\u00e4hrst, wie du Redis als Job-Queue aufsetzt, PostgreSQL f\u00fcr den gemeinsamen State bereitstellst, Umgebungsvariablen \u00fcber alle Container hinweg konfigurierst, den n8n-Hauptprozess startest und Worker-Prozesse skalierst, die Workflows parallel abarbeiten. Du erf\u00e4hrst, wann der Queue-Modus sinnvoll ist (100+ Ausf\u00fchrungen pro Stunde, lang laufende Workflows, die andere Aufgaben blockieren), welche Serverressourcen du brauchst (mindestens 2 CPU-Kerne und 4 GB RAM) und wie du Worker anhand der tats\u00e4chlichen Last \u00fcberwachst und skalierst. Das Setup erfordert Docker-Kenntnisse und Erfahrung mit der Kommandozeile, liefert aber eine produktionsreife n8n-Skalierbarkeit, die mit deinen Anforderungen an die Workflow-Automatisierung mitw\u00e4chst.<\/p>\n","protected":false},"author":63,"featured_media":28011,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1399],"tags":[],"ppma_author":[1492],"class_list":["post-29285","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials"],"uagb_featured_image_src":{"full":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE.webp",1200,630,false],"thumbnail":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE-150x150.webp",150,150,true],"medium":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE-600x315.webp",600,315,true],"medium_large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE-768x403.webp",768,403,true],"large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE.webp",1200,630,false],"1536x1536":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE.webp",1200,630,false],"2048x2048":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_DE.webp",1200,630,false]},"uagb_author_info":{"display_name":"Christopher Carter","author_link":"https:\/\/contabo.com\/blog\/de\/author\/christophercarter\/"},"uagb_comment_info":0,"uagb_excerpt":"Der n8n Queue-Modus verwandelt ein Einzelinstanz-Setup zur Workflow-Automatisierung in ein verteiltes System, das hunderte gleichzeitige Ausf\u00fchrungen verarbeiten kann. Diese Anleitung f\u00fchrt dich Schritt f\u00fcr Schritt durch die komplette Einrichtung mit Docker Compose auf einem VPS. Du erf\u00e4hrst, wie du Redis als Job-Queue aufsetzt, PostgreSQL f\u00fcr den gemeinsamen State bereitstellst, Umgebungsvariablen \u00fcber alle Container hinweg konfigurierst,…","authors":[{"term_id":1492,"user_id":63,"is_guest":0,"slug":"christophercarter","display_name":"Christopher Carter","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/63db81672a5ce4c1e8ee39753d00251d561b5b3a9967febf1c4f662024cef00f?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/posts\/29285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=29285"}],"version-history":[{"count":5,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/posts\/29285\/revisions"}],"predecessor-version":[{"id":29301,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/posts\/29285\/revisions\/29301"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/media\/28011"}],"wp:attachment":[{"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=29285"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=29285"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=29285"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/contabo.com\/blog\/de\/wp-json\/wp\/v2\/ppma_author?post=29285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}