n8n binary data limits workflows in a way that rarely shows up in testing. A workflow built and tested against a handful of small sample files runs cleanly, then the same workflow crashes, hangs, or throws an unexplained error the first time it meets a real PDF, a large image, or an export file. n8n’s own documentation confirms the mechanism directly: n8n keeps binary data in memory by default, and that default “can cause crashes when working with large files.” The part most teams miss is that there is no single number to check against. Self-hosted n8n, self-hosted n8n running in queue mode, and n8n Cloud each hit a different ceiling, and the fix for one does not apply to the other two.
n8n Binary Data Limits Workflows Are Really Three Different Ceilings
Per n8n’s own documentation on handling binary data, the default behaviour is stated plainly: “When handling binary data, n8n keeps the data in memory by default. This can cause crashes when working with large files.” That single sentence is the root cause behind most “this workflow just stopped working” reports involving a PDF, an image export, or a document attachment: nothing in the workflow logic changed, the file simply got big enough to exhaust whatever memory the process has available at the time.
What changes the picture is that n8n documents three separate settings that govern this, not one. Self-hosted n8n running in its default mode can switch to disk storage with a single environment variable. Self-hosted n8n running in queue mode cannot use that same variable and instead answers to a Redis relay size cap on webhook responses. n8n Cloud exposes neither setting to the user and instead enforces a fixed RAM ceiling per plan, documented separately from anything about binary data modes at all. A team that reads only one of these three sources and applies its fix everywhere will “solve” a problem that was never the one actually happening on that particular deployment.
Why the Default Memory Mode Crashes on Large Files
For a standard self-hosted install, n8n’s own environment variable documentation confirms the same default from a different angle: “By default, n8n uses memory to store binary data.” The N8N_DEFAULT_BINARY_DATA_MODE variable defaults to default, which “keeps binary data in memory. Set to filesystem to use the filesystem, s3 to use AWS S3, azure to use Azure Blob Storage, or database to use the DB.” n8n’s own scaling documentation states the fix in one line: “To avoid this, change the N8N_DEFAULT_BINARY_DATA_MODE environment variable to filesystem. This causes n8n to save data to disk, instead of using memory.” For a workflow processing PDFs, image exports, or attachments on a self-hosted instance, this single variable is usually the entire fix, and it needs setting once at the instance level, not per workflow.
Queue mode removes that fix from the table. The same scaling documentation is explicit: “If you’re using queue mode, switch this to database. n8n doesn’t support filesystem mode with queue mode.” Database mode has its own ceiling worth knowing before relying on it: N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE defaults to 512 MiB and, per the environment variable documentation, “can’t exceed 1024, the limit of a database column. Storing a larger file fails.” A queue-mode workflow that needs to move genuinely large files, well beyond that ceiling, needs S3 or Azure external storage instead, which n8n’s own external storage documentation confirms is “available on: Self-hosted: Business, Enterprise. It isn’t available on n8n Cloud.” A team on queue mode that copies the “just set filesystem mode” fix from a self-hosted default-mode setup will find it simply doesn’t apply.
Binary Data Limits by Mode and Plan
Each row below is governed by a different documented setting, which is exactly why a single “the binary data limit is X” answer doesn’t exist. What counts as the ceiling depends entirely on which deployment and which mode a workflow is actually running under.
| Deployment and mode | What governs the ceiling | Documented effect |
|---|---|---|
| Self-hosted, default mode | Available process memory | Binary data stays in memory; large files “can cause crashes” |
| Self-hosted, filesystem mode | N8N_DEFAULT_BINARY_DATA_MODE=filesystem | Data saved to disk instead of memory; not supported in queue mode |
| Self-hosted, database mode | N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE | 512 MiB default, hard cap 1024 MiB (a database column limit); larger files fail |
| Self-hosted, S3 or Azure mode | External storage config, Business or Enterprise only | No documented file size cap of its own; not available on n8n Cloud |
| Self-hosted queue mode, webhook responses | N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX | 64 MiB default; a larger response fails the node unless offloaded to storage |
| n8n Cloud, any plan | Fixed instance RAM per plan | 320 MiB (Trial, Starter) up to 4096 MiB (Enterprise); exceeding it can crash the instance |
The queue mode row is worth reading twice, because it is not a file size limit at all in the way the others are. n8n’s own documentation on enabling queue mode describes it precisely: “A response from a Respond to Webhook node travels from the worker back to that instance inside a queue message, so Redis holds the whole response while the message is in flight.” The default cap sits at 64 MiB, and “Redis holds several copies of a response in flight, so budget about 1.5 times this value in Redis memory for each response in flight.” A workflow that returns a generated file directly from a webhook, rather than uploading it somewhere and returning a link, is the exact shape of workflow this limit catches.
The n8n Cloud vs Self-Hosted Difference That Actually Matters
The single biggest gap between deployments is that n8n Cloud removes the self-hosted fix from the table entirely. There is no user-facing way to set N8N_DEFAULT_BINARY_DATA_MODE on n8n Cloud, and n8n’s own documentation on external storage confirms the alternative routes are gone too: “External storage is available on: Self-hosted: Business, Enterprise. It isn’t available on n8n Cloud.” A Cloud workflow processing a large file has nowhere to move the data out of memory. What actually happens instead is governed by n8n’s own documentation on managing Cloud data: “complex workflows processing large amounts of data can exceed n8n’s memory limits. If this happens, the instance can crash and become inaccessible.” The RAM ceiling behind that statement is fixed and published per plan: 320 MiB on Trial and Starter, 640 MiB on Pro-1, 1280 MiB on Pro-2, and 4096 MiB on Enterprise, and n8n’s own documentation notes “n8n itself consumes memory to run. On average, the software alone uses around 180MiB RAM” before a workflow has processed anything at all, which leaves genuinely little headroom on the lower Cloud tiers for a workflow handling multi-megabyte files.
Cloud adds a second, unrelated constraint that self-hosted deployments don’t have by default. Per n8n’s own documentation on common Webhook node issues: “n8n Cloud uses Cloudflare to protect against malicious traffic. If your webhook doesn’t respond within 100 seconds, the incoming request will fail with a 524 status code.” A workflow that reads, transforms, or extracts text from a large file inside a webhook-triggered execution can legitimately take longer than 100 seconds on a big enough input, and that failure has nothing to do with memory or binary data mode at all: it is a Cloudflare-enforced request timeout specific to Cloud, not a general n8n behaviour. A self-hosted instance behind its own infrastructure has no equivalent built-in ceiling on how long a webhook can take to respond.
Where Teams Get This Wrong
The first common mistake is applying the self-hosted default-mode fix to a queue-mode problem. Setting N8N_DEFAULT_BINARY_DATA_MODE to filesystem does nothing on an instance already running in queue mode, since n8n’s own documentation states plainly that filesystem mode isn’t supported there; the correct move is database, S3, or Azure storage instead, and picking database mode still leaves the 512 MiB to 1024 MiB file size ceiling to plan around.
The second common mistake is assuming a workflow that runs fine self-hosted will behave the same way on n8n Cloud, when the fixes available to each are not the same. A self-hosted instance with 8 GiB of host RAM and filesystem mode enabled can comfortably process files that would crash the same workflow on a Cloud Starter plan’s 320 MiB ceiling, and there is no environment variable a Cloud user can set to change that.
The third common mistake is treating a webhook timeout on Cloud as a binary data problem and trying to fix it with storage configuration, when it is actually the separate 100-second Cloudflare limit documented for n8n Cloud specifically. Moving a large file to filesystem or database storage does not make an execution respond faster within that window; the fix for a genuinely slow, large-file operation is to return an immediate response and process the file asynchronously, rather than trying to finish the work inside the original webhook call.
The fourth common mistake is expecting execution pruning to relieve an active out-of-memory problem. n8n’s own documentation on managing execution data describes pruning as age or count based, deleting “finished executions along with their execution data and binary data on a regular schedule,” with defaults of 336 hours or 10,000 executions, whichever comes first. Pruning controls long-term database growth from accumulated binary data; it does nothing for a single execution that is already too large to fit in memory while it’s running.
Related Reading
For the automation layer these binary-heavy workflows usually sit inside, see n8n Consultancy. For the CRM side of file-heavy automations, such as attachments and generated documents, see HubSpot Consultancy. For the broader integration pattern most large-file workflows are built around, see HubSpot n8n Integration Guide.
Go deeper: Advanced n8n Webhook Listeners for Real-Time SaaS and RevOps Automation · Advanced n8n Error Handling Strategies for Resilient SaaS Workflows · RevOps Consultancy
Frequently Asked Questions
Why does my n8n workflow crash only on large PDFs or images?
Because n8n’s own documentation confirms binary data is kept in memory by default, and this “can cause crashes when working with large files.” Small test files never use enough memory to trigger the problem, which is why it only appears once a genuinely large file reaches the workflow.
Can I raise n8n’s binary data size limit on a self-hosted instance?
Yes, by changing how it’s stored rather than raising a single number. Setting N8N_DEFAULT_BINARY_DATA_MODE to filesystem moves data to disk instead of memory. In queue mode, filesystem isn’t supported, so database mode (capped at 1024 MiB per file) or S3 or Azure storage is used instead.
Does n8n Cloud have a fixed memory limit that affects large files?
Yes. n8n’s own documentation states each Cloud plan has a fixed RAM ceiling, from 320 MiB on Trial and Starter up to 4096 MiB on Enterprise, and that exceeding it “can crash the instance and become inaccessible.” Cloud does not expose the binary data mode setting self-hosted instances use to avoid this.
Why is filesystem mode not available when n8n runs in queue mode?
n8n’s own documentation states plainly that queue mode doesn’t support filesystem binary data storage. The same page notes that in filesystem mode, every instance would need to mount the same disk, which n8n doesn’t recommend. The documented alternative for queue mode is database, S3, or Azure storage instead.
Does n8n Cloud’s 100 second webhook timeout relate to binary data limits?
It’s a separate, Cloudflare-enforced limit specific to n8n Cloud, not a binary data setting. n8n’s own documentation confirms a webhook that doesn’t respond within 100 seconds fails with a 524 status code, regardless of whether the slowdown is caused by a large file or something else entirely.