How Many n8n Workflows Fit on a 4GB VPS? We Measured It

Hundreds, if they’re idle. Possibly five, if they aren’t.

The question is asked the wrong way round, so we installed n8n and measured what actually consumes memory. It isn’t how many workflows you have.

The baseline: what n8n costs before doing anything

We ran n8n 2.34.6 against Postgres 16, both in Docker, and let it settle:

That’s your floor on any box, with zero workflows. On a 4GB VPS it leaves roughly 3.5GB, minus whatever the OS takes — call it 3.2GB of actual headroom.

Workflow count barely matters

Here’s the measurement that reframes the question. We built a webhook workflow with a Code node and hammered it:

Two hundred executions cost 96MB. Going from sequential to fifty-at-once cost another 13MB.

Concurrency of small work is nearly free. The memory that accumulated is n8n’s execution bookkeeping, not a per-workflow tax — and a workflow sitting idle on a schedule costs essentially nothing, because it isn’t running. A hundred scheduled workflows that fire once an hour are cheaper than three that move files.

Payload size is what actually costs you

Same workflow, same instance, but with 10MB JSON bodies:

Three concurrent 10MB payloads cost more than two hundred trivial executions. That’s the whole answer to the sizing question: measure your data, not your workflow list.

The plateau at ten is garbage collection keeping pace rather than a ceiling — do not read it as “ten is free.”

The number that actually kills you

This is the finding we didn’t expect, and it’s the one that matters most.

While resident memory sat at 570MB, the container’s peak was 1,217 MB.

We pulled that from the kernel’s own accounting (memory.peak), and it’s more than double what docker stats was showing. Transient allocations during execution — parsing, copying, serialising — spike far above the steady state, and then get collected.

Your VPS is killed by the peak, not the average. A box that looks 60% idle in monitoring can OOM on a burst. Size for roughly double what your steady state suggests, which is why we’d not put a payload-heavy n8n on 2GB even when the graphs look fine.

Two ceilings you’ll hit before you run out of RAM

The 16MB payload cap. We sent progressively larger bodies to the same webhook:

n8n rejects request bodies over 16MB by default, and it fails as a server error rather than something obviously configuration-shaped. Raise it with N8N_PAYLOAD_SIZE_MAX — but understand you’re removing a guardrail that was protecting your RAM.

The V8 heap ceiling, which ignores your extra RAM. Node sizes its default heap from available memory, and we measured where it lands:

Look at the last row. Doubling the box from 4GB to 8GB does not give Node any more heap. It caps around 2GB and stays there.

This is why people upgrade their VPS and still get JavaScript heap out of memory. The fix isn’t more RAM — it’s telling Node to use it. Setting --max-old-space-size=3072 on that same 4GB container raised the limit to 3,120 MB, which we confirmed directly. If you’re on 8GB or above and hitting heap errors, this flag is your problem.

The sizing table

Combining the measurements with the peak-versus-resident gap:

4GB is the right default, and the reason isn’t the average — it’s that the peak runs to roughly double the steady state.

The three settings that reduce memory most

1. Move binary data off the heap. n8n’s documentation is explicit: “When handling binary data, n8n keeps the data in memory by default.” Set N8N_DEFAULT_BINARY_DATA_MODE=filesystem and it writes to disk instead. This is the single highest-impact change for any workflow touching files.

The trap: n8n does not support filesystem binary storage in queue mode. If you scale to workers, you need S3-compatible storage — so if queue mode is in your future, go to S3 directly rather than migrating twice.

2. Stop saving execution data you’ll never read. Pruning is on by default, but the volume saved isn’t. EXECUTIONS_DATA_SAVE_ON_SUCCESS=none keeps error data and discards the rest — and EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT control retention.

Also set EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false. Per n8n’s docs, “manual executions increase memory consumption as n8n makes a copy of the data for the frontend” — testing a workflow in the editor costs roughly double what running it costs.

3. Cap worker concurrency in queue mode. Queue mode moves execution to separate Node processes coordinated through Redis. It doesn’t reduce total memory — it distributes it, and lets you cap how many executions run at once. Reach for it when one process can’t hold peak concurrency, not because you have a lot of workflows.

One more, if you write JavaScript: n8n names the Code node as memory-heavy. A Code node that builds an array of everything before returning holds all of it at once — batch through a sub-workflow and only the current batch stays resident.

What to run it on

Hetzner — the traditional value answer, though check the price before assuming: after the 2026 repricing its 4GB CPX22 is €19.99 (~$21.59) and the cheap tier has been unavailable. Dedicated-vCPU CCX line if your workflows are CPU-bound rather than memory-bound.

Hostinger — $11.99 renewal for 4GB and $14.99 for 8GB, with a one-click n8n template. The cheapest way to the 4GB tier this article recommends, and the $3 step to 8GB is the best-value upgrade here — just remember 8GB does nothing for the heap unless you set the flag.

DigitalOcean — $24 for 4GB, the most expensive of the self-managed options, bought for documentation and predictable APIs. Its Spaces object storage is a tidy answer to the S3 binary-data requirement if you’ll run queue mode.

Cloudways — from $11 for 2GB billed monthly, managed on top of DigitalOcean or AWS. Note its published support scope excludes debugging custom code, so a misbehaving Code node is yours regardless.

Railway — no server to manage, but it bills per second of resource residency and n8n is resident by definition. We priced that against a flat VPS; the convenience is real and so is the premium.

Once you’ve picked, the Docker Compose setup is the next step, and what n8n actually costs to self-host has the full running figures.

How we checked this

Every memory number here is measured, not estimated. We ran n8n 2.34.6 with Postgres 16 in Docker on 18 August 2026, created a webhook workflow with a Code node through n8n’s REST API, activated it, and drove load with curl while sampling docker stats. The 1,217 MB peak is from the container’s cgroup memory.peak counter, and the V8 heap limits from v8.getHeapStatistics().heap_size_limit inside containers started with explicit -m limits.

The important caveat: this was one workflow shape on one machine. A webhook plus a Code node returning a small object is a deliberately simple case. Your workflows will differ — more nodes, heavier nodes, database queries, LLM calls — and the numbers will move. Treat these as the shape of the curve, not as your capacity.

The host machine has 30.6GB of RAM and the containers were unconstrained during the load tests, which is why the V8 heap limit read 4,288 MB there. That’s not what you’d get on a 4GB VPS — which is exactly why we measured the limits separately at 2GB, 4GB and 8GB, and those figures are the ones in the table.

We did not test on any provider’s VPS. No Hetzner, Hostinger, DigitalOcean, Cloudways or Railway instance was involved. A real VPS would show worse numbers than a workstation — slower disk, less cache, CPU steal — so treat the sizing table as a floor.

The 200-execution figure is cumulative, not per-execution. Memory rose 96MB across 200 runs and did not return to baseline during our test window; we did not run long enough to characterise where it settles, so we’re not claiming a steady-state figure for a long-running instance. The plateau at ten concurrent 10MB payloads is likewise a single observation, not a demonstrated ceiling.

The 16MB payload cap was established by bisection — 15MB succeeded, 17MB returned 500 with PayloadTooLargeError in the logs — which is consistent with n8n’s documented default. We did not test raising it.

The configuration guidance is from n8n’s own documentation, read the same day: the binary-data-in-memory default and filesystem mode, the queue-mode incompatibility with filesystem storage, the execution-data pruning variables, the manual-execution copy behaviour and the Code node’s memory profile. We verified the behaviour of none of those settings ourselves — we measured the defaults and are reporting the vendor’s fixes.

One incidental finding: in n8n 2.x, activating a workflow through the API requires passing the current versionId. It cost us a few attempts, and it’s a change worth knowing if you automate deployments.

What we did not do: run a multi-day soak test, test queue mode with real workers, measure binary data in filesystem or S3 mode, or benchmark any provider’s hardware.

The host links above are affiliate links. The article’s recommendation is 4GB rather than the larger box, and it points out that paying for 8GB does nothing for your heap unless you change a flag that costs nothing.

FAQ

How many n8n workflows can a 4GB VPS handle?

Hundreds, if they’re idle or move small payloads — 200 executions cost us 96MB. But three concurrent 10MB payloads cost more than those 200 executions combined. Concurrency and payload size determine the answer, not workflow count.

How much RAM does n8n use at idle?

We measured roughly 300–350MB for n8n 2.34.6 plus 45–50MB for Postgres — about 400MB before running anything.

Is 2GB enough for n8n?

For light API-calling workflows with small JSON, yes. Not for files: the V8 heap limit at 2GB is only about 1GB, and peak memory during execution runs to roughly double the resident figure.

Why does n8n run out of memory even on a big server?

Node’s default heap limit stops growing at around 2GB. We measured 2,096MB on both a 4GB and an 8GB container — identical. Set --max-old-space-size to use the RAM you paid for.

What’s the biggest payload n8n accepts?

16MB by default. We confirmed 15MB succeeds and 17MB returns a 500 with PayloadTooLargeError. Raise it with N8N_PAYLOAD_SIZE_MAX, understanding that the cap was protecting your memory.

What single setting saves the most memory?

N8N_DEFAULT_BINARY_DATA_MODE=filesystem, if your workflows touch files — n8n keeps binary data in memory by default. Note it isn’t supported in queue mode, where you need S3-compatible storage instead.

When do I need queue mode?

When a single process can’t hold your peak concurrency. It distributes memory across worker processes and lets you cap concurrent executions — it doesn’t reduce the total, and having many workflows isn’t itself a reason.

Why does testing a workflow use more memory than running it?

n8n copies the execution data for the editor frontend during manual runs. Setting EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false avoids persisting it.