n8n server requirements: what n8n 2.x really uses, measured on five servers

The real n8n server requirements are modest: 2 vCPU, 4 GB of RAM and about 10 GB of free disk run n8n with PostgreSQL comfortably. On our servers n8n 2.46.6 idled near 400 MiB, PostgreSQL under 70 MiB, and even 50 concurrent webhook requests pushed n8n to at most 1049.6 MiB. CPU is what sets the ceiling: 4 vCPU handled twice the webhook load of 2 vCPU.

Why this matters now: n8n 2.x runs Code nodes through task runners, and most requirement lists online still repeat "2 GB minimum" without saying what was measured. We measured each part separately, idle and under load. This guide is part of our n8n hosting section.

Tested in the Lab Hetzner CX23, CX33, CX43, CAX11, CAX21 · n8n 2.46.6 + PostgreSQL 16 · Nov 2026

Quick answer by workload

A vCPU is a virtual CPU core. MiB is mebibytes (1 MiB = 1.048576 MB; 1024 MiB = 1 GiB). Executions/s is completed workflow runs per second in our webhook test. Sizes match the Hetzner plans we tested; other providers are not yet tested in our Lab.

What the n8n docs say

In the n8n hosting, database and scaling pages we checked on 5 November 2026, n8n gives no fixed minimum CPU or RAM. What the docs do say:

• Memory depends on your data. The memory errors page says "n8n doesn't restrict the amount of data each node can fetch and process". It lists the causes of memory trouble: large JSON, large binary files, Code nodes, manual executions in the editor, and many workflows running at once. The fixes it gives are more memory or a higher Node.js heap with --max-old-space-size.
• Database. "By default, n8n uses SQLite to save credentials, past executions, and workflows. n8n also supports PostgresDB." Supported PostgreSQL versions are the latest two (17 and 18 as of July 2026) plus 16 for compatibility. We use 16.
• Benchmark hardware. n8n's single-instance benchmark ran on an AWS c5a.large with 4 GB RAM in main mode with PostgreSQL.
• Scaling. Queue mode needs Redis and a database other than SQLite; a distributed setup on SQLite "isn't supported".

So the docs tell you what uses memory, not how much. That is the gap our numbers fill.

RAM: measured by component

Measured by AI Hosting Lab on 2026-11-05 · docker compose: n8n + postgres:16, docker.io from Ubuntu repo, task runners on · method

That table is our production CX23 on Ubuntu 26.04 with no workflows yet. Three things stand out:

• Startup spike. n8n used 785.3 MiB right after start and settled to 379.7 MiB after about a minute. A server that only fits the idle number can fail at boot or after an update.
• PostgreSQL is small. 69.6 MiB idle. Most of the stack's memory is n8n itself.
• The OS and Docker take their share. The whole server used 1036 MiB idle, so about 590 MiB went to the operating system and Docker beyond the two containers.

Idle on all five test servers

Idle RAM barely changes with server size or CPU architecture. "Start to healthy" is image pull plus first start until n8n's health check answered; the 2 vCPU servers were slowest.

Under load

During our webhook test (webhook → Code node → response, every execution saved to PostgreSQL) the n8n container grew with concurrency. On the CX23: 519.8 MiB at 1 concurrent request, 660.1 at 10, 824.8 at 25 and 1003.0 at 50. The highest peak on any server was 1049.6 MiB on the CX33. Our test payload was tiny; large items or files will need more, as the n8n docs warn.

Measured by AI Hosting Lab on 2026-11-05 · 5 servers · method · raw data

CPU: idle is nothing, load is everything

Idle, n8n used 3.16% CPU and PostgreSQL 0.03% on our production server. Under webhook load, vCPU count decided throughput:

• 2 vCPU: 15.04 executions/s (CX23), 13.9 (CAX11)
• 4 vCPU: 31.93 (CX33), 25.77 (CAX21)
• 8 vCPU: 36.14 (CX43)

The jump from 2 to 4 vCPU doubled throughput. The jump from 4 to 8 added 13%. In regular mode one n8n main process receives the webhooks and runs the executions, so beyond about four cores the extra capacity goes mostly unused by n8n. The full analysis is in our n8n webhook performance report.

Disk

• Images: n8n 1.94 GB, postgres:16 642 MB, 2.58 GB together.
• After install: 4.7 GB used of 38 GB on the CX23, including Ubuntu.
• Growth: execution history in PostgreSQL. We prune executions after 336 hours (14 days) with EXECUTIONS_DATA_PRUNE and EXECUTIONS_DATA_MAX_AGE. We have not measured database growth over months yet.
• Updates: each new n8n image is another ~2 GB until you remove the old one with docker image prune.

Our five test servers measured 35013 to 53796 random 4k IOPS (input/output operations per second, small reads and writes) for reads and writes. We have not measured how much disk I/O n8n itself generates, but none of the servers needed faster storage to reach the results above.

Are 1 GB or 2 GB servers enough?

We have not tested servers below 4 GB yet, so we will not tell you they work. Our numbers make 2 GB tight: on the CX23 the system used 435 MiB with Docker installed and nothing running, n8n starts at 785.3 MiB and can reach about 1 GB under load, and PostgreSQL adds about 60 MiB. That leaves little room for the page cache, a Code node with real data, or an update pulling a new image. On 1 GB, n8n's startup spike of 785.3 MiB alone would leave almost nothing for the OS and PostgreSQL.

Plan for the external task runner

Our test used the task runner that n8n starts as a child process (internal mode). The n8n docs say internal mode is deprecated from n8n 3.0 and recommend external mode, where runners run in a separate n8nio/runners container. That container will need its own RAM. We have not measured it yet and will add it here.

Add other apps to the same server

n8n rarely lives alone. Add up what else you will run with our calculator, using the measured RAM of Ollama models and Supabase:

The standalone version is the VPS RAM calculator.

Keep memory in check

• Set N8N_CONCURRENCY_PRODUCTION_LIMIT if bursts of heavy executions are possible. The n8n docs say regular mode does not limit concurrent production executions by default; with a limit, extra ones wait in line.
• Split large data into batches instead of loading everything in one node, as the memory errors page advises.
• Avoid running big manual executions in the editor on a small production server.
• Keep swap in mind: none of our test servers had swap, so running out of RAM kills a process instead of slowing it.

Next step: pick the server that fits these numbers in our best VPS for n8n comparison.