n8n Lifted the 64 MiB Webhook Ceiling. Turn It On in the Wrong Order and Your Caller Gets a File Reference.

August 6, 2026. If you run n8n in queue mode and a workflow ever has to hand a large payload back to whoever called it, n8n has shipped the fix you have probably been working around. On August 4, in n8n 2.34, workers gained the ability to offload an oversized webhook response body into storage instead of failing the node. The feature is real, and the documentation behind it is unusually specific. It also carries an upgrade order that, done backwards, does not throw an error. It returns a storage reference to your caller where the data should be, wrapped in a response that looks like it worked.

What n8n shipped on August 4

1. The entry is dated August 4, 2026 on n8n's changelog, titled "Return webhook responses of any size from your workers," and names n8n 2.34 as the release.
2. Why the limit exists at all. In queue mode a worker runs the execution, but the client that made the request stays connected to the main or webhook instance. A response from a Respond to Webhook node has to travel back through the queue, so Redis holds the whole response while that message is in flight.
3. The ceiling is 64 MiB by default, set by N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX. Above it, without offloading, the node fails.
4. The new switch is one variable on your workers. Set N8N_WEBHOOK_RESPONSE_RELAY_OFFLOAD_ENABLED=true and a body above the limit goes into binary data storage instead. The queue message then carries only a reference, the main instance streams the body from storage to the client, and n8n deletes the stored copy once it delivers the response.
5. It needs somewhere real to write. Offloading requires an N8N_DEFAULT_BINARY_DATA_MODE that actually stores data, meaning any mode except default, and storage every instance can read.

The payloads this was blocking, and what the ceiling costs in Redis

n8n names the cases plainly in its queue mode documentation: a wide result set from a database query, a batch of aggregated API calls, or a CSV or XML document assembled inside the workflow. These are not exotic. They are the ordinary output of a reporting endpoint, an export job, or an internal API you built on n8n because it was faster than writing a service.

The same page adds a number worth putting in your capacity plan. Redis holds several copies of a response while it is in flight, so n8n tells you to budget roughly 1.5 times the size limit in Redis memory for every response in flight. At the 64 MiB default, ten concurrent large responses is close to a gigabyte of Redis you may never have accounted for. Raising the limit instead of offloading raises that number with it, which is the quiet argument for offloading rather than for a bigger ceiling.

Storage mode is not a neutral choice either. n8n recommends s3 or azure, because both stream the body and the main instance only holds one chunk at a time. In database mode the main instance loads the whole body into memory before sending it and the response passes through your primary database, capped by N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE up to the 1 GB a database column holds. In filesystem mode every instance has to mount the same disk, which n8n says it does not recommend. Worth noting for anyone reading fast: the top of that same page states that n8n does not support queue mode with binary data storage in filesystem at all, while the offload section lists filesystem as a mode you can set. Those two statements sit on one page and n8n has not reconciled them in writing. If filesystem is your only option, that is a question to put to n8n before you build on it, not a gap to guess your way through.

The upgrade order is the whole story

Here is the part that deserves a line in your runbook. Only a main instance running 2.34.0 or later can read an offloaded body. An older one, in n8n's own words, returns the storage reference to the client instead of the response body. That is not a failed execution you will see in your error workflow. That is a caller receiving a well formed response containing the wrong thing, and the first person to notice is whoever consumes your endpoint.

So the sequence is fixed: upgrade every main and webhook instance first, then set the variable on your workers. n8n ships the variable turned off by default precisely so nobody trips this accidentally. A worker with the variable unset behaves exactly as before, sending every response inline and failing one above the limit, which is the safe half of the failure surface. One more constraint that catches people: n8n only offloads the response body. Headers and status code are measured against the same limit, so a response whose headers alone exceed it fails either way.

The MCP carve out almost nobody has mentioned

If you expose n8n workflows as tools over the MCP Trigger, and a growing number of agencies now do, read this twice. The same size limit applies to a tool result an MCP Trigger workflow returns from a worker, and n8n states you cannot offload a tool result. An oversized one reaches the MCP client as a tool error naming the limit.

That matters more than it sounds. A webhook consumer that gets an error usually retries or alerts a human. A model that gets a tool error tends to reason around it, try a different tool, or answer from what it already has. The failure is not loud, it is absorbed. If you are building agent tooling on n8n, the practical fix is to make oversized results impossible rather than to handle them: paginate the tool, return a summary with a fetch link, or write the artifact to storage yourself and return the URL. That design discipline is the same one that separates an AI automation build that survives contact with real data from a demo that works once.

Where this is documented, and where it is not

n8n publishes three release surfaces, and this feature does not appear on all of them. The narrative changelog carries it. The queue mode scaling guide carries the full configuration, the upgrade order, and a four row troubleshooting table with the exact error strings. The per release release notes entry for 2.34, also dated August 4, is headlined "OIDC logout support added and made opt-in, plus 18 other features," and none of those nineteen bullets is the webhook response offload.

If you track n8n by the release notes page or its RSS feed, which is the obvious thing to do, the change to production behaviour you most needed to see is the one you would have missed. n8n also states on that page that publishing there does not guarantee a feature is available to you yet, since some ship behind a feature flag and others roll out gradually. And as this is published, n8n's docs list the current stable release as 2.33.4 and the current beta as 2.34.1, with stable described as the version for production use. Check what your own instance is actually running before you plan around any of this.

What it means for operators

Three things are worth doing this week, and none of them takes long. First, find out whether you are in queue mode and what your main instances are running, because the upgrade order only bites people who enable the worker side early. Second, look at whether any live workflow returns a response that could grow: an export, a report, a data pull that was small at signup and is not small now. The 64 MiB ceiling is generous until a customer's dataset triples. Third, if you run MCP tools, audit their largest plausible output today, because that path has no escape hatch.

The wider lesson is the one this engine keeps running into. Self hosted automation is cheap to start and expensive to operate blind, and the facts that decide whether a workflow survives production tend to live in a scaling guide nobody reads until something breaks. If you would rather not be the person reading it at 2am, that is exactly the ground a dedicated n8n developer covers, and it is the same discipline we bring to any automation engagement where the workflow has to hold up under someone else's traffic.