n8n auf Kubernetes: Helm-Chart, Queue Mode und wann sich das lohnt
Wann lohnt sich n8n auf Kubernetes statt Docker Compose? Offizieller Helm-Chart, Queue Mode und Redis erklärt.

n8n lässt sich mit Docker Compose auf einem einzelnen Server meist in wenigen Minuten betreiben, und für die überwiegende Mehrheit der kleinen und mittleren Unternehmen reicht dieser Ansatz vollkommen aus. Kubernetes mit dem offiziellen Helm-Chart wird erst dann relevant, wenn Workflows auf mehrere Knoten verteilt, automatisch skaliert oder bei Ausfällen selbstständig neu gestartet werden müssen, etwa bei sehr hohem Webhook-Aufkommen oder wenn im Unternehmen bereits eine Kubernetes-Plattform für andere Anwendungen läuft. Der offizielle Chart wird von n8n selbst im Repository n8n-io/n8n-hosting gepflegt und über eine OCI-Registry veröffentlicht. Laut dem Chart-README unterstützt er zwei Betriebsarten: einen Standalone-Modus mit SQLite ohne externe Abhängigkeiten und einen Queue-Modus, der PostgreSQL und Redis voraussetzt und Arbeitslast auf separate Worker-Pods verteilt. Stand: August 2026.
Was deckt der offizielle n8n Helm-Chart konkret ab?
Der Chart installiert n8n über den Befehl helm install mit der OCI-Referenz oci://ghcr.io/n8n-io/n8n-helm-chart/n8n und einer eigenen values.yaml-Datei für die Konfiguration. Vorausgesetzt werden laut Dokumentation Helm ab Version 3.12 und ein Kubernetes-Cluster ab Version 1.25. Im Queue-Modus, der als Standardeinstellung des Charts vorgesehen ist, unterscheidet die Architektur drei Pod-Typen: Main-Pods für Oberfläche, API und nicht-produktive Webhooks, Worker-Pods, die Workflows aus der Redis-Warteschlange abarbeiten und typischerweise in mehrfacher Ausführung laufen, sowie optionale dedizierte Webhook-Pods für produktiven Webhook-Traffic. Der Chart bringt außerdem Unterstützung für horizontale Autoskalierung über HPA und KEDA mit, sowohl für Worker als auch für Webhook-Prozessoren.
Wie hängen Queue Mode und Redis zusammen?
Queue Mode ist die Voraussetzung dafür, dass mehrere n8n-Worker parallel Workflows abarbeiten können, und dafür braucht n8n Redis als Warteschlange. Ohne Queue Mode verarbeitet eine einzelne n8n-Instanz Workflows sequenziell im selben Prozess, der auch die Oberfläche ausliefert, was bei wenigen Workflows unproblematisch ist, bei hoher Last aber zum Engpass wird. Mit aktiviertem Queue Mode legt n8n auszuführende Workflows in eine Redis-Warteschlange, aus der die Worker-Pods sie abholen und unabhängig voneinander abarbeiten. Laut Angaben im Hosting-Repository wird für den produktiven Betrieb Redis ab Version 7 empfohlen, Version 6 ist mindestens erforderlich, sobald ein Redis-Benutzername konfiguriert wird. PostgreSQL kommt in dieser Konstellation als primäre Datenbank hinzu, SQLite ist für den Queue-Modus nicht vorgesehen.
Welche Voraussetzungen und welchen Aufwand sollten Sie realistisch einplanen?
Wer den Helm-Chart produktiv einsetzt, braucht neben einem laufenden Kubernetes-Cluster auch Erfahrung im Betrieb von PostgreSQL, Redis und Ingress-Konfiguration, denn der Chart übernimmt die Orchestrierung der n8n-Komponenten, nicht aber den Betrieb der externen Abhängigkeiten. Mehrere Main-Instanzen für Hochverfügbarkeit setzen laut Chart-Dokumentation zusätzlich eine Enterprise-Lizenz sowie sitzungsbasierte Lastverteilung auf Ebene des Load Balancers voraus. Für die Isolierung von Code-Ausführung bietet der Chart sogenannte Task Runner als separate Sidecars an, die eine eigene Authentifizierung benötigen. In der Praxis heißt das: Der betriebliche Mehraufwand gegenüber einer Docker-Compose-Installation ist spürbar, von Cluster-Wartung über Monitoring bis zu Backup-Strategien für Redis und PostgreSQL. Für ein KMU mit einer Handvoll Automatisierungen, die auch mal ein paar Sekunden länger in der Warteschlange stehen dürfen, ist das in aller Regel Overkill. Sinn ergibt der Aufwand vor allem, wenn IT-Teams bereits Kubernetes-Kompetenz mitbringen oder n8n Teil einer größeren, ohnehin auf Kubernetes betriebenen Plattform wird. Wer unsicher ist, welches Hosting-Modell zur eigenen Automatisierungslast passt, sollte diese Frage vor der Einführung klären, etwa im Rahmen einer n8n-Beratung, statt sich nachträglich mit einer überdimensionierten Infrastruktur herumzuschlagen. Auch ein Blick auf den ROI-Rechner hilft einzuordnen, ob der zusätzliche Betriebsaufwand einer Kubernetes-Lösung im Verhältnis zum erwarteten Automatisierungsnutzen steht.
Haeufige Fragen zu n8n auf Kubernetes
Brauche ich für n8n unbedingt Kubernetes?
Nein, für die meisten KMU reicht eine Docker-Compose-Installation auf einem einzelnen Server völlig aus. Kubernetes wird erst relevant, wenn Skalierung über mehrere Knoten, automatische Ausfallsicherheit oder eine bereits bestehende Kubernetes-Plattform im Unternehmen im Spiel sind. Für den Einstieg oder kleinere Automatisierungsvorhaben ist der Betriebsaufwand eines Clusters meist nicht gerechtfertigt.
Muss ich für den Helm-Chart zwingend Queue Mode nutzen?
Nein, der offizielle Chart unterstützt auch einen Standalone-Modus mit SQLite und ohne externe Abhängigkeiten wie Redis oder PostgreSQL. Queue Mode lohnt sich erst, wenn mehrere Worker parallel Workflows abarbeiten sollen, weil dann eine Redis-Warteschlange die Verteilung übernimmt. Für einzelne, überschaubare Workflow-Mengen ist der Standalone-Modus deutlich einfacher zu betreiben.
Welche Kubernetes-Version brauche ich für den offiziellen Chart?
Laut dem README des offiziellen Charts werden mindestens Helm 3.12 und Kubernetes 1.25 vorausgesetzt. Ältere Cluster-Versionen werden vom Chart nicht offiziell unterstützt, ein Upgrade des Clusters sollte also vor der Installation geprüft werden. Diese Mindestanforderungen können sich mit künftigen Chart-Versionen ändern.
Ist der offizielle Chart für Produktivbetrieb geeignet oder nur für Tests?
Der Chart ist für den Produktivbetrieb ausgelegt und bringt Funktionen wie horizontale Autoskalierung über HPA und KEDA sowie dedizierte Webhook-Pods für produktiven Traffic mit. Voraussetzung ist allerdings, dass die externen Abhängigkeiten wie PostgreSQL und Redis selbst produktionsreif betrieben werden, der Chart übernimmt nur die Orchestrierung von n8n selbst. Wer diese Betriebserfahrung nicht im Haus hat, sollte den Aufwand vor der Entscheidung realistisch einschätzen.
NordFlux UG (haftungsbeschränkt)
NordFlux baut Organisationen digitale Mitarbeiter: Automatisierungen und KI-Agenten, die wiederkehrende Arbeit abnehmen. Sie behalten die Kontrolle.
n8n auf Kubernetes: lohnt sich der Aufwand für Ihren Betrieb?
Helm-Chart, Queue Mode und Redis sind schnell aufgesetzt, aber der Dauerbetrieb auf Kubernetes verlangt Know-how, das im Tagesgeschäft selten vorhanden ist. NordFlux übernimmt Aufbau und Betrieb Ihrer n8n-Infrastruktur, von der einfachen VM bis zum skalierten Kubernetes-Setup, je nachdem, was Ihr Workload wirklich braucht.
- Ehrliche Einschätzung, ob Kubernetes für Ihre Workload überhaupt nötig ist
- Queue Mode und Redis-Setup mit getesteter Skalierung statt Trial-and-Error
- Laufender Betrieb mit Monitoring und Updates statt Wochenendarbeit