JavaScript heap out of memory: Fixing n8n memory issues

The error "JavaScript heap out of memory" occurs in n8n when a workflow execution requires more memory than the Node.js process of n8n has available. The most common causes are large binary files, extensive JSON data, the Code node, and manual executions where n8n additionally maintains a copy of the data for the interface. The problem can be resolved by allocating more memory to the n8n process via the environment variable NODE_OPTIONS with the parameter --max-old-space-size, by switching binary data processing to filesystem mode, and through regular execution pruning, which automatically deletes old execution data. Status: July 2026.

Why does n8n report the error "JavaScript heap out of memory"?

The error occurs because n8n, as a Node.js application, by default uses only a limited amount of memory for the so-called heap size of the V8 engine, and this limit is exceeded with memory-intensive workflows.

According to the official n8n documentation on fixing memory issues the memory requirements of an execution depend mainly on the amount of JSON data, the size of binary data, the number of concurrent executions, and the use of the Code node. Manual executions via the editor also increase consumption because n8n additionally maintains a copy of the data for the live view in the frontend.

• Large data volumes: Many JSON objects or large binary files per execution.
• Code node: Custom JavaScript logic can significantly increase memory consumption.
• Manual execution: Additional data copy for live display in the editor.
• Concurrent executions: Multiple simultaneously running workflows add up.

How do you allocate more memory to n8n via NODE_OPTIONS?

You increase the available memory by passing the parameter --max-old-space-size with a higher memory limit in megabytes to the Node.js process via the environment variable NODE_OPTIONS.

According to the documentation, when you encounter a "JavaScript heap out of memory" error, it pays to enlarge the so-called old-memory area of the V8 engine, either via the command line or via NODE_OPTIONS. For self-hosted instances, this practically means: for example, you set NODE_OPTIONS with the value --max-old-space-size=4096 to allocate approximately four gigabytes of old heap memory to the process, and then restart n8n. It is important to note: this setting only takes effect if the server or container actually has sufficient physical memory available. If that is not enough, the documentation recommends equipping the instance with more resources in general or choosing a larger plan in the n8n Cloud.

How do you prevent memory issues from binary data?

By default, n8n keeps binary data such as files, images, or PDFs directly in memory, which is why large files quickly lead to crashes if you do not switch the storage mode to the filesystem.

According to the documentation on handling binary data n8n stores binary data in memory by default, which can lead to crashes with large files. Via the environment variable N8N_DEFAULT_BINARY_DATA_MODE, the mode can be switched to filesystem, so n8n writes the data to disk instead. In queue mode, the filesystem mode is not supported according to the documentation; instead, database mode is used there. Important to know: the cleanup of binary data also runs via the respectively active storage model. If you change the mode, older data remains in the previous storage location until manually removed.

How does execution pruning help against growing memory consumption?

Execution pruning automatically deletes completed executions along with associated execution and binary data based on age or count, so that the database and storage do not grow uncontrollably.

According to the documentation on managing execution data pruning is enabled by default and takes effect once an execution is older than the value of EXECUTIONS_DATA_MAX_AGE in hours (default: 336 hours, i.e., 14 days) or the total number of executions exceeds the value of EXECUTIONS_DATA_PRUNE_MAX_COUNT (default: 10,000). Running, pending, or new executions as well as executions with tags or ratings are never deleted. Additionally, a safety buffer via the variable EXECUTIONS_DATA_HARD_DELETE_BUFFER (default: one hour) ensures that you can still view recently completed executions while memory is freed up in the background.

• EXECUTIONS_DATA_PRUNE: Enables automatic cleanup, is active by default.
• EXECUTIONS_DATA_MAX_AGE: Deletes executions after age in hours, default 336.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: Limits the total number of stored executions, default 10,000.

What workflow adjustments additionally reduce memory requirements?

Besides server-side settings, you most effectively reduce memory requirements directly in workflow design by processing data in smaller portions instead of loading everything at once.

The n8n documentation specifically recommends dividing data into smaller blocks, processing about 200 instead of 10,000 records per execution, avoiding the Code node where possible, and executing large data quantities via a trigger rather than manually. For very large data volumes, the documentation suggests splitting the workflow into sub-workflows using the Loop Over Items node and the Execute Workflow node, so that only the data of the current batch is held in memory and then released again. If you use n8n productively for more complex automations and do not want to rebuild these controls yourself, NordFlux supports you with setting up and securing n8n workflows including appropriate server configuration.

Frequently asked questions about n8n memory issues

How much memory should an n8n server have at minimum?

The documentation does not specify a fixed minimum value, but points out that the requirement depends on the data volume and the number of concurrent executions. In practice, you should provide enough memory so that the max-old-space-size set via NODE_OPTIONS is also physically covered; otherwise, you are just shifting the problem.

Does a higher NODE_OPTIONS setting solve every memory problem?

No, a higher heap limit only provides more buffer but does not fix the underlying cause such as inefficient workflows or uncontrolled growth of binary data. According to the documentation, you should also reduce the data volume per execution and keep execution pruning active so that memory requirements remain within limits long-term.

What happens if I disable execution pruning?

Without pruning, completed executions along with execution and binary data accumulate unlimited in the database. According to the documentation, this leads to increasing memory consumption in the long term, which is why n8n has cleanup enabled by default.

Why does the error occur primarily with manual executions?

Because when executing manually via the editor, n8n additionally maintains a copy of the execution data for live display in the frontend. With large data volumes, this noticeably increases memory requirements, which is why the documentation recommends starting extensive processing via a trigger instead of manually.