Eine einzelne n8n-Instanz hat etwa sechs Monate lang einwandfrei funktioniert. Dann erreichten wir über 200 Workflow-Ausführungen pro Tag und alles wurde quälend langsam: Webhooks liefen in Timeouts, die UI hing beim Öffnen des Editors, neue Workflows warteten 30 Sekunden, bis sie überhaupt starten konnten, weil irgendein CSV-Verarbeitungsjob den einzigen verfügbaren Thread blockierte. Die Skalierbarkeit von n8n war schlicht nicht gegeben.
Der n8n Queue-Modus löst das Problem, indem er die Aufgaben in deinem n8n-Docker-Setup aufteilt. Ein n8n-Prozess kümmert sich um die Web-Oberfläche und lauscht auf eingehende Trigger wie Webhooks, Zeitpläne und manuelle Ausführungen. Separate Worker-Prozesse - ob drei oder zehn - holen sich Jobs aus einer Redis-Queue und führen die Workflows tatsächlich aus. So können jetzt zehn Workflows gleichzeitig laufen, statt nacheinander in der Warteschlange zu stehen. Das ist echte Workflow-Automatisierung.
Du konfigurierst das Ganze mit Docker Compose, Redis als Job-Queue und PostgreSQL, weil SQLite mit mehreren Prozessen nicht klarkommt (genauer gesagt: überhaupt nicht). Umgebungsvariablen müssen in allen Containern exakt übereinstimmen, 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ührungen wegsteckt, ohne ins Stocken zu geraten.
Bereit loszulegen?
So funktioniert der n8n Queue-Modus
Standard-n8n packt alles in einen einzigen Prozess. Die Weboberfläche läuft dort. Webhook-Listener laufen dort. Workflow-Ausführungen laufen dort. Alle kämpfen 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 öffnen: 15 Sekunden Ladekreisel. Ein Webhook von Stripe trifft deinen Endpunkt und du bekommst einen Timeout, weil der Prozess ausgelastet ist.
Der Queue-Modus trennt die Zuständigkeiten in der n8n-Queue-Modus-Architektur. Der Hauptprozess bedient die Web-UI und lauscht auf Trigger. Wenn ein Workflow ausgeführt 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ächsten Aufgabe.
Worker überwachen den Redis-Message-Broker permanent. Sie laufen in einer engen Schleife: Queue prüfen, Job holen falls vorhanden, ausführen, Ergebnisse in PostgreSQL schreiben, Queue erneut prüfen. 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ührt.
Alles verbindet sich mit derselben PostgreSQL-Datenbank. Dort liegen Zugangsdaten, Workflow-Definitionen und die Ausführungshistorie. Dieser gemeinsame State bedeutet: Jeder Worker kann jeden Workflow ausführen. Es gibt kein Festpinnen bestimmter Jobs auf bestimmte Maschinen, was für die Workflow-Orchestrierung ein Albtraum wäre. Die Datenbank trackt den Ausführungsstatus in Echtzeit. Der Hauptprozess zeigt dir Fortschrittsupdates in der UI, obwohl die Ausführung auf einem völlig anderen Container stattfindet.
Die parallele Ausführung 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ührst du am besten auf dedizierten Workern mit mehr RAM aus, während reine API-Workflows auf kleineren Workern laufen. Das hängt aber von deinen Workflows ab.
Voraussetzungen
Du brauchst ein n8n VPS oder einen Dedicated Server mit mindestens 2 CPU-Kernen und 4 GB RAM. Für 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.
Docker und Docker-Compose müssen installiert und funktionsfähig 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ürzlich geändert.
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ügt weitere Komplexität hinzu. Wenn du neu bist, fang einfach an: Such nach "n8n" in unserem Blog, dort findest du viele hilfreiche Artikel für den Einstieg.
PostgreSQL-Kenntnisse sind hilfreich, aber nicht zwingend nötig. Du bringst ein PostgreSQL-Docker-Setup zum Laufen, aber die eigentlichen Datenbankoperationen passieren automatisch, sobald die Verbindungsstrings stimmen. SQLite funktioniert mit dem Queue-Modus überhaupt nicht. Mehrere Prozesse, die gleichzeitig auf dieselbe SQLite-Datei zugreifen, führen zu Datenkorruption. PostgreSQL ist Pflicht, kein Vorschlag.
Sicherheit auf der Kommandozeile ist essenziell. Du wirst docker-compose.yml-Dateien bearbeiten, Umgebungsvariablen setzen (jede Menge davon) und Docker-Befehle ausführen, um Worker hoch- und herunterzufahren. Außerdem musst du Logs prüfen, wenn Container nicht starten. Falls dich das Navigieren durch Verzeichnisse im Terminal und das Lesen von Fehlermeldungen nervös macht, arbeite dich da erst einmal ein.
n8n Queue-Modus konfigurieren
Die n8n-Konfiguration für 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 übereinstimmen müssen. Dann PostgreSQL, dann der n8n-Hauptprozess und zum Schluss die Worker. Wenn du Schritte überspringst, bekommst du Abhängigkeitsfehler: Container stürzen ab, weil sie sich mit Diensten verbinden wollen, die noch nicht existieren. Wenn du später Kapazität brauchst, nutzt du Docker Compose-Scale-Befehle, um weitere Worker hochzufahren. Aber das initiale Setup muss in genau dieser Reihenfolge passieren.
Redis-Container vorbereiten
Redis ist das Fundament für die Jobverteilung von n8n. Worker holen Jobs aus der Redis-Queue. Der Hauptprozess schiebt neue Ausführungen in diese Queues. Ohne laufendes Redis funktioniert der Queue-Modus schlicht nicht.
Erstelle ein Verzeichnis für dein Setup und füge Redis zu deiner Docker-Compose-Konfiguration hinzu. Hier die grundlegende Service-Definition:
redis:
image: redis:7-alpine
container_name: n8n_redis
ports:
- "6379:6379"
volumes:
- redis_data:/data
command: redis-server --appendonly yes
restart: unless-stopped
Das --appendonly yes Flag aktiviert die Redis-Persistenz. Ohne dieses Flag bedeutet ein Neustart der Redis-Container-Instanz, dass alle Jobs in der Queue verloren gehen. Endgültig weg. Der Volume-Mount speichert diese persistenten Daten auf der Festplatte.
Für die n8n-Redis-Verbindung verwenden Worker und Hauptprozess als Hostnamen redis , da sie alle im selben Docker-Netzwerk laufen. Port 6379 ist der Redis-Standard. Du kannst Passwort-Authentifizierung mit im Befehl --requirepass yourpassword hinzufügen, wobei das für Container in einem privaten Docker-Netzwerk optional ist.
Starte nur Redis: docker compose up -d redis. Prüfe die Logs sofort: docker logs n8n_redis. Du solltest "Ready to accept connections" ohne Fehler sehen. Teste es von deinem Host mit redis-cli ping, bevor du weitermachst. Erkenne Verbindungsprobleme lieber jetzt als nach der Konfiguration von sechs weiteren Containern.
Umgebungsvariablen konfigurieren
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ädigen aber Daten, weil der Encryption-Key nicht übereinstimmt.
Hier die kritischen n8n-Umgebungsvariablen für das Setup:
EXECUTIONS_MODE=queue schaltet n8n vom Standard- in den Queue-Modus. Setze das sowohl beim Hauptprozess als auch bei allen Workern. Ohne diese Variable läuft n8n im normalen Einzelprozessmodus und ignoriert Redis komplett.
N8N_ENCRYPTION_KEY muss beim Hauptprozess und jedem einzelnen Worker identisch sein. Damit werden Zugangsdaten in der Datenbank verschlüsselt. Worker mit einem anderen Key können Zugangsdaten nicht entschlüsseln. 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älligen String, verwende ihn überall und ändere ihn nach dem Deployment nie mehr, es sei denn, du willst alle verschlüsselten Daten manuell migrieren.
QUEUE_BULL_REDIS_HOST und QUEUE_BULL_REDIS_PORT zeigen auf Redis. Verwende den Docker-Servicenamen als Host, da Container über Dockers internes Netzwerk kommunizieren. Der Port ist , sofern du ihn nicht geändert hast.
DB_TYPE=postgresdb schaltet von SQLite auf PostgreSQL um. Dann ergänze: DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER und DB_POSTGRESDB_PASSWORD. Alle Prozesse verbinden sich mit derselben Datenbank und denselben Zugangsdaten.
Lege diese in eine .env-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.
Hauptprozess von n8n bereitstellen
Der n8n-Hauptprozess verwaltet die Web-UI, stellt die API bereit und reiht Workflow-Ausführungen in die Queue ein, führt sie aber nicht selbst aus. Nutzer greifen über Port 5678 darauf zu. Das ist der Kern deines n8n-Deployments.
Hier die n8n-Docker-Service-Definition in der docker-compose.yml für die n8n-Installation:
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
Das depends_on stellt sicher, dass PostgreSQL und Redis starten, bevor n8n sich verbinden will. Volume-Mounts persistieren Workflow-Dateien und Custom Nodes außerhalb des Containers.
Starte es: docker compose up -d n8n. Prüfe die Logs direkt: docker logs -f n8n_main. 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ängigkeiten nicht erreicht, funktioniert nichts korrekt.
Rufe die Web-UI auf unter http://your-vps-ip:5678. Erstelle einen Test-Workflow, führe ihn aber noch nicht aus. Worker laufen noch nicht, Ausführungen würden also ewig in der Queue hängen.
PostgreSQL-Datenbank bereitstellen
PostgreSQL speichert Workflows, Zugangsdaten, Ausführungshistorie 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ädigen.
Füge den n8n-PostgreSQL-Service zur docker-compose.yml hinzu:
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
Die Datenbank-Zugangsdaten hier müssen mit denen in deiner n8n-Hauptkonfiguration übereinstimmen. Der PostgreSQL-Container persistiert Daten in einem Docker-Volume, sodass Inhalte Neustarts überstehen.
Beim PostgreSQL-Docker-Setup initialisiert sich die Datenbank beim ersten Start automatisch. Du musst keine SQL-Skripte manuell ausführen. n8n übernimmt die Schema-Erstellung beim ersten Verbindungsaufbau. Starte PostgreSQL: docker compose up -d postgres. Prüfe die Logs: docker logs n8n_postgres. Achte auf "database system is ready to accept connections."
Wenn du den n8n-Hauptprozess bereits gestartet hast, verbindet er sich automatisch mit PostgreSQL und initialisiert die Tabellen. Prüfe die n8n-Logs erneut auf erfolgreiche Datenbankmigrationen.
n8n Worker-Prozesse starten
Worker sind n8n-Instanzen, die im Worker-Modus laufen. Keine Weboberfläche. Keine offenen Ports. Sie holen Jobs aus Redis, führen Workflows aus und schreiben Ergebnisse in PostgreSQL. Das war's.
Hier die n8n-Worker-Service-Definition, ähnlich wie die Hauptdefinition, aber mit den entscheidenden Unterschieden:
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
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 übereinstimmen. Worker entschlüsseln mit diesem Key die Zugangsdaten aus der Datenbank. Bei Abweichung laufen Workflows zwar, können aber nicht auf Zugangsdaten zugreifen. Das erzeugt stille Fehler, die extrem schwer zu debuggen sind.
Starte zunächst einen Worker: docker compose up -d n8n-worker. Prüfe die Logs: docker logs n8n-worker. Du solltest "n8n worker is now ready" sowie Verbindungsmeldungen für Redis und PostgreSQL sehen. n8n-Worker protokollieren, wenn sie Jobs aufnehmen. Anfangs siehst du also nur Initialisierungsmeldungen.
Skaliere die Worker mit Docker-Compose: docker compose up -d --scale n8n-worker=3. Das erstellt drei Worker-Container aus derselben Service-Definition. Jeder verbindet sich mit derselben Redis-Queue und PostgreSQL-Datenbank und holt Jobs unabhängig.
Wie viele Worker du brauchst, hängt von deiner tatsächlichen Last ab, nicht von der Theorie. Starte mit einem oder zwei. Beobachte Queue-Tiefe und Ausführungszeiten unter realer Last. Skaliere hoch, wenn sich Jobs stauen. Jeder Worker verbraucht 200-500 MB RAM. Zehn Worker auf einem 4-GB-VPS führen zu OOM-Kills.
n8n Queue-Setup testen
Erstelle einen Workflow mit einem Wait-Node, der auf 10 Sekunden eingestellt ist. Füge einfache HTTP-Request-Nodes davor und danach ein, damit du den Ausführungsfluss beobachten kannst. Speichern und aktivieren.
Löse den Workflow manuell dreimal schnell hintereinander über die n8n-Weboberfläche aus. Im Standardmodus würde das nacheinander ablaufen: insgesamt 30+ Sekunden. Mit laufenden Workern werden sie parallel ausgeführt.
Prüfe die Ausführungsliste 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 an: das zeigt dir, welcher Worker welche Ausführung übernommen hat. Du siehst Meldungen wie "Job picked up" mit Ausführungs-IDs.
Das n8n-Automatisierungs-Monitoring in der Web-UI zeigt die Ausführungszeiten. Vergleiche mit dem Standardmodus. Der Queue-Modus hat oft etwas längere Ausführungszeiten pro Einzellauf wegen des Queuing-Overheads. Der Gesamtdurchsatz steigt aber massiv, weil Workflows parallel laufen.
n8n Worker überwachen und skalieren
Beobachte Ausführungszeiten und Queue-Tiefe im realen Betrieb. Wenn die Redis-Queue zu Spitzenzeiten konstant wächst, kommen Workflows schneller rein, als die Worker sie abarbeiten können. Hochskalieren.
Worker im laufenden Betrieb hinzufügen: docker compose up -d --scale n8n-worker=5. Neue Worker starten sofort und beginnen, Jobs aus der Redis-Queue abzuholen. Keine Workflow-Unterbrechung. Keine Konfigurationsänderungen. Einfach mehr Kapazität. Hier zeigt sich die Skalierbarkeit von n8n wirklich.
In ruhigen Zeiten herunterskalieren: docker compose up -d --scale n8n-worker=2. Docker stoppt überzählige Worker sanft: Sie beenden laufende Jobs, bevor sie herunterfahren. Keine abgebrochenen Ausführungen.
Überwache die Ressourcennutzung pro Worker mit docker stats. Das zeigt CPU und RAM für jeden Worker-Container. Wenn Worker dauerhaft die CPU auslasten oder ans Speicherlimit stoßen: entweder Workflows optimieren oder einen größeren VPS nehmen. n8n-Performance zu verstehen bedeutet, diese Metriken über die Zeit zu verfolgen.
Aktiviere Metriken für tieferes Monitoring. Setze N8N_METRICS=true und N8N_METRICS_INCLUDE_API_ENDPOINTS=true in den Umgebungsvariablen. Das stellt Prometheus-kompatible Metriken am /metrics-Endpunkt bereit. Dort kannst du Queue-Tiefe, Ausführungszähler und Worker-Performance über die Zeit verfolgen.
Fazit
Der Queue-Modus macht aus n8n ein System, das produktionsreife Workloads bewältigen kann. Die Trennung von Web-UI, Job-Queuing und verteilter Ausführung schafft echte n8n-Skalierbarkeit, die mit deinen Anforderungen wächst, statt im ungünstigsten Moment an harte Grenzen zu stoßen.
Das Setup ist nicht trivial. Du hast Docker Compose über mehrere Services hinweg orchestriert, Umgebungsvariablen synchronisiert, die perfekt übereinstimmen müssen, PostgreSQL- und Redis-Infrastruktur bereitgestellt und Worker-Prozesse gestartet. Aber jetzt hast du ein Workflow-Automatisierungssystem, das hunderte gleichzeitige Ausführungen verarbeitet, ohne einzubrechen.
Was als Nächstes kommt, ist genauso wichtig wie das initiale Setup. Richte automatische PostgreSQL-Backups ein: Workflows, Zugangsdaten und Ausführungshistorie liegen dort. Überwache die Ressourcennutzung der Worker und skaliere proaktiv anhand von Traffic-Mustern. Bringe Log-Aggregation zum Laufen, damit du Probleme über verteilte Worker hinweg analysieren kannst. Sichere Redis ab, wenn dein VPS in Netzwerken hängt, die du nicht kontrollierst.
VPS-Hosting bedeutet: Du triffst die Skalierungsentscheidungen. Cloud-Dienste mit gemanagtem n8n rechnen pro Ausführung ab oder limitieren Workflows. Den Queue-Modus auf eigener Infrastruktur zu betreiben bedeutet, nach tatsächlichen Ressourcenkosten zu skalieren statt nach Abo-Stufen. Der Kompromiss: Du trägst die Komplexität. Dafür hast du die volle Kontrolle.
n8n Queue-Modus FAQ
Was ist der n8n Queue-Modus?
Der n8n Queue-Modus trennt die Weboberfläche von der Workflow-Ausführung: über 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 überwachen diese Queues permanent, holen Jobs ab und führen Workflows parallel aus.
Das ermöglicht horizontale Skalierung: Du fügst mehr Worker hinzu, um höhere Lasten zu bewältigen, ohne am Workflow-Code etwas ändern zu müssen. Voraussetzung ist PostgreSQL statt SQLite, da mehrere Prozesse gleichzeitigen Datenbankzugriff brauchen. Redis koordiniert die Jobverteilung über die Worker. Alle Prozesse teilen denselben Encryption-Key, um Zugangsdaten aus der Datenbank zu entschlüsseln.
Das Ergebnis: Dutzende oder hunderte Workflows laufen gleichzeitig, statt hinter einem einzelnen Ausführungsthread Schlange zu stehen.
Wann setzt du den n8n Queue-Modus ein?
Kurz gesagt: Wenn du an die Grenzen einer Einzelinstanz stößt. Typische Anzeichen sind langsame Workflow-Ausführungen, Webhook-Timeouts, UI-Verzögerungen beim Öffnen von Workflows und sich stauende Ausführungsqueues zu Spitzenzeiten. Wenn du mehr als 100 Ausführungen pro Stunde verarbeitest oder lang laufende Workflows andere Aufgaben blockieren, ergibt der Queue-Modus Sinn.
Für den persönlichen Gebrauch oder leichte Automatisierung mit wenigen täglichen Läufen ist das überdimensioniert. Der Standardmodus reicht völlig, wenn Ausführungen selten sind und Workflows schnell durchlaufen. Der Queue-Modus bringt Komplexität mit: Redis, PostgreSQL, mehrere Container, synchronisierte Umgebungsvariablen. Das zahlt sich nur unter realer Last aus.
Produktionsumgebungen mit geschäftskritischer Automatisierung brauchen den Queue-Modus für Zuverlässigkeit. Selbst wenn die aktuelle Last es nicht erfordert, bietet die Architektur Redundanz. Ein Worker stürzt ab, die anderen arbeiten weiter. Datenbankwartung läuft, Worker verlieren kurz die Verbindung und setzen dann ohne Datenverlust fort, weil der Queue-Status in Redis und PostgreSQL persistiert wird.
Was ist die beste Serverkonfiguration für n8n?
Die beste Serverkonfiguration für n8n im Queue-Modus startet bei 2 CPU-Kernen und 4 GB RAM für kleine Deployments. Damit läuft der Hauptprozess, PostgreSQL, Redis und ein bis zwei Worker für leichte Workflows. Du brauchst etwa 1 GB für Redis und PostgreSQL zusammen, 500 MB für den n8n-Hauptprozess und 200-500 MB pro Worker, je nach Workflow-Komplexität.
Produktionssetups mit ernsthafter Last brauchen mindestens 4-8 CPU-Kerne und 8-16 GB RAM. Das ermöglicht mehrere Worker gleichzeitig, ohne Ressourcenkonflikte. PostgreSQL profitiert deutlich von dedizierten CPU-Kernen und ausreichend RAM für Caching. Redis ist leichtgewichtig, profitiert aber von schnellem Storage für Queue-Persistenz.
Erst überwachen, dann anhand der tatsächlichen Nutzung skalieren statt zu raten. Führe 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änzen oder Workflows optimieren. Wenn der RAM voll wird: Worker-Anzahl reduzieren oder mehr Speicher einbauen. Storage ist wichtig, denn die PostgreSQL-Ausführungshistorie wächst über die Zeit. Plane Datenbankwachstum in deine Schätzung der Festplattenkapazität ein.
