n8n System Requirements: How Much Server Do You Actually Need?

If you search for n8n system requirements, you will find surprisingly little official guidance, and what exists is deliberately vague. That is because the honest answer depends almost entirely on what your workflows do. A workflow that fires once an hour and posts a Slack message needs almost nothing. A workflow that pulls 50MB JSON exports every minute and transforms them with Code nodes needs real hardware.

This guide breaks down the n8n hardware requirements question mechanically: what actually consumes CPU, RAM, and disk, how to size a server for your workload, and when to move to something bigger. If you have not deployed yet, our guide on how to self-host n8n covers installation; this post covers sizing.

The Short Answer: Sizing at a Glance

Here is a practical starting point. These are not benchmarks, they are reasoned defaults based on how n8n behaves in practice, and you should treat them as a floor to adjust from.

Workload	vCPU	RAM	Disk	Example use case
Testing / hobby	1	1GB	20GB	Trying n8n out, a few manual workflows
Personal / small business	1	2GB	40GB	Scheduled automations, webhooks, light API syncs
Growing team	2	4GB	80GB	Concurrent flows, larger payloads, Code nodes
High volume	3+	8GB+	160GB+	Many parallel executions, big data transforms
Very high volume	Horizontal	Horizontal	Postgres + Redis	Queue mode with dedicated worker processes

To put concrete numbers on this, our own Hosto n8n hosting tiers (full disclosure: that is our product) map directly onto these rows: the Starter plan at 1 vCPU, 2GB RAM, and 40GB NVMe runs $12/mo (or $9/mo billed annually) and is genuinely fine for most personal and small-business automation. Growth at 2 vCPU, 4GB, and 80GB ($24/mo, $18 annually) suits heavier concurrent flows, and Scale at 3 vCPU, 8GB, and 160GB ($39/mo, $29 annually) handles high-volume workloads. If you prefer raw infrastructure, a Hetzner VPS starts around 4 to 5 euros and a DigitalOcean basic droplet at $6, though you take on the setup and maintenance yourself.

Now let us look at why those numbers are what they are.

What Actually Consumes Resources in n8n

n8n is a Node.js application. That single fact explains most of its resource profile. Node.js is single-threaded for JavaScript execution, event-driven for I/O, and holds working data in memory. Each of those properties maps to a specific sizing consequence.

RAM: the resource that bites first

Memory is where most self-hosted n8n instances hit trouble, and the mechanism is simple: n8n holds execution data in memory while a workflow runs. Every item flowing between nodes, every API response, every file you load into a workflow lives in the Node.js heap until the execution finishes.

A tiny test instance will typically idle in the 512MB to 1GB range, which is enough to click around the editor and run small workflows. But the moment a workflow pulls a large payload, memory usage spikes, often by several copies of the payload, because each node in the chain can produce its own transformed version of the data.

This is why 2GB of RAM is a comfortable production minimum. It gives the process room for realistic payload spikes without the Linux OOM killer terminating it mid-execution, which is the classic failure mode of underprovisioned instances: workflows that mysteriously die partway through with no useful error.

Rules of thumb that hold up in practice:

• Size RAM for your worst payload, not your average one. One big file sync can crash an instance that handles a thousand small webhooks fine.
• Concurrent executions multiply the problem. Three heavy workflows running at once need roughly three times the peak memory of one.
• Binary data (files, images, PDFs) is the most common source of surprise spikes. If your workflows move files, be generous with RAM or configure filesystem-based binary data storage.

CPU: Code nodes and concurrency

For typical automation, meaning webhooks, HTTP requests, and simple transforms, n8n is I/O bound. The server spends most of its time waiting on external APIs, and a single vCPU handles this comfortably. This is why a 1 vCPU box is a reasonable production baseline for personal and small-business use.

CPU starts to matter in two situations. First, Code nodes: JavaScript you write inside a workflow runs on the server, and loops over thousands of items or heavy string processing will pin a core. Second, parallel executions: when multiple workflows trigger simultaneously, they compete for CPU time, and on a single vCPU they queue up behind each other, which shows up as latency on time-sensitive webhook responses.

In practice, move from 1 to 2 vCPUs when you regularly run overlapping executions or lean heavily on Code nodes, and beyond that when you see sustained CPU saturation rather than brief spikes.

Disk: execution history is the silent grower

n8n itself is small. What grows is execution data: by default, n8n saves the input and output of every node for every execution, which is wonderful for debugging and terrible for disk usage. A busy instance can accumulate gigabytes of history surprisingly fast, especially with large payloads.

The fix is retention settings. n8n exposes environment variables for execution data pruning (EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE, and related settings) that cap how long history is kept. Set these on day one. With sensible pruning, 40GB is plenty for a small instance; without it, no disk is ever big enough. Our production docker compose guide includes a pruning configuration you can copy.

Disk speed matters more than people expect, too. Execution logging means constant small writes to the database, so NVMe or SSD storage is strongly preferable to spinning disks or throttled network volumes.

SQLite or Postgres?

n8n ships with SQLite by default, and for small setups that is genuinely fine. SQLite is fast, zero-maintenance, and one less service to run. Plenty of production instances run on it for years.

Postgres becomes the recommended choice as volume grows: it handles concurrent writes better, it is easier to back up and restore independently, and it is required for queue mode. A reasonable rule: if you are past the hobby stage, or expect to grow, start on Postgres. Migrating later is possible but is one of those chores that never happens at a convenient time.

Budget roughly an extra 512MB to 1GB of RAM headroom if Postgres runs on the same box, which is the common setup on a 4GB server.

When One Server Is Not Enough: Queue Mode

At some point, vertical scaling stops making sense. n8n's answer is queue mode: instead of one process doing everything, a main instance handles the UI, scheduling, and webhooks, and pushes executions onto a Redis queue, where one or more separate worker processes pick them up and run them. Workers can live on the same machine or on entirely different machines, which is what makes horizontal scaling possible.

Keeping this at a high level: once you are in queue mode, you stop sizing one server and start sizing a fleet. The main instance can be modest, Postgres and Redis need their own headroom, and workers scale out with load. If a single 8GB instance running executions back to back is no longer keeping up, queue mode is the path forward rather than an ever-larger single box. Most users never need this; it exists so the ones who do are not stuck.

A Practical Sizing Decision Process

Rather than guessing, walk through these questions:

1. What is your largest payload? If workflows only move small JSON, 2GB RAM is comfortable. If they move files or large exports, start at 4GB.
2. How many executions overlap? Sequential scheduled jobs are cheap. Simultaneous webhook-driven executions multiply CPU and RAM needs.
3. Do you write Code nodes? Heavy in-workflow JavaScript justifies a second vCPU sooner.
4. How long do you need execution history? Set pruning to match, then size disk accordingly.
5. Is this business-critical? If yes, use Postgres, take backups, and leave headroom above your observed peak. Running at 90 percent memory utilization is an outage waiting for a large payload.

Then start one tier smaller than you think you need, watch actual usage for two weeks, and resize. Scaling a plan upward is a five-minute operation; overpaying for a year is not refundable.

The Cost Angle

Because n8n's resource needs are so modest at the low end, the economics often favor self-hosting: a $9 to $12 per month server typically runs unlimited workflows and executions, where usage-based cloud pricing scales with volume. We break down the full comparison in n8n cloud vs self-hosted.

FAQ

Can n8n run on 1GB of RAM?

Yes, for testing and light personal use. A tiny instance typically idles well under 1GB. The risk is payload spikes: one workflow that loads a large API response or file can exhaust memory and crash the process. For anything you rely on, 2GB is the comfortable production minimum.

Does n8n need a dedicated server or is a shared VPS fine?

A standard VPS is fine, and it is how most self-hosted instances run. Entry-level options like a Hetzner VPS at around 4 to 5 euros or a DigitalOcean $6 droplet can technically run n8n, though at 1GB RAM they sit in the testing tier above. A managed option like Hosto's $12/mo Starter (2GB RAM, NVMe) trades a few dollars for not handling setup, updates, and backups yourself.

How much disk space does n8n use?

The application itself needs very little; execution history is what grows. With default settings, n8n stores full input and output data for every execution, which can reach gigabytes quickly on busy instances. With pruning enabled via the retention environment variables, 40GB comfortably covers small to medium instances.

When should I switch from SQLite to Postgres?

Move to Postgres when the instance becomes business-critical, when execution volume grows beyond a few thousand per day, or when you anticipate needing queue mode, which requires it. For a single-user hobby instance, the SQLite default is fine and simpler to run.