n8n System Requirements: 5 Real Tests and Where It Crashes

Tested by M. Aziz, backend engineer at Selfhost.dev · n8n 2.40.7 (Node.js 26.7.0 in the image) on Selfhost.dev servers in Falkenstein, Germany

Ask five sources what server n8n needs and you get five answers: 1 vCPU or 2, 1 GB or 8. So we measured it. n8n system requirements are set by memory, not CPU. n8n 2.40.7 idled at 394 MiB with its task runner, and its main process ran every test workflow inside a 1 GB memory limit. At 512 MB, five Code nodes running at once crashed it in a loop.

You’ll leave with a server size, the point where n8n breaks, and the setting that wastes the most RAM. Every number comes from five test workflows run on Selfhost.dev servers.

Key Facts

• Idle RAM: n8n 2.40.7 uses 394 MiB on SQLite and 391 MiB on Postgres, plus 4 MiB for its task runner.
• Minimum memory requirement: A 1 GB limit on n8n’s main process ran every test workflow, with the task runner unlimited. At 512 MB, five parallel Code runs caused a crash loop due to JavaScript heap out of memory.
• 4 GB server performance: A 2 vCPU / 4 GB server peaked at 2.2 GiB with five parallel Code runs and successfully handled all 1,201 requests during a one-minute test at 20 requests per second.
• CPU scaling: Increasing CPU from 2 to 4 vCPU nearly doubled light-workflow throughput, from 10.9 to 20.8 runs per second. Increasing from 4 to 8 vCPU added only 4%.
• Binary data configuration: Setting N8N_DEFAULT_BINARY_DATA_MODE=default made a 50 MB file workflow use 75% more RAM and run four times slower.

n8n system requirements at a glance

n8n’s system requirements come down to three sizes: 1 GB for n8n’s main process, 2 vCPU / 4 GB for small production, and 4 vCPU / 8 GB for heavy work.

On a 2 vCPU / 4 GB server, the one-click template passed every test. The whole server peaked at 2.2 GiB with five parallel Code runs, and at 1.74 GiB during a 1-minute run at 20 light requests a second.

n8n’s hosting requirements go beyond size: our n8n hosting providers compared at 4 GB show which set up HTTPS and webhooks for you.

What most n8n requirements guides get wrong

Four figures that n8n requirements guides repeat (100 MB idle, Node.js 16, a 2 GB minimum and 1 vCPU to start) don’t match our tests on n8n 2.40.7.

Does n8n publish official system requirements?

No. n8n’s docs give no hardware minimum for self-hosting. Its only sizing table is on the OEM prerequisites page, which says the figures “are an example based on n8n Cloud and are for illustrative purposes only”.

The 100 MB figure comes from the same page: “an n8n Cloud instance at idle requires ~100MB”. That describes n8n Cloud, not a self-hosted n8n 2.x with its task runner.

n8n’s performance docs report up to 220 executions a second on one 4 GB instance, for a two-node workflow (Webhook Trigger and Edit Fields) on Postgres. Our light workflow, W1, also makes an outbound HTTP call on every run, and topped out near 21 a second. n8n’s own scalability benchmark measured 16.2 requests a second in single mode. Throughput depends on what the workflow does, so treat any single number, ours included, as specific to its workflow.

How we measured

We ran n8n 2.40.7 (n8nio/n8n:2.40.7 + n8nio/runners:2.40.7, Node.js 26.7.0 inside the image) with the same settings as the Selfhost.dev’s one-click n8n template: SQLite, an external task runner, N8N_RUNNERS_MAX_CONCURRENCY=5. Postgres runs used postgres:16-alpine.

Three terms below: n8n main is the main n8n container, the task runner is the container that runs Code nodes, and the whole server is everything on the box. Memory is shown in binary units (MiB, GiB) as measured; server sizes and disk are in GB.

• RAM and CPU: read from each container’s cgroup v2 counters every second (memory.current, memory.peak, cpu.stat), for n8n main, the task runner and Postgres separately. Platform containers (the reverse proxy and deploy agent) are left out.
• Load: k6 v0.43.1 from a separate machine in India.
• Clean starts: each workload’s RAM peak comes from a fresh instance, because n8n keeps memory between runs.

Limits of these tests:

• Results are for n8n 2.40.7; other versions may differ.
• All vCPUs were shared, not dedicated.
• 2 GB, 1 GB, 512, 384 and 256 MB are container memory limits (mem_limit, swap off) on the 16 GB server, not real servers. In those tests only n8n main was limited; the task runner was not.
• 1 vCPU, and real 1 GB and 2 GB servers, were not tested.
• Response times include about 150 ms of network from India. RAM and CPU are not affected.
• W5 used one free cloud model; other models and tools may use more.

The five test workflows (exported JSON and the load script are in [REPO LINK: add before publishing, see DRAFT NOTES]):

W5 used OpenRouter’s free nvidia/nemotron-3.5-lightning:free model through n8n’s OpenAI credential with a custom base URL, on the 4 vCPU / 8 GB server. Its run time (median 7.4 s) is the model provider’s, not n8n’s.

How much RAM does n8n need?

n8n’s RAM requirements start at about 400 MiB idle and reach 1.7 GiB for the heaviest single workflow we ran. Size for your heaviest workflow’s peak, not the idle number.

n8n memory usage at idle

Sampled for 3 minutes on a fresh instance, n8n 2.40.7 idled at 394 MiB on SQLite and 391 MiB on Postgres, plus 121 MiB for Postgres itself. The task runner sat at 4 MiB: it only starts runner processes when a Code node runs. During startup (database migrations), n8n main briefly peaked at about 720 MiB.

RAM per workload

Files and large payloads drive memory up; workflow count barely does. Each workflow ran 10 times, one at a time, on a fresh instance (16 GB server, no limits):

• A light workflow adds about 20 MB over idle. A 20 MB JSON response adds about 360 MB, roughly 18 times its size.
• One 50 MB file adds about 560 MB in n8n 2.x’s default filesystem mode, and 1.3 GB if binary data is kept in memory.
• An AI Agent run with a cloud model added about 160 MiB to n8n main and averaged 5% CPU: n8n mostly waits for the model. Five agents in parallel peaked at 467 MiB, with all 20 runs successful.

n8n does not hand memory back after heavy runs. After a sequence of the runs above, n8n main sat at 1.6 GiB when idle, up from 394 MiB fresh. If your n8n’s memory climbs after big workflows and stays there, ours did too.

Binary data mode

Where n8n keeps files decides a file workflow’s RAM. When N8N_DEFAULT_BINARY_DATA_MODE is unset, n8n 2.40.7 stores binary data on the filesystem (in the database in queue mode, as the binary data config in n8n’s source shows). Older guides and setups still set it to default, which keeps files in memory.

For W4, in-memory mode cost 75% more RAM (1,663 vs 949 MiB) and made runs four times slower (1.97 vs 0.51 s median). With 5 runs in parallel, filesystem mode handled 3.65 runs/s against 0.58. n8n 2.40.7 logs that in-memory default mode will be removed in a future version, so if your setup sets it, remove the variable.

Concurrent runs

More parallel Code runs cost more memory but stopped adding speed after five. W2 (Code nodes over 10,000 items) with more runs in parallel:

n8n accepts more executions than its task runner works on at once; with the template’s cap of 5, extra executions wait their turn. At 20 parallel runs, n8n main and the runner together used about 2.3 GiB. Throughput stopped growing after 5 because the template caps the task runner at 5 concurrent tasks (N8N_RUNNERS_MAX_CONCURRENCY=5); the extra runs only queued, and the median run took 10.9 s. The 20-run row followed earlier runs on the same instance, so its peaks include some retained memory.

On our 4 GB test server, the OS, the platform and idle n8n took 1.47 GiB, which leaves about 2.5 GB for your heaviest workflow’s peak. That 2 vCPU / 4 GB server is $0.02 an hour in our EU locations, and the n8n template adds nothing to the bill. Price a 2 vCPU / 4 GB n8n server, no signup

n8n minimum requirements: finding the memory floor

n8n 2.40.7 needs 1 GB for its main process to survive parallel Code runs, and about 384 MB for light workflows and single file runs in its default binary mode. We limited the n8n main container to each size (task runner unlimited, swap off) and ran the same workflows. The task runner used up to 502 MiB during five parallel Code runs, so budget for it on top:

At 1 GB the 50 MB file pushed n8n main exactly to 1,024 MiB. It finished, but runs took 3.3 to 5.8 s instead of 2.3 s at 2 GB as the kernel reclaimed memory.

The “n8n 2.x default” column leaves N8N_DEFAULT_BINARY_DATA_MODE unset, so files go to the filesystem; each limit ran on a fresh instance with only W4, three runs each. In that mode a 50 MB file ran even at 384 MB (median 0.44 s), with n8n main pinned at the limit.

The “in memory” column sets the mode to default. Its 512 and 384 MB rows failed because n8n was still crash-looping from the W2 run before, so the file itself was never tested there. The W3 rows at 512 and 384 MB failed the same way.

JavaScript heap out of memory: the exact errors

At 512 MB and 384 MB, five parallel Code runs killed n8n main with:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Every request in that run failed. n8n then restarted, logged Last session crashed, reached n8n ready, and ran out of heap again about 20 seconds later:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

It was still crash-looping minutes later, so the next workflows failed instantly. Back with enough memory, its executions list showed the in-flight runs as Crashed (5 of 5 when we reproduced it). Runs still waiting never started and left no record.

At 256 MB n8n never became ready. The first boot ran all database migrations, then the process was killed with no error line. It restarted 22 times in 7 minutes, each time logging only Last session crashed and Initializing n8n process.

A kill from the kernel leaves no log, so a box that is simply too small looks like a silent restart loop.

Node heap limit

Node sizes its JavaScript heap from the container: in the 512 MB container the heap filled at about 247 of 258 MB, roughly half the limit. You can set it yourself with NODE_OPTIONS=--max-old-space-size=<MB>. In a 1 GB container:

The W4 column ran with binary data in memory (default mode); n8n 2.x’s default filesystem mode was not tested under a heap limit.

A heap limit set too low crashes n8n with plenty of RAM free: n8n died at 585 MiB with 440 MB of the container unused. Raising it fixes heap crashes, but a heap close to the container size only moves the crash: the kernel kills the process instead, without the heap out of memory line. Raise the server’s RAM and the heap limit together.

Does n8n need more CPU?

For a single n8n instance, 4 vCPU handled nearly twice as many light webhook runs as 2 vCPU in our tests, and 8 vCPU added only 4% more. We limited n8n main and the task runner to 2, 4 and 8 vCPU on the same server. On fresh instances we ran two loads: a burst of light webhooks (W1 at 50 requests/s for 1 minute) and Code-heavy work (W2, 10 runs in parallel, 60 in total).

These are overload numbers. When 50 requests arrive every second, requests start piling up faster than n8n can process them. That backlog slows the system down. Below that limit, a server performs better.

At a steady 20 light requests per second, both server sizes handled the workload without dropping requests:

• 2 vCPU / 4 GB: Answered all 1,201 requests in one minute, with a median response time of 248 ms and a p95 of 1.4 s.
• 4 vCPU / 8 GB: Also answered all 1,201 requests, with a median of 187 ms and a p95 of 299 ms.

Adding CPU cores helps, but only up to a point. For light workflows, moving from 2 to 4 vCPU doubled what n8n could handle. Going from 4 to 8 vCPU added just 4%.

In the 8 vCPU burst, n8n main averaged 330% CPU usage. Workflows run on a single Node.js event loop, but garbage collection, I/O and database operations can use other cores. That’s why adding a second pair of cores still helps, even though workflow execution itself runs on one event loop.

Code-heavy workloads behaved differently. Throughput barely changed as we added CPU because the task runner never used more than about 1.8 cores. The template caps it at five concurrent tasks, which limits how much additional CPU it can use.

CPU starvation can also turn into a memory problem. During the 2 vCPU overload test, waiting requests piled up and pushed n8n main’s memory usage from 402 MiB to 3.4 GiB. We did not run that burst on a 4 GB server, but 3.4 GiB is already more than the memory available after accounting for the OS and platform.

When does adding more CPU stop helping? With W1, which makes an outbound HTTP call on every run, one instance topped out at around 21 runs per second on 4 cores. Beyond that point, adding more cores won’t solve the bottleneck. That’s when queue mode becomes relevant.

Disk: how fast n8n’s database grows

What a workflow carries decides disk growth: a light run adds about 10 KB to the SQLite database, and a 50 MB file run adds 50 MB. Growth per execution, with n8n’s default of saving successful executions:

At 1,000 light runs a day, expect about 0.3 GB a month on SQLite without pruning; at 1,000 Code-heavy runs a day like W2, about 54 GB a month.

Not saving successful executions cut W2’s growth from 1.8 MB to 10 KB per run and made it 30% faster (2.41 vs 1.86 runs/s). For light workflows it changed nothing: the roughly 10 KB per run is written either way.

With saving off, n8n still writes each execution when it starts and soft-deletes it when it succeeds, and adds 4 rows per run to its insights_raw table. The pruning job removes the soft-deleted rows later.

With binary data kept in memory, a 50 MB file costs 73 MB per saved execution, about 1.4 times its size, because it is stored inside the execution record.

Pruning

n8n prunes old executions by default: EXECUTIONS_DATA_PRUNE=true, EXECUTIONS_DATA_MAX_AGE=336 (hours, 14 days), EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 (the defaults in n8n 2.40.7’s source). Soft-deleted executions are purged after a further buffer, EXECUTIONS_DATA_HARD_DELETE_BUFFER=1 (hour).

That cap matters for Code-heavy work: 10,000 saved runs at 1.8 MB each is about 18 GB. With pruning off, the same workload fills a 40 GB disk in under a month, and SQLite stops with the SQLITE_FULL error.

Whether a SQLite file shrinks after pruning without a vacuum (DB_SQLITE_VACUUM_ON_STARTUP) was not measured. n8n’s guide to managing execution data says SQLite reuses freed space rather than releasing it, unless you vacuum.

Images and logs

The amd64 images are about 540 MiB to download: n8nio/n8n:2.40.7 254 MiB and n8nio/runners:2.40.7 177 MiB compressed, plus 110 MiB for postgres:16-alpine if you use it. Unpacked they take about 1.6 GB on disk (1.03 GB, 535 MB and 288 MB, measured on arm64). Log growth was not measured.

n8n SQLite vs Postgres: what changes in resources

Postgres costs 120 to 300 MiB of extra RAM and saves disk on heavy workflows; n8n main used the same memory on both.

Postgres stored Code-heavy execution data in less than half the space SQLite used, possibly because it compresses large rows.

Light runs behaved differently. Postgres disk usage grew in steps as it allocated new write-ahead log (WAL) files. That makes per-run growth figures below a few MB unreliable.

We also tested SQLite under load. It did not return a database is locked error in any run, including tests with 20 parallel executions.

When should you switch to Postgres?

Switch when you need queue mode (which requires Postgres), when execution data grows to several GB, or when you want to take backups without stopping n8n. If you run both on the same server, budget about 300 MiB of RAM for Postgres.

Setting up Postgres for n8n means running a second container, creating a database user, and configuring environment variables before the first boot. Our n8n with Postgres template handles that setup on the same server.

See n8n with its own Postgres 16 database, connected before first boot

Already decided? Deploy it with the $5 welcome credit, no card required

n8n software requirements

n8n 2.40.7 needs Docker with Compose, or Node.js 24+ for an npm install:

• Docker image: n8nio/n8n:2.40.7 ships Node.js 26.7.0. The “Node.js 16 or higher” figure in some guides is long out of date.
• Task runner: a second image, n8nio/runners:2.40.7, runs Code nodes in a separate container (see n8n’s task runners guide). n8n 2.40.7 logs that N8N_RUNNERS_ENABLED is no longer needed.
• Node.js for an npm install: Node.js 24 or newer (n8n 2.40.7’s package.json says “node”: “>=24.0.0”).
• Docker / Compose: Docker Engine 28.5.2 with the Compose plugin 5.6.1 on the Selfhost.dev servers we tested.
• OS: Ubuntu 24.04 LTS with kernel 6.8.0 (the Selfhost.dev server image).
• CPU architecture: both n8n images are published for amd64 and arm64.

n8n hardware requirements by workload

n8n’s server requirements follow the workload: 2 vCPU / 4 GB covers most single-instance setups, and 4 vCPU / 8 GB suits bursts of traffic or many parallel Code runs. Each row points to a measurement above. The server rows were checked with the one-click template, where the platform, OS and n8n together used 1.47 GiB at idle.

All rows assume n8n 2.x’s default filesystem binary mode; setting N8N_DEFAULT_BINARY_DATA_MODE=default adds about 1.3 GB per 50 MB file in flight. No row needs a GPU. Running local AI models with Ollama on the same server needs much more RAM.

To compare these sizes with n8n Cloud’s execution plans, see what running n8n on your own server costs.

Both server sizes in this table are one-click n8n servers in Europe: 4 GB for $15.18 a month and 8 GB for $23.36, with every execution included. Compare the 4 GB and 8 GB n8n servers side by side

Field notes: what surprised our engineer

1. Idle was four times what I expected. Every guide says about 100 MB. A fresh n8n 2.40.7 sat at 394 MiB doing nothing, and never went back down after heavy runs: 1.6 GiB idle by the end of one test sequence.
2. Too little memory doesn’t fail once, it loops. At 512 MB, one burst of parallel Code runs crashed n8n with JavaScript heap out of memory. It restarted, logged Last session crashed, and died again 20 seconds later, over and over. I expected one failed execution, not an instance that stays down.
3. The smallest box fails silently. At 256 MB there was no error at all, only 22 restarts in 7 minutes. If your container restarts with nothing in the logs, check its memory limit first.
4. An old tip now costs RAM. Older guides tell you to set N8N_DEFAULT_BINARY_DATA_MODE=default. On n8n 2.x that keeps files in memory: a 50 MB file workflow used 75% more RAM and ran four times slower than with the variable left unset. Doubling the cores past 4 did nothing by comparison.
5. “Write to disk” broke out of the box. n8n 2.x limits file nodes to ~/.n8n-files, and the Docker image doesn’t create that folder, so my first file workflow failed with ENOENT: no such file or directory, realpath '/home/node/.n8n-files'.
6. A red ERROR that isn’t one. The task runner logs ERROR [runner:js] ExperimentalWarning: localStorage is not available on every Code node run. It’s a harmless Node warning; ignore it.

The short version

Size n8n for your heaviest workflow’s peak, then add the OS:

• If you run scheduled jobs and webhooks, a 2 vCPU / 4 GB server with SQLite is enough.
• If you run Code nodes over large data or move files, take 8 GB.
• If workflows like W1 top about 20 runs a second, more cores stop helping; look at queue mode.
• If your setup sets N8N_DEFAULT_BINARY_DATA_MODE=default, remove it.

You have the size. The template handles the rest before n8n first starts: HTTPS, the webhook URL and an encryption key pinned outside the containers. Launch n8n on a 4 GB server in about four minutes, $5 welcome credit, no card.

Keep reading:

• One-click n8n on a dedicated server
• n8n pricing: Cloud plans vs running it yourself
• Best n8n hosting providers in 2026, ranked
• n8n vs Zapier: what 1,000 to 20,000 runs cost

n8n system requirements FAQ