JavaScript heap out of memory: n8n-Speicherprobleme beheben

Der Fehler "JavaScript heap out of memory" tritt in n8n auf, wenn eine Workflow-Ausführung mehr Arbeitsspeicher benötigt, als der Node.js-Prozess von n8n zur Verfügung hat. Die häufigsten Ursachen sind große Binärdateien, umfangreiche JSON-Datenmengen, der Code-Node sowie manuelle Ausführungen, bei denen n8n zusätzlich eine Kopie der Daten für die Oberfläche vorhält. Beheben lässt sich das Problem durch mehr Arbeitsspeicher für den n8n-Prozess über die Umgebungsvariable NODE_OPTIONS mit dem Parameter --max-old-space-size, durch die Umstellung der Binärdatenverarbeitung auf den Dateisystem-Modus sowie durch regelmäßiges Execution-Pruning, das alte Ausführungsdaten automatisch löscht. Stand: Juli 2026.

Warum meldet n8n den Fehler "JavaScript heap out of memory"?

Der Fehler entsteht, weil n8n als Node.js-Anwendung standardmäßig nur eine begrenzte Menge an Arbeitsspeicher für die sogenannte Heap-Größe der V8-Engine nutzt und diese Grenze bei speicherintensiven Workflows überschritten wird.

Laut der offiziellen n8n-Dokumentation zum Beheben von Speicherproblemen hängt der Speicherbedarf einer Ausführung vor allem von der Menge an JSON-Daten, der Größe von Binärdaten, der Anzahl gleichzeitiger Ausführungen sowie dem Einsatz des Code-Node ab. Auch manuelle Ausführungen über den Editor erhöhen den Verbrauch, weil n8n dabei zusätzlich eine Kopie der Daten für die Live-Ansicht im Frontend vorhält.

• Große Datenmengen: Viele JSON-Objekte oder große Binärdateien pro Ausführung.
• Code-Node: Eigene JavaScript-Logik kann den Speicherverbrauch deutlich erhöhen.
• Manuelle Ausführung: Zusätzliche Datenkopie für die Live-Anzeige im Editor.
• Parallele Ausführungen: Mehrere gleichzeitig laufende Workflows summieren sich auf.

Wie stellen Sie n8n über NODE_OPTIONS mehr Arbeitsspeicher zur Verfügung?

Sie erhöhen den nutzbaren Speicher, indem Sie dem Node.js-Prozess über die Umgebungsvariable NODE_OPTIONS den Parameter --max-old-space-size mit einer höheren Speichergrenze in Megabyte übergeben.

Laut Dokumentation lohnt es sich bei einem "JavaScript heap out of memory"-Fehler, den sogenannten Old-Memory-Bereich der V8-Engine zu vergrößern, entweder über die Kommandozeile oder eben über NODE_OPTIONS. Für selbst gehostete Instanzen bedeutet das praktisch: Sie setzen zum Beispiel NODE_OPTIONS mit dem Wert --max-old-space-size=4096, um dem Prozess rund vier Gigabyte alten Heap-Speicher zuzuweisen, und starten n8n danach neu. Wichtig ist dabei: Diese Einstellung wirkt nur, wenn dem Server oder Container tatsächlich ausreichend physischer Arbeitsspeicher zur Verfügung steht. Reicht das nicht aus, empfiehlt die Dokumentation, die Instanz grundsätzlich mit mehr Ressourcen auszustatten oder in der n8n Cloud einen größeren Plan zu wählen.

Wie verhindern Sie Speicherprobleme durch Binärdaten?

Binärdaten wie Dateien, Bilder oder PDFs hält n8n standardmäßig direkt im Arbeitsspeicher, weshalb große Dateien schnell zu Abstürzen führen, wenn Sie den Speichermodus nicht auf das Dateisystem umstellen.

Laut der Dokumentation zur Verarbeitung von Binärdaten speichert n8n Binärdaten standardmäßig im Arbeitsspeicher, was bei großen Dateien zu Abstürzen führen kann. Über die Umgebungsvariable N8N_DEFAULT_BINARY_DATA_MODE lässt sich der Modus auf filesystem umstellen, sodass n8n die Daten stattdessen auf die Festplatte schreibt. Im Queue-Modus ist der Dateisystem-Modus laut Dokumentation nicht unterstützt, dort kommt stattdessen der Datenbank-Modus zum Einsatz. Wichtig zu wissen: Auch die Bereinigung der Binärdaten läuft über das jeweils aktive Speichermodell. Wechseln Sie den Modus, bleiben ältere Daten im vorherigen Speicherort liegen, bis sie manuell entfernt werden.

Wie hilft Execution-Pruning gegen wachsenden Speicherverbrauch?

Execution-Pruning löscht abgeschlossene Ausführungen samt zugehöriger Ausführungs- und Binärdaten automatisch nach Alter oder Anzahl, sodass Datenbank und Speicher nicht unkontrolliert wachsen.

Laut der Dokumentation zur Verwaltung von Ausführungsdaten ist Pruning standardmäßig aktiviert und greift, sobald eine Ausführung älter ist als der Wert von EXECUTIONS_DATA_MAX_AGE in Stunden (Standard: 336 Stunden, also 14 Tage) oder die Gesamtzahl der Ausführungen den Wert von EXECUTIONS_DATA_PRUNE_MAX_COUNT übersteigt (Standard: 10.000). Laufende, wartende oder neue Ausführungen sowie mit Tags oder Bewertungen versehene Ausführungen werden dabei nie gelöscht. Zusätzlich sorgt ein Sicherheitspuffer über die Variable EXECUTIONS_DATA_HARD_DELETE_BUFFER (Standard: eine Stunde) dafür, dass Sie kürzlich abgeschlossene Ausführungen noch einsehen können, während im Hintergrund Speicher freigegeben wird.

• EXECUTIONS_DATA_PRUNE: Aktiviert die automatische Bereinigung, ist standardmäßig aktiv.
• EXECUTIONS_DATA_MAX_AGE: Löscht Ausführungen nach Alter in Stunden, Standard 336.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: Begrenzt die Gesamtzahl gespeicherter Ausführungen, Standard 10.000.

Welche Workflow-Anpassungen senken den Speicherbedarf zusätzlich?

Neben den serverseitigen Einstellungen senken Sie den Speicherbedarf am wirksamsten direkt im Workflow-Design, indem Sie Daten in kleineren Portionen verarbeiten, statt alles auf einmal zu laden.

Die n8n-Dokumentation empfiehlt konkret, Daten in kleinere Blöcke aufzuteilen, etwa 200 statt 10.000 Datensätze pro Ausführung zu verarbeiten, den Code-Node wo möglich zu vermeiden und bei großen Datenmengen nicht manuell, sondern über einen Trigger auszuführen. Für sehr große Datenmengen schlägt die Dokumentation vor, den Workflow mit dem Loop-Over-Items-Node und dem Execute-Workflow-Node in Sub-Workflows aufzuteilen, damit jeweils nur die Daten des aktuellen Batches im Speicher gehalten und danach wieder freigegeben werden. Wenn Sie n8n produktiv für komplexere Automatisierungen einsetzen und diese Stellschrauben nicht selbst nachbauen möchten, unterstützt Sie NordFlux bei der Einrichtung und Absicherung von n8n-Workflows inklusive passender Server-Konfiguration.

Häufige Fragen zu n8n-Speicherproblemen

Wie viel Arbeitsspeicher sollte ein n8n-Server mindestens haben?

Die Dokumentation nennt keinen festen Mindestwert, sondern verweist darauf, dass der Bedarf von der Datenmenge und der Anzahl paralleler Ausführungen abhängt. In der Praxis sollten Sie so viel Arbeitsspeicher bereitstellen, dass die über NODE_OPTIONS gesetzte max-old-space-size auch physisch gedeckt ist, sonst verschiebt sich das Problem nur.

Löst eine höhere NODE_OPTIONS-Einstellung jedes Speicherproblem?

Nein, eine höhere Heap-Grenze verschafft nur mehr Puffer, behebt aber nicht die eigentliche Ursache wie ineffiziente Workflows oder unkontrolliert wachsende Binärdaten. Laut Dokumentation sollten Sie zusätzlich die Datenmenge pro Ausführung reduzieren und Execution-Pruning aktiv lassen, damit der Speicherbedarf dauerhaft im Rahmen bleibt.

Was passiert, wenn ich Execution-Pruning deaktiviere?

Ohne Pruning sammeln sich abgeschlossene Ausführungen samt Ausführungs- und Binärdaten unbegrenzt in der Datenbank an. Das führt laut Dokumentation langfristig zu wachsendem Speicherverbrauch, weshalb n8n die Bereinigung standardmäßig aktiviert.

Warum tritt der Fehler vor allem bei manuellen Ausführungen auf?

Weil n8n bei einer manuellen Ausführung über den Editor zusätzlich eine Kopie der Ausführungsdaten für die Live-Anzeige im Frontend vorhält. Bei großen Datenmengen erhöht das den Speicherbedarf spürbar, weshalb die Dokumentation empfiehlt, umfangreiche Verarbeitungen über einen Trigger statt manuell zu starten.