n8n Concurrency Limits by RAM Tier: How Many Can You Run?

n8n publishes no concurrent execution limit by RAM tier, and that catches a lot of self-hosters off guard. What you get instead is one setting, N8N_CONCURRENCY_PRODUCTION_LIMIT, which defaults to -1 (unlimited) on self-hosted instances, so the real ceiling comes from your server's RAM and how heavy a single workflow run is. As a planning starting point in regular mode, a 1 GB box copes with roughly 3 to 5 light concurrent executions, 2 GB with about 8 to 10, 4 GB with around 15 to 20, and above that you're better off switching to queue mode and splitting the load across worker containers.

Those figures assume small JSON payloads and no binary files sitting in memory, because one workflow pulling a 50 MB PDF can eat the entire budget by itself. Measure your own per-run usage before you lock in a number.

n8n gives you one concurrency setting, and the default is unlimited

The setting is N8N_CONCURRENCY_PRODUCTION_LIMIT, and you pass it as an environment variable. Set it to a positive integer and n8n caps how many production executions run at the same time. Leave it at -1 and there's no cap at all on a self-hosted instance.

Concurrency control arrived during the n8n 1.x line, so if you're on an older build the variable won't do anything. Check your version in the UI footer before you spend an evening debugging a setting that isn't in your release yet. n8n's self-hosting documentation lists the current environment variables and their defaults.

What counts toward the limit matters more than the number itself. Production executions are the ones fired by webhooks, schedule triggers, app triggers, and other live workflows. When the cap is reached, new production runs don't fail.

They wait in line and start as soon as a slot frees up, and the editor shows a banner telling you the queue is backed up.

Note: manual executions you fire from the editor's Test workflow button are not counted against the production concurrency limit. Those are often the heaviest runs you'll do, because you're usually debugging something big, so a "safe" limit of 5 can still tip a 1 GB server over while you're testing.

There's a second thing to keep straight. On n8n Cloud, the concurrency number is fixed by your plan and you can't raise it with an environment variable. Self-hosting is where you own the decision, which is also why sizing the box correctly falls on you.

RAM per execution is the number that actually sets your ceiling

Server RAM is not execution RAM. Before a single workflow runs, you're already spending memory on the Linux host, the n8n main process, your database, and Redis if you're in queue mode. On a typical Docker setup with Postgres on the same box, I'd reserve somewhere between 500 MB and 700 MB before counting any executions.

Whatever's left gets divided by the peak memory of one execution. Light workflows moving a few dozen JSON items usually sit in the tens of megabytes. Anything touching binary data, big API responses, or thousands of items can run several hundred megabytes on its own, because n8n holds the output of each node in memory for the duration of the run.

So the working formula is straightforward: (total RAM minus fixed overhead) divided by peak RAM per execution, then knock 20 to 30 percent off the result as headroom.

Here's how that plays out across common VPS sizes. Treat these as planning figures to start from, not vendor specs:

The gap between those last two columns is the whole reason a single RAM tier chart can't be handed down from n8n. Two people on identical 4 GB servers can have wildly different safe limits depending on what their workflows carry.

How to measure your own per-execution memory footprint

1. Start your n8n container with nothing running and note the idle memory with docker stats. That's your baseline overhead.
2. Trigger one production run of your heaviest real workflow and watch the peak figure during the run, not the value after it finishes.
3. Subtract the baseline from the peak. That difference is your per-execution cost for that workflow.
4. Divide your free RAM by that number, drop 25 percent for safety, and set N8N_CONCURRENCY_PRODUCTION_LIMIT to the result.

Do this with the workflow you'd least like to see crash, not the tidy little one that posts to Slack. And if you're running several very different workflows, size against the worst offender. It's the same logic behind picking the moment a shared plan stops coping and moving to a VPS: plan for the peak, not the average.

Tier by tier: what each RAM size can realistically run

1 GB RAM

This is the tier where people get burned. n8n will install and boot on 1 GB, and a couple of simple schedule triggers will run fine for weeks. Then a webhook burst arrives, three executions overlap, and the Node process runs out of heap.

Set the limit to 3 and add swap. Keep the database off the box if you can, or stick with SQLite, since Postgres on the same 1 GB machine will fight n8n for memory. Skip anything involving file downloads, image processing, or spreadsheet parsing at this tier.

2 GB RAM

This is the smallest size I'd actually recommend for a self-hosted n8n instance doing real work. A limit of 8 is comfortable for JSON-only workflows, and you've got room for Postgres alongside it.

Two GB also gives you enough slack to survive a bad day. If one execution balloons unexpectedly, you have a few hundred megabytes of cushion before the OOM killer steps in.

4 GB RAM

The sweet spot for most single-instance setups. A limit of 15 to 20 works for light workflows, and you can handle moderate binary work if you move binary data to disk (covered further down).

Four GB is also the point where regular mode starts to become the bottleneck rather than RAM. All those executions share the same Node process and the same event loop, so CPU-heavy nodes will queue behind each other regardless of free memory.

8 GB RAM

At 8 GB, stop raising the single-process limit and switch to queue mode. Run the main process for webhooks and the UI, Redis for the queue, and two or three worker containers. Total throughput climbs well past what one process manages, and a crashed worker no longer takes your webhook listener with it.

16 GB and above

This tier is about worker count and database performance, not the concurrency variable. Four workers at a limit of 10 each gives you 40 concurrent slots with genuine process isolation. Your bottleneck moves to Postgres write throughput and whatever external APIs you're hammering, both of which will complain before RAM does.

Queue mode changes the math because the limit applies per worker

In queue mode, N8N_CONCURRENCY_PRODUCTION_LIMIT is applied to each worker separately, not to the instance as a whole. Three workers with a limit of 10 each means up to 30 concurrent executions. Get this wrong and you'll size a 4 GB server for 10 runs and accidentally allow 30.

Workers also accept a --concurrency flag on the command line, which defaults to 10. Whichever mechanism you use, the arithmetic is the same: multiply per-worker concurrency by worker count, then check that total against your available RAM.

Every worker is a separate Node process with its own base overhead, which is the cost of the isolation you're buying. Two workers use noticeably more idle memory than one, so queue mode on a 2 GB box usually performs worse than plain regular mode. Queue mode earns its keep from 4 GB up, and really from 8 GB.

Redis needs its own allocation too. It's light for queue duty, but it isn't free, and it's another process competing for the same pool. Whatever you build here, write the container layout and variables down somewhere; the same discipline behind keeping decent setup notes saves hours when you rebuild the stack six months later.

Cutting RAM per execution raises your limit without buying more RAM

Before you upgrade the server, shrink what each run costs. These are the changes with the biggest payoff.

Move binary data out of memory. Set N8N_DEFAULT_BINARY_DATA_MODE=filesystem and n8n writes binary payloads to disk instead of holding them in the Node heap. There's an S3 option as well. On any workflow touching PDFs, images, or CSV files, this single variable can be the difference between a limit of 3 and a limit of 15.

Cap the payload size. N8N_PAYLOAD_SIZE_MAX sets the largest request body n8n accepts, with a 16 MB default. Lowering it stops one oversized webhook from blowing through your memory budget. Same thinking applies to what you allow users to upload in the first place, which is worth checking against sensible upload ceilings on your host.

Batch your loops. A Split In Batches node processing 200 items at a time uses a fraction of the memory of one node handling 20,000 rows in a single pass. This is the most common fix for workflows that die on large data sets.

Stop carrying data you don't need. Every node's output stays in memory until the execution ends. Drop unused fields early with a Set or Edit Fields node, and turn off "Always Output Data" where you don't need it. Trimming a 40-field record down to 5 fields at step two cuts the cost of every step after it.

Raise the heap ceiling if the box has room. Node.js limits how much heap a process can claim, and the default is tied to the memory the container sees. You can raise it with NODE_OPTIONS=--max-old-space-size=2048 for a 2 GB heap. The Node.js project documents the flag.

Never set it higher than your actual free RAM, or you've traded a clean n8n error for the kernel killing the container.

Prune old execution data. EXECUTIONS_DATA_PRUNE with a max age keeps the database from bloating. This is disk and query speed rather than RAM, but a slow database makes concurrent executions hold memory longer, so it feeds back into the same problem. Keep a restore point too, and know how long your snapshots stick around before you start editing production variables.

n8n Cloud fixes the limit for you, self-hosting hands you the dial

On n8n Cloud, concurrency is set per plan and the number goes up as you move to a bigger tier. You can't override it with an environment variable, and the infrastructure sizing is handled for you. n8n changes plan details periodically, so check the official pricing page for the current per-plan concurrency figures rather than trusting a number you read in a forum thread.

Self-hosting has no license-side cap. The community edition will attempt as many concurrent executions as you tell it to, right up to the point where the process dies. That freedom is the appeal and the trap in equal measure.

For webhook-driven work, self-hosting also means handling your own HTTPS and DNS. Most people run n8n on a subdomain, and pointing a subdomain at the instance plus a valid certificate is part of the setup. If you're unsure what's included with your plan, the certificate options on your host are worth confirming first, because webhook providers reject endpoints with certificate errors.

Common mix-ups about n8n concurrency limits

Mix-up: A higher concurrency limit means more work gets done per hour.

Reality: Concurrent executions share the same CPU and memory. Past a certain point, raising the limit slows every run down and increases the chance of an out-of-memory crash that kills all of them at once. Throughput often peaks at a lower limit than people expect.

Mix-up: Setting the limit protects the instance from every kind of overload.

Reality: It counts production executions only. Manual test runs from the editor sit outside the cap, and they're frequently the heaviest thing on the box. Sub-workflow behaviour is worth verifying in the docs for your version before you rely on the number being exact.

Mix-up: The RAM figure on a hosting plan is the RAM n8n gets to use.

Reality: The OS, your database, Redis, and the idle n8n process take their cut first. On a 1 GB plan, you might have 400 MB left for actual executions. Anyone who has chased down sluggish server performance on an undersized box knows how quickly that shortfall shows up.

What this means for your setup

If you're picking a server today, start at 2 GB and set the production limit to 8. That combination survives normal traffic, leaves room for a manual test run, and costs very little. Move to 4 GB the moment you add binary data handling or your workflows start returning thousands of items.

If you already have a running instance, the useful next step is measurement, not guesswork. Fifteen minutes with docker stats and your three busiest workflows tells you more than any RAM tier table can, including this one. Then set the limit from your own numbers and leave a quarter of the memory unallocated.

The thing worth remembering: the n8n concurrent execution limit by RAM tier is a decision you make once and then verify against real load. Automation workloads grow quietly. A workflow that handled 50 records at launch handles 5,000 a year later, and the limit that fit then won't fit now.

Running n8n needs a VPS with root access, so shared hosting is off the table. Hostinger's VPS range starts at plans with enough RAM for a small n8n instance and scales into the 8 GB and 16 GB territory queue mode wants, and the coupon code hHostCouponHub takes up to 85% off through this Hostinger VPS link.

Frequently asked questions

How much RAM does n8n need to run?

n8n will boot on 1 GB, but 2 GB is the realistic minimum for production use with a database on the same server. Budget 4 GB if your workflows handle files, images, or large data sets, since binary data held in memory is the single biggest driver of per-execution RAM.

What happens when n8n hits the concurrency limit?

New production executions are held in a queue and start automatically as slots free up, so nothing is dropped. The editor displays a banner showing the backlog. Manual executions triggered from the editor are not counted against the limit and will still run.

Why do I get "JavaScript heap out of memory" errors in n8n?

That error means the Node process exceeded its heap ceiling, usually because too many executions overlapped or one workflow held a very large data set in memory. Fix it by lowering N8N_CONCURRENCY_PRODUCTION_LIMIT, setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem, batching large loops, and raising --max-old-space-size only if the server has spare RAM.

Should I raise the concurrency limit or add another worker?

Below 4 GB, raise the limit. At 4 GB and above, add workers in queue mode instead, because separate processes give you crash isolation and use multiple CPU cores. Remember the limit applies per worker, so three workers at 10 each means 30 concurrent slots.

Size the server for your heaviest workflow, set the limit from measured numbers, and give yourself room to grow into queue mode later. If you're spinning up a fresh instance, the VPS plans behind this discounted Hostinger link with code hHostCouponHub cover everything from a 2 GB starter box to the RAM you'll want once workers enter the picture.

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.