n8n-Server-Anforderungen

Wie viel Maschine eine selbstgehostete n8n-Instanz wirklich braucht, was die Datenbank dazukommen lässt und ab wann eine Instanz nicht mehr reicht. Die meisten Dimensionierungsempfehlungen, die du online findest, sind für den Queue-Modus geschrieben, den die meisten nie brauchen, und lesen sich daher wie eine viel größere Anforderung, als sie ist.

Die kurze Antwort

Eine einzelne n8n-Instanz mit normalen Workflows ist keine anspruchsvolle Software. Zwei vCPU und 2 GB RAM bewältigen komfortabel eine echte Last aus geplanten Jobs, Webhooks und API-Aufrufen, weil n8n den Großteil seiner Zeit auf die Dienste anderer wartet, statt zu rechnen. Der n8n-Hauptprozess selbst liegt im Ruhezustand bei etwa 300 MB.

Was die Zahl wirklich nach oben treibt, ist nicht, wie viele Workflows du definiert hast. Es ist, wie viele Daten eine einzelne Ausführung gleichzeitig im Speicher hält und wie viele Ausführungen parallel laufen.

Was in n8n Speicher verbraucht

n8n gibt Daten zwischen Nodes als Items weiter, die für die Dauer der Ausführung im Speicher gehalten werden. Das hat eine wichtige Folge für die Dimensionierung: Ein Workflow, der zehntausend Zeilen abruft und durch fünf Nodes mappt, ist ein weit schwererer Mieter als hundert Workflows, die jeweils eine Webhook-Payload bewegen.

• Payload-Größe pro Ausführung. Große HTTP-Antworten, Tabellenimporte und Binärdateien sind die übliche Ursache dafür, dass eine Instanz, die lief, plötzlich nicht mehr läuft.
• Parallelität. Zehn gleichzeitig laufende Ausführungen halten jeweils ihren eigenen Arbeitsspeicher. Ein Zeitplan, der mehrere Workflows in derselben Minute auslöst, ist eine Spitze, die du nicht eingeplant hast.
• Ausführungsverlauf. Gespeicherte Ausführungsdaten sammeln sich in der Datenbank an. Das ist eine Frage von Speicherplatz und Datenbank, nicht von RAM, aber es wächst monatelang unbemerkt und wird dann relevant.

Die praktische Folge: Wenn du große Payloads verarbeitest, teile sie auf. Einen großen Datensatz in Chunks zu stapeln, bringt mehr Stabilität als beliebig viel zusätzlicher RAM, weil es die Spitze verändert, statt die Obergrenze anzuheben.

Die Datenbank ist eine Anforderung, keine Optimierung

n8n nutzt standardmäßig SQLite, was für einen Test in Ordnung und in der Produktion eine schlechte Idee ist. Es kommt schlecht mit gleichzeitigen Ausführungen zurecht und lässt sich nur umständlich zuverlässig sichern und wiederherstellen. PostgreSQL ist die Antwort für die Produktion und ressourcentechnisch nicht umsonst: Plane grob 500 MB bis 1 GB dafür ein, wachsend mit deinem Ausführungsverlauf.

Diese Zahl packen die meisten Dimensionierungsanleitungen stillschweigend in dieselbe Kiste wie n8n selbst. Auf einem selbst betriebenen VPS geht sie vom selben RAM ab wie deine Workflows, zusammen mit der Container-Laufzeit, einem Reverse Proxy und dem Betriebssystem. In unseren Tarifen ist der PostgreSQL-Cluster eine separate hochverfügbare Komponente mit eigenem Speicher, sodass der RAM im Tarifnamen RAM für n8n ist.

CPU: meist nicht der Engpass

n8n besteht überwiegend aus Warten. Eine Ausführung verbringt ihre Zeit mit Netzwerk-Roundtrips zu APIs und nicht mit Berechnung, daher reichen zwei Kerne weit. Die Ausnahmen sind real, aber konkret: aufwendige Datentransformation in Code-Nodes, das Parsen großer JSON-Dateien und KI-Workflows, die nennenswert lokal rechnen, statt eine Modell-API aufzurufen. Wenn deine Workflows überwiegend Integrationen sind, erhöhe zuerst den RAM vor den Kernen.

Wann du den Queue-Modus brauchst

Standardmäßig führt n8n alles in einem Prozess aus. Der Queue-Modus teilt das auf: Eine Haupt-Instanz nimmt Trigger an und übergibt Ausführungen über Redis an separate Worker-Prozesse, sodass der Hauptprozess reaktionsfähig bleibt, egal wie lange ein Job dauert. Das ist die Standardantwort auf die Skalierung von n8n, und es ist auch der Grund, warum die meisten veröffentlichten Dimensionierungsempfehlungen so schwer aussehen.

Du brauchst ihn, wenn eines davon zutrifft, und nicht vorher:

• Lange Ausführungen blockieren kurze. Ein Workflow, der fünf Minuten dauert, lässt einen eingehenden Webhook im Einzelprozess-Modus dahinter warten. Im Queue-Modus bestätigt die Haupt-Instanz sofort, und ein Worker erledigt die Arbeit.
• Du siehst einen sichtbaren Rückstau. Das klarste Signal sind Ausführungen, die im n8n-UI länger als ein paar Sekunden im Wartezustand hängen. Das ist eine entstehende Warteschlange, und kein zusätzlicher RAM in einem Prozess beseitigt sie.
• Ein schwerer Job kann die ganze Instanz mit in den Abgrund reißen. Isolation ist oft die eigentliche Motivation und nicht der Durchsatz.

Der Queue-Modus fügt deinen Anforderungen zwei Dinge hinzu. Redis, das mit rund 128 MB klein ist, aber eine weitere zu betreibende Komponente, und RAM pro Worker: Jeder Worker-Prozess verbraucht grob 200 bis 500 MB, je nachdem, was deine Workflows transportieren. Zwei Worker sind der sinnvolle Startpunkt, und du fügst nur dann weitere hinzu, wenn der Rückstau es verlangt. Worker brauchen weit mehr RAM als Kerne, weshalb der übliche Skalierungspfad zwei- bis dreimal Speicher hinzufügt, bevor er CPU hinzufügt.

Ganz ehrlich: Eine Queue-Modus-Bereitstellung mit mehreren Workern braucht eine Redis-Komponente und mehr Speicher, als die obigen Stufen bieten, daher sind diese Tarife nicht dafür gedacht. Sie sind n8n mit einer Instanz und einer hochverfügbaren Datenbank, was die große Mehrheit der selbstgehosteten Instanzen tatsächlich ist. Wenn du einen Rückstau gemessen hast und wirklich Worker brauchst, bist du einer Ein-Klick-Bereitstellung entwachsen und solltest dafür einen dedizierten Stack dimensionieren.

Speicher und das, was wächst

n8n selbst braucht sehr wenig Speicherplatz. Der Ausführungsverlauf wächst, und zwar proportional dazu, wie oft deine Workflows laufen, nicht danach, wie viele du hast. Ein Workflow, der alle zehn Minuten eine API abfragt, erzeugt allein rund 4,300 Ausführungen im Monat. Bereinige gespeicherte Ausführungsdaten nach einer Aufbewahrungsrichtlinie, statt zu warten, bis der Speicherplatz die Entscheidung für dich trifft, und behalte fehlgeschlagene Ausführungen länger als erfolgreiche, denn nur die liest du je.

Anforderungen, die keine Hardware sind

Zwei davon zählen mehr als jede Spezifikation. Webhooks brauchen eine stabile öffentliche HTTPS-URL, das heißt eine echte Domain, ein gültiges Zertifikat und einen Reverse Proxy vor n8n; eine selbstgehostete Instanz ohne das kann Zeitpläne ausführen, aber nichts empfangen. Und eine Automatisierungsplattform muss laufen, wenn der Trigger auslöst, was einen Laptop ausschließt und Verfügbarkeit im gleichen Sinne zur Anforderung macht wie RAM.

Häufig gestellte Fragen