When n8n runs out of memory, either the system kills the container (and Docker restarts it, without telling you) or the workflow fails with a memory error. Nearly always the cause is the same: a workflow loads too much data at once. Less often it is the execution history growing, or a VPS too small for everything running on it.
Confirming it is memory
| 1 |
Watch the usage live with docker stats while the suspect workflow runs. If the container memory climbs to the end and it drops, that is it.
|
|
| 2 |
Check the memory of the whole VPS with free -h. Another container may be the one eating it, not n8n.
|
|
| 3 |
Ask Docker whether it was killed for lack of memory: docker inspect on the container shows an “OOMKilled” field in its state.
|
|
| 4 |
Read the logs with docker compose logs at the moment of the crash, and the time the container restarted, to learn which workflow was running.
|
|
The causes, and what to do about each
| Cause |
What to do |
| A node reads thousands of rows at once (database, spreadsheet, API) |
Ask only for the columns and rows you need and process in batches, with the node meant for it, described in the documentation. |
| Large files or images passing through the workflow |
Binary data takes memory. The n8n documentation describes how to keep it on disk rather than in memory; look for the binary data variables. |
| One workflow calls another and hands it everything |
Split the work into sub-workflows that return only what the next one needs. |
| Many executions at the same time |
Spread out the schedule times. For heavy loads, the documentation describes a mode with queues and separate workers. |
| A huge execution history |
Switch on automatic clean-up of old executions (variables described in the documentation) and choose, in the workflow settings, what is worth keeping. Very frequent workflows fill the history fast. |
| The code node working with everything in memory |
Filter before the data reaches the node, and return only what is needed. |
| A small VPS, with other containers pitching in |
Add up what each service uses. If it does not fit, the problem is the plan, not n8n. |
|
Raising Node’s memory limit does not create memory. n8n is a Node.js application and there is an option to give it more working space, but if the machine does not have the memory it only postpones the crash and risks the system killing other services. Fix the workflow first.
|
When it really is the plan
If the workflows are already in batches and memory is still short, it is time to change plan. Compare on VPS servers and Cloud servers. Before that, take a look at the disk and the other common causes of crashes in common VPS and Cloud errors, and at the space Docker takes in Docker filling the disk.
Change one thing at a time and measure again with docker stats. That way you know which change solved it, and you do not end up with five alterations nobody remembers.
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $6.59/mo (3-year plan, with coupon) See plans |
Português
English
