Large Binary Data: Why 100 PDFs Kill the Server

When a workflow suddenly has to process 100 PDFs at once, it looks like a simple task on paper: read files, extract text, pass them on. In practice, this workflow often crashes in the middle of execution, the n8n container is restarted, and the log only shows a sobering "Out of memory". The reason is almost always in the same place: n8n keeps binary data in RAM by default, not on disk.

For individual files or small images, this hardly matters. But once you process dozens or hundreds of PDFs, scans, or attachments in a single run, each individual file adds to the RAM consumption of the process until the server or container reaches its limit. You can avoid this reproducibly without rebuilding the workflow itself if you know which lever to turn. This article shows why the memory explosion happens and how to control it through the right binary data mode.

Why 100 PDFs Blow Up Memory

n8n technically distinguishes between the actual workflow data flow and so-called binary data, that is, files like PDFs, images, or Excel attachments that flow through a workflow. According to the official documentation on binary data, n8n keeps this data in RAM by default, which is unproblematic with small amounts of data, but quickly leads to performance issues with large files or many files at once. There is no built-in brake: n8n neither limits how many files a workflow holds at once, nor does the software automatically reserve memory for a node. A workflow that reads 100 PDFs from a mailbox or folder and processes them with the Extract-from-File node can thus consume more RAM file by file until the container reaches its limit and crashes.

A user in the n8n community forum describes this exact pattern: when migrating around 2,000 records with 150 to 200 attachments each, the workflow regularly broke on an 8-GB VPS after about 50 processed files because the default mode kept all binary data in RAM. The effect is the same with 100 PDFs as with 2,000 attachments, just becomes visible more quickly if your server is thinly provisioned.

Binary Data Modes at a Glance

n8n offers several storage modes for binary data, controlled via the environment variable `N8N_DEFAULT_BINARY_DATA_MODE`:

• memory (default): All files remain in the RAM of the n8n process. Simple, but without any upper limit.
• filesystem: n8n writes binary data to disk instead of RAM. According to documentation, this prevents crashes with large files because memory consumption per execution drops significantly.
• s3: Binary data goes into an external S3-compatible bucket instead of the local disk or RAM.
• database: Used when Filesystem mode is not available, for example in Queue mode.

Important for multi-worker setups: According to documentation, n8n does not support Filesystem mode in Queue mode. In that case, database mode must be used instead, unless shared storage is available.

Switching to Filesystem Mode: The Fastest Solution

For most single-instance setups, switching the mode to Filesystem is sufficient:

• Set the environment variable `N8N_DEFAULT_BINARY_DATA_MODE` to `filesystem`.
• Restart the n8n instance for the variable to take effect.
• Make sure the underlying volume has enough disk space, because now PDFs will land on disk instead of RAM.
• Plan regular cleanup, as n8n does not automatically empty the folder with binary data, but instead controls it through execution data cleanup.

The community user from the thread mentioned above describes the effect as follows: the memory curve remained permanently low after the switch and the previous spike completely disappeared. For a workflow that processes 100 PDFs at a time, this is usually already the complete solution, without any code changes to the workflow itself.

S3 Mode When Filesystem Is Not Enough

If your n8n instance runs in Queue mode with multiple workers on separate machines, local disk storage helps only partially because not every worker automatically has access to the same files. For this case, the documentation on external storage describes the S3 connection. It is configured via several environment variables:

• `N8N_EXTERNAL_STORAGE_S3_HOST`, `N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME` and `N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION` for the target infrastructure.
• `N8N_EXTERNAL_STORAGE_S3_ACCESS_KEY` and `N8N_EXTERNAL_STORAGE_S3_ACCESS_SECRET` for the access credentials.
• `N8N_AVAILABLE_BINARY_DATA_MODES=filesystem,s3` and `N8N_DEFAULT_BINARY_DATA_MODE=s3` to actually enable the mode.

Important to know: According to documentation, S3 connection requires a valid Enterprise license, without which n8n will not start in this mode. Additionally, you should set up a lifecycle policy in the bucket that automatically deletes old binary data, as n8n does not clean up there itself.

Don't Forget to Clean Up: Execution Data Cleanup

Even with Filesystem or S3 mode, your storage needs continue to grow if old executions are never deleted. The documentation on managing execution data describes the following variables for this:

• `EXECUTIONS_DATA_PRUNE` enables automatic cleanup.
• `EXECUTIONS_DATA_MAX_AGE` specifies after how many hours a completed execution is considered deletable, default value 336 hours, that is 14 days.
• `EXECUTIONS_DATA_PRUNE_MAX_COUNT` additionally limits the maximum number of stored executions, default value 10,000.
• `EXECUTIONS_DATA_HARD_DELETE_BUFFER` provides a grace period of one hour by default before data is permanently removed.

A detail that is easily overlooked: according to documentation, cleanup always only affects the currently active binary data mode. So if you switch from Filesystem to S3, old files may remain on the local disk and need to be manually removed.

If you're unsure which mode fits your setup, or if an existing n8n workflow regularly crashes with larger PDF quantities, we'd be happy to look at it together as part of our n8n automation services. As digital workers, we set up the configuration cleanly once, document it, and hand it over to you so that afterward you maintain control over your server resources.

Frequently Asked Questions

Why Does n8n Only Crash at a Certain Number of PDFs, Not Immediately?

Because in the default mode, each individual file occupies additional RAM. With few small files, enough buffer remains, but with each additional PDF in the same run, RAM consumption continues to rise until the available memory of the container or server is exhausted and the process crashes.

Is Switching to Filesystem Mode Enough for 100 PDFs per Run?

Yes, in most single-instance setups, because the files then lie on disk instead of in RAM and RAM consumption per execution drops significantly. If you run in Queue mode with multiple separate workers, you additionally need either shared storage or S3 mode, because n8n does not support Filesystem mode there.

Do I Need a Specific n8n License for S3 Storage?

Yes. According to official documentation, S3 connection for binary data is tied to a valid Enterprise license, without which the instance will not start in S3 mode. For smaller setups without multiple worker machines, the free Filesystem mode is usually the simpler and sufficient solution.

Do I Have to Delete the Binary Data Folder Manually?

n8n does not automatically clean up the folder, but instead ties cleanup to execution data pruning settings like `EXECUTIONS_DATA_PRUNE` and `EXECUTIONS_DATA_MAX_AGE`. If pruning is active, old executions including their binary data in active mode are regularly removed. If pruning is disabled, the folder continues to grow indefinitely.