n8n meldet 'JavaScript heap out of memory'? So beheben Sie es mit NODE_OPTIONS, Dateisystem-Modus und Execution-Pruning.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
Warum ein n8n-Agent den Chatverlauf vergisst, wie Session-Keys funktionieren und wann Simple Memory oder Postgres Memory die richtige Wahl ist.
Einen KI-Agenten erstellen Sie in n8n aus vier Bausteinen: Trigger, Chat-Modell, Memory und Tools. Die Anleitung mit Praxis-Tipps und typischen Fehlern.
Sammelseite der häufigsten n8n AI-Agent-Fehlerbilder: Prompt, Rate-Limits, Memory und Output-Parser im Überblick, mit Links zur n8n-Doku.
NODE_OPTIONS, der Umgang mit Binärdaten und ein sauberes Execution-Pruning entscheiden darüber, ob n8n unter Last stabil bleibt oder regelmäßig mit „JavaScript heap out of memory" abstürzt. NordFlux übernimmt den betreuten n8n-Betrieb inklusive Ressourcen-Dimensionierung, Speicher-Monitoring und Execution-Pruning, damit wachsende Workflows nicht zum Ausfallrisiko werden. Im ersten Gespräch analysieren wir Ihre Server-Ressourcen und Ihre größten Speicherfresser unter den Workflows.
