How can I stop n8n from accumulating excessive RAM after each run?

Below is some guidance based on the documentation regarding memory usage and execution data in n8n.

Why Memory May Increase on Each Run

n8n doesn’t restrict data flow between nodes, and by default, manual executions also create copies of the data for display in the UI. This can result in gradual increases in RAM over successive executions—even if your workflow isn’t processing an unusually large amount of data. In your case, even if every HTTP request processes around 30MB, n8n might keep copies of this data once the execution finishes because:

• Execution data remains in memory for the UI.
• The system may not immediately free memory allocated for the execution (garbage collection in Node’s V8 engine can delay releasing memory).

Points to Consider

1. Manual Executions and UI Data Copies
   When testing via the UI (as with a test trigger), n8n caches execution data. If you don’t disable saving these executions (or prune them), the memory used by these copies accumulates.

2. Execution Data Logging
   Even though you mentioned “binning the workflow” to clear data, the execution data might still be there unless explicitly disabled or pruned. On n8n Cloud there are settings to not save successful execution data. For self-hosted instances, you might consider configuring your workflow settings so that you don’t save executions you don’t need.

3. Behavior in Docker vs. npm
   The RAM usage in Docker (showing 275MB) versus what you see in system monitor (e.g. “web content” showing 5GB) might indicate that the container reports lower memory usage while the browser or additional processes (for example, the UI) are holding onto larger amounts of memory. Note that the V8 runtime may keep memory allocated even if it isn’t actively used, and the memory is only released on a full restart.

Recommendations

• Control Execution Data
  If you’re running tests, consider disabling logging of successful executions:

  1. In your workflow’s options (within n8n’s UI), open Settings and change Save successful production executions to Do not save.
  2. For a system-wide approach, consider periodically pruning execution data. Refer to the Cloud data management guidelines for details.

• Monitor and Understand Memory Usage
  A steady increase seen in system monitors might not necessarily indicate a leak. The V8 engine can hold memory for performance and only release it on a full restart. Compare the memory usage reported by your Docker container (which appears stable) with what the OS reports.

• Evaluate Workflow Nodes
  Although you mentioned that the workflow doesn’t influence the behavior, if you’re using nodes known to be memory heavy (like the Code node), try to avoid them or split the workflow into sub-workflows as suggested in our reduce-memory-consumption guidelines.

• Upgrade n8n
  If you haven’t done so, check if an update beyond version 1.77.3 addresses any memory management improvements or bug fixes.

Final Thoughts

The observed accumulation of RAM after multiple executions is consistent with how n8n manages execution data alongside the Node.js garbage collector’s behavior. By ensuring execution data isn’t unnecessarily persisted and by understanding the memory allocation behavior of Node.js, you can mitigate the appearance of “excessive” memory usage.

If you continue to experience issues and believe there might be a bug, consider reaching out on the n8n community forum or GitHub repository with as much non-sensitive detail as possible.

Hope this helps!