How Much RAM Does One Active n8n Webhook Actually Use?

One active n8n webhook sitting idle and waiting for a call uses well under a megabyte of RAM, because all n8n holds for it is a registered route and a cached copy of the workflow definition. The memory that actually matters appears the moment that webhook fires: a single execution commonly takes anywhere from around 5 MB to several hundred MB, and the size is set by your payload and how many nodes touch it. n8n keeps every node's input and output data in memory until the execution finishes, so a 2 MB JSON body passing through ten nodes can hold 40 MB or more at peak. Separately, a self-hosted n8n container idles somewhere around 150 MB to 400 MB before a single request arrives.

So the short answer to how much RAM does one active n8n webhook use is: close to nothing while parked, and roughly payload size multiplied by node count while it runs.

An idle webhook is a route entry; the execution it triggers is where the RAM goes

When you activate a workflow with a Webhook node, n8n writes a row to its database and registers the URL path on the running process. From then on, the process is holding a path string, a workflow ID, the HTTP method, and the workflow JSON in its cache. That's kilobytes of data, not megabytes.

This is why people running fifty or a hundred active webhooks on one instance rarely see memory climb from the registrations themselves. A hundred route entries plus a hundred cached workflow definitions might add a few megabytes total. You'd struggle to spot that against normal garbage-collection noise in docker stats.

The picture changes when a call comes in. n8n creates an execution, parses the incoming request body into JavaScript objects, and hands that data to the first node. From there, every node's output stays resident until the whole execution ends and the objects become eligible for garbage collection. Ten nodes means ten sets of data held at once.

So two webhooks that look identical in the editor can behave completely differently. A webhook receiving a 400-byte Stripe event and writing one row to Postgres might peak at 3 MB or 4 MB above baseline. A webhook receiving a 10 MB CSV export, splitting it into 8,000 items, and looping through an HTTP Request node can chew through several hundred megabytes on the same instance.

Note: none of the numbers in this article are hard specifications. n8n publishes no per-webhook memory figure because there isn't one to publish. Treat every range here as a planning estimate you should confirm on your own hardware.

Every node holds its own copy, so payload size multiplies down the workflow

This is the single behaviour that explains most n8n memory surprises. n8n's execution model passes data between nodes as arrays of items, and it retains each node's input and output so you can inspect them in the editor and so error handling works. The upshot: a large payload doesn't move through your workflow, it accumulates.

There's a second multiplier on top of that. Raw JSON expands when V8 parses it into live objects. A 1 MB JSON string does not become 1 MB of heap; it becomes several megabytes of objects, keys, and pointers, and the expansion is worse when the structure has many small nested objects rather than a few large ones.

Deeply nested webhook bodies with thousands of tiny records are the expensive shape.

Here's how a rough estimate works out in practice. Take your incoming payload size, assume roughly a 3x to 6x expansion in heap, then multiply by the number of nodes that carry that data forward.

Those numbers assume no filtering. If your second node trims 8,000 items down to 12, everything downstream stays small, though the fat original still sits in memory until the execution closes.

Does the number of nodes change how much RAM one active n8n webhook uses?

Yes, and more than most people expect. Node count matters because of retention, not because nodes are expensive objects themselves. Five Set nodes shuffling a tiny payload cost almost nothing.

Five nodes each carrying a 3 MB dataset cost you five copies of a 3 MB dataset.

The fix is ordering. Filter, limit, or aggregate as early as you can, ideally in the first or second node after the trigger. Cutting a 5,000-item array to 50 items in node two is far cheaper than doing the same work in node eight.

A fresh n8n install uses 150 MB to 400 MB before any webhook fires

n8n runs on Node.js, and the runtime plus the n8n backend, the task runner, and the editor API make up your floor. Self-hosters commonly report an idle container in the low hundreds of megabytes, and that number drifts upward with version releases as the codebase grows. If your server has 512 MB total, most of it is gone before you've received a request.

Two things sit on top of that floor. First, your database: SQLite runs inside the n8n process and keeps pages in memory, while Postgres runs separately and needs its own allocation, typically 100 MB to 300 MB for a small instance. Second, your active workflow cache, which is small but real.

The number people should actually plan around is the Node.js heap limit. Node derives a default maximum old-space size from the memory available to the process, and on a small VPS that ceiling can land lower than you'd guess. When an execution tries to exceed it, you get FATAL ERROR: Reached heap limit Allocation failed or a plain JavaScript heap out of memory, and the process dies mid-execution.

Setting it explicitly with NODE_OPTIONS=--max-old-space-size=1024 (value in MB) gives you a predictable ceiling instead of a surprise one. n8n's own self-hosting documentation covers this variable, and the flag itself is documented on the Node.js project site.

Note: raising the heap limit above your machine's physical RAM makes things worse, not better. Node will happily try to allocate what you told it it could have, and the Linux OOM killer will terminate the process without a useful error message. Keep the heap ceiling comfortably below total system memory, leaving room for the OS, your database, and anything else on the box.

What are the minimum server requirements for self-hosted n8n?

For light webhook traffic, one vCPU and 1 GB of RAM works, with the heap capped around 512 MB to 768 MB. 512 MB total is possible for hobby use with tiny payloads, and it's fragile: one unexpected bulk payload and the process restarts. If you're weighing whether your current plan can carry it at all, the signals for moving up a tier are the same ones that apply here.

Two vCPU and 2 GB is the comfortable starting point for real production use. Go to 4 GB once you're handling file uploads, running several workflows concurrently, or using Postgres on the same host. Check n8n's official docs for the current recommended specs, since these move with major releases.

Binary uploads, concurrency, and response mode push one webhook past 100 MB

Three settings account for most of the cases where a single webhook balloons.

Binary data mode. By default, n8n holds binary data in memory, which means a webhook receiving file uploads carries the whole file in the heap for the length of the execution, then again for every node that passes it along. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem writes binaries to disk instead and keeps only a reference in memory. On newer versions you can point it at S3-compatible storage.

This one change is the difference between a 20 MB upload costing you a few megabytes and costing you several hundred. It pairs well with sane upload ceilings on the sending side, so oversized files never reach n8n in the first place.

Concurrency. Everything above describes one execution. Ten simultaneous calls to the same webhook means ten executions, ten payloads, and ten sets of node data in the same process. Memory is per-execution and additive.

In main-process mode, n8n does not cap production concurrency by default, so a traffic spike can trigger an out-of-memory crash even when each individual run is small. N8N_CONCURRENCY_PRODUCTION_LIMIT sets a ceiling and queues the rest; check the current default for your version before relying on it.

Response mode. The Webhook node's Respond setting changes when the caller gets an answer, not when memory is released. With "Respond Immediately," the HTTP request closes fast, and the execution keeps running with all of its data resident. That's good for avoiding sender timeouts and it does nothing for RAM.

Watch for the pattern where a fast 200 response encourages the sender to fire more requests, stacking executions in the background.

Payload size caps

n8n limits the size of incoming request bodies through N8N_PAYLOAD_SIZE_MAX, which defaults to 16 MB. Anything larger is rejected before it becomes an execution. Lowering that value is a blunt but effective guard: if no webhook of yours should ever receive more than 2 MB, cap it there and let the sender get a clear error rather than letting your instance take the hit.

Measure your own per-webhook usage in about ten minutes

Estimates get you a server size. Measurement gets you the real answer for your workflow. This works on any Docker-based install and takes ten to fifteen minutes.

1. Open a terminal and run docker stats n8n (substitute your container name). Leave it running in that window so you can watch the memory column live.
2. Wait two to three minutes with no traffic and write down the idle figure. This is your baseline, and you need it because everything else is measured against it.
3. Deactivate every workflow except the one you're testing, so background schedules and polling triggers don't pollute the reading.
4. Send one realistic call to your production webhook URL with curl, using a real payload rather than a trimmed test body. Payload shape drives the result more than anything else.
5. Watch the peak value in docker stats during the execution, then subtract your baseline. The difference is what one active webhook execution costs you.
6. Repeat with five or ten concurrent calls to see how it scales. Multiply by your realistic worst-case burst to size the server.

Warning: run the concurrent test on a staging instance, not production. Deliberately stacking executions is how you find your out-of-memory ceiling, and finding it on a live box means killed executions and lost data.

Timing note: memory doesn't drop the instant an execution finishes. V8 releases heap on its own schedule, so give it 30 to 60 seconds after the run before reading the settled figure. A container that looks bloated straight after a big job is often fine a minute later.

Budget 1 GB for light traffic, 2 GB to 4 GB once payloads grow

Here's how the numbers translate into plans. Every row assumes n8n plus SQLite on one box, binary data on the filesystem, and an explicit heap limit.

Past that top row, throwing RAM at one process stops paying off. Queue mode is the structural answer: set EXECUTIONS_MODE=queue, add Redis, and run separate worker processes that pick executions off the queue. Each worker gets its own heap, so one memory-hungry execution kills one worker instead of your whole instance, and the webhook process stays responsive.

The trade-off is honest overhead. Every worker carries its own Node.js baseline of a couple of hundred megabytes, plus Redis. Queue mode on a 2 GB box usually performs worse than a single well-tuned process.

It starts making sense around 4 GB and up, or when uptime during heavy executions matters more than total efficiency.

Four changes cut n8n webhook memory the most

Move binary data out of the heap. Set N8N_DEFAULT_BINARY_DATA_MODE=filesystem. If your webhooks touch files at all, this is the highest-return change on the list, and it costs you nothing but disk. Take a recent restore point before you edit environment variables and restart, so a bad config doesn't cost you an afternoon.

Filter early. Put your Filter, Limit, or Aggregate node immediately after the trigger. Reducing 10,000 items to 100 in node two keeps every downstream node cheap. Doing it at the end means you paid full price the whole way through.

Batch with Loop Over Items. Instead of pushing 5,000 items through an HTTP Request node in one pass, loop in batches of 100 or 250. Peak memory drops to roughly one batch's worth plus overhead, and the run takes longer. That's usually the right trade for a webhook you don't have to babysit.

Split into sub-workflows. Move the heavy stage into its own workflow called by the Execute Workflow node, and return only the summary the parent needs. The bulky intermediate data becomes collectable once the sub-workflow returns, rather than sitting there until the parent finishes.

Two things that don't help, despite showing up in a lot of advice threads. Pruning execution history (EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE) saves database space and does nothing for runtime RAM. And restarting n8n on a cron schedule masks a specific leaky workflow instead of finding it; if memory climbs steadily across days rather than spiking per execution, hunt the workflow.

Things people get wrong about n8n webhook memory

Mix-up: adding more webhooks to an instance raises memory usage in proportion.

Reality: registrations are nearly free. Twenty idle webhooks and two hundred idle webhooks look almost identical in docker stats. Concurrent executions drive your memory curve, so ten busy webhooks cost far more than a hundred quiet ones.

Mix-up: webhook triggers use more RAM than polling or schedule triggers.

Reality: the trigger type barely registers. A Schedule Trigger that pulls 10,000 rows every five minutes uses vastly more memory than a webhook receiving a 1 KB event. What the workflow does with its data decides the cost.

Mix-up: an out-of-memory crash means the server is too small.

Reality: sometimes, and often it's an unset heap limit or in-memory binary data. Plenty of people move from 2 GB to 4 GB, keep the same defaults, and crash again at a slightly higher threshold. Set the heap ceiling and switch binary mode first, then judge whether you need more RAM.

Steady climbing that never comes back down points at a workflow problem, and the same diagnostic instinct applies to any server that keeps dragging for no visible reason.

What this means for your server

If you're running a handful of webhooks that receive small JSON events from Stripe, Slack, or a form tool, a 1 GB VPS handles it, and you should still set an explicit heap limit rather than trusting the default. That's the majority of n8n self-hosters, and it's the cheapest tier of any provider.

If your webhooks accept files, receive large API responses, or fan out into loops, plan on 2 GB to 4 GB and change the binary data mode on day one. The gap between a tuned 2 GB instance and an untuned 4 GB one is wide enough that config beats hardware here.

There's one practical detail worth sorting before you go live. Production webhooks need to be reachable over HTTPS, since most services refuse to send to plain HTTP, so get a certificate in place and point a subdomain at the instance before you paste the URL into anything. Doing that after the fact means updating every webhook URL you've already registered.

If you need somewhere to put it, a VPS with 2 GB of RAM covers most self-hosted n8n setups with room to grow, and Hostinger's plans sit at the affordable end for that spec. Check the current VPS pricing with code hHostCouponHub to see what the listed discount, up to 85% at the time of writing, brings the first term down to. Confirm the total at checkout, and note that renewal rates are higher than the introductory price.

Frequently asked questions

Is 512 MB of RAM enough to run self-hosted n8n with webhooks?

For hobby use with tiny JSON payloads and one or two active workflows, yes, if you cap the Node heap around 320 MB to 384 MB and keep binary data off. It leaves almost no headroom, so a single unexpected bulk payload or a burst of concurrent calls will crash the process. 1 GB is the smallest size worth trusting with anything you'd notice breaking.

How many active webhooks can one n8n instance handle?

Hundreds of registered webhooks are fine on modest hardware, because idle registrations cost kilobytes each. Your real limit is concurrent executions and the memory each one needs, which is why two teams with the same webhook count can need very different servers. Measure your heaviest workflow, divide your available heap by that figure, and you have your practical concurrency ceiling.

Does n8n use RAM when no workflows are running?

Yes. A self-hosted instance idles at roughly 150 MB to 400 MB depending on version, database choice, and how many workflows are cached, because the Node.js process, the editor API, and the task runner stay resident. That floor exists whether you have one webhook or fifty.

Should I add RAM or switch to queue mode?

Add RAM up to about 4 GB first, since a single tuned process is simpler to run and more memory-efficient than several. Move to queue mode when one heavy execution keeps taking down your whole instance, or when webhook response times suffer while big jobs run. Queue mode adds Redis plus a couple of hundred megabytes per worker, so it earns its place at scale rather than on a small box.

Getting the sizing right the first time

Pick your server based on your heaviest realistic execution rather than your webhook count, set the heap limit explicitly, and move binary data to the filesystem before you go live. If you're provisioning a box for this, Hostinger's VPS plans with the hHostCouponHub code are a reasonable place to start at the 2 GB tier, with room to scale up if your payloads grow.

This page contains affiliate links. If you purchase through the links on this page, we may earn a commission, at no extra cost to you.