n8n System Requirements: Smaller Than You Think, Until They Are Not

n8n’s own documented baseline is modest: memory measured in hundreds of megabytes, a few gigabytes of disk, and SQLite or PostgreSQL for storage. People running it report a single vCPU with 2GB of RAM handling a handful of active workflows without breaking a sweat. The numbers only climb when specific things change, and it is worth knowing which.

The sizing question is genuinely easy to answer wrong in both directions. Provision a large instance for three workflows and you have bought idle capacity. Provision the minimum and then add a workflow that processes a ten thousand row export in one node, and the process gets killed by the out-of-memory reaper mid-run, leaving a half-finished execution and no obvious explanation.

Table of contents

• The baseline
• What actually drives the numbers up
• SQLite versus PostgreSQL
• Queue mode, and when you need it
• Availability matters more than capacity
• A sizing rule of thumb
• How this fits the rest of the stack
• FAQ

The baseline

• CPU — 1 vCPU is enough for light to moderate use. Workflow execution is mostly waiting on HTTP calls, which is not CPU work.
• Memory — the documented range starts in the hundreds of megabytes and goes up to a couple of gigabytes. 2GB is a comfortable starting point with headroom.
• Disk — a few gigabytes. n8n itself is small; the growth comes from execution history and any binary data passing through.
• Database — SQLite by default, PostgreSQL recommended for anything real.
• Node.js — required if installing directly rather than via Docker, and version-sensitive.

Reports from people running it in practice line up with the documentation: one vCPU sitting at a couple of percent utilisation, 2GB of RAM with well under a gigabyte in use, a few gigabytes of disk. That is genuinely the shape for a small deployment.

But those numbers describe an idle-ish instance running a handful of workflows on schedules. Four specific things change the picture, and all four are things people add without thinking of them as capacity decisions.

What actually drives the numbers up

1. Large payloads in a single node. n8n holds items in memory as they move between nodes. Fetching a 200MB JSON response, or a node that emits fifty thousand items, puts all of that in the process. This is the most common cause of an out-of-memory kill and it has nothing to do with how many workflows you run.
2. Binary data. Files passing through — PDFs, images, exports — are held in memory by default. n8n can be configured to write binary data to disk instead, which trades memory for I/O and is usually the right trade.
3. Concurrency. Several workflows firing simultaneously each carry their own working set. A webhook that receives bursts is different from a schedule that fires once an hour.
4. Execution history. Every run is stored. With verbose workflows and a short interval, the database grows faster than expected, and on SQLite that shows up as the whole instance getting slower.

The first one is worth designing around rather than sizing for. Splitting a large fetch into pages, using the batching node to process items in chunks, and streaming binary data to disk all keep the working set small regardless of instance size. Buying more memory to run one badly-shaped workflow is the expensive fix.

SQLite versus PostgreSQL

SQLite is the default and is fine for evaluating. It stops being fine sooner than people expect.

Move to PostgreSQL when any of these are true:

• The instance is doing anything you would be annoyed to lose.
• Execution history matters — either for debugging or because you need to look at what ran last week.
• You want to run more than one n8n process, in queue mode or otherwise. SQLite does not support that.
• You want backups that are a database operation rather than a file copy of something being actively written.
• Performance has started degrading in a way that correlates with how long the instance has been running.

That last symptom is the classic SQLite growth curve: everything is fine for two months and then the editor gets slow, because execution history has grown into a single file that every query touches. Pruning helps and is worth configuring regardless — n8n can be told to delete executions older than a set age, which is the single most effective thing you can do about disk growth.

Migrating from SQLite to Postgres later is possible and is more disruptive than starting on Postgres. If the instance is going to matter, start there.

Queue mode, and when you need it

By default n8n runs everything in one process. Queue mode splits it into a main instance and one or more workers coordinated through Redis, so executions are distributed.

Signals that you have outgrown the single process:

• Webhook responses are slow because a long workflow is occupying the process.
• Executions queue behind each other during bursts.
• You want a workflow failure to be unable to affect the editor’s availability.
• You want to scale execution capacity without scaling the whole instance.

The cost is real: queue mode means Redis, a Postgres database, and at least two n8n processes to run and keep in version lockstep. That is a meaningfully larger operational footprint than one container. Most teams do not need it, and reaching for it early is a common over-engineering mistake.

The intermediate step people skip: check whether one workflow is responsible for the contention. Frequently it is, and fixing that workflow is cheaper than restructuring the deployment.

Availability matters more than capacity

This is the part that sizing discussions usually miss. n8n’s value is that it reacts to events, and an instance that is down does not receive webhooks. The sender usually does not retry.

So the practical requirements list is less about cores and more about:

• A stable public URL with a valid certificate, for webhook endpoints.
• Restart on failure, so a crash does not mean an outage until someone notices.
• Persistent storage for credentials and execution history that survives a container replacement.
• Environment variables managed outside the image, so a credential change does not require a rebuild.
• Logs you can read after a failed execution, without shelling into a box.
• Upgrades that do not lose state, which in practice means the database is separate from the application.

Every one of those is an operational property rather than a hardware number, and together they matter more than the difference between 2GB and 4GB of RAM.

A sizing rule of thumb

• Evaluating, a few workflows, low frequency — 1 vCPU, 1-2GB RAM, SQLite. Fine.
• A team depending on it, moderate workflows — 1-2 vCPU, 2GB RAM, PostgreSQL, execution pruning configured.
• Large payloads or file processing — same CPU, more RAM, and binary data written to disk rather than held in memory.
• Frequent webhook bursts or long-running workflows — consider queue mode, but first check whether one workflow is the problem.
• Anything you would be paged about — the availability list above matters more than the numbers.

Start small. n8n is not resource-hungry, and the failure mode when you undersize is loud and quick to diagnose. Oversizing is quiet, permanent, and paid monthly.

How this fits the rest of the stack

The awkward part of self-hosting n8n is not the memory figure — it is everything in the availability list: the certificate, the restart policy, the separate database, the upgrade that must not lose credentials. n8n is one of the managed tools on RunxBuild, so those come with the plan: a live URL, custom domains, environment variables, autoscaling between a floor and a ceiling, logs per execution, and a managed Postgres provisioned beside it rather than inside it. A Basic plan at $6 a month with a managed database alongside covers a real team’s workflow load. Services on RunxBuild covers the deploy, variable, and log model, and the RunxBuild hosting calculator shows the tool plan, the database, storage, and bandwidth separately so you can size it against what you actually run.

Useful related references:

• n8n vs Make: Where the Complexity Goes
• n8n Use Cases: What It Is Genuinely Good At, and What It Is Not
• n8n Alternatives: The Honest Comparison by What You Are Escaping
• Services on RunxBuild

FAQ

What are the minimum system requirements for n8n?

n8n’s documented baseline is in the hundreds of megabytes of memory, a few gigabytes of disk, and either SQLite or PostgreSQL for storage. In practice a single vCPU with 2GB of RAM comfortably runs a handful of active workflows with plenty of headroom.

Why does my n8n instance run out of memory?

Almost always a single node holding a large payload — a big API response, a node emitting tens of thousands of items, or binary files held in memory. Page the fetch, use batching to process items in chunks, and configure binary data to be written to disk instead of memory.

Should I use SQLite or PostgreSQL with n8n?

SQLite is fine for evaluation. Move to PostgreSQL as soon as the instance matters: it is required for queue mode, makes backups a database operation, and avoids the gradual slowdown that comes from execution history growing into one file. Migrating later is more disruptive than starting there.

When do I need n8n queue mode?

When webhook responses are delayed by long-running workflows, executions queue during bursts, or you want execution capacity to scale independently of the editor. It requires Redis, PostgreSQL, and multiple processes in version lockstep, so check first whether one badly-shaped workflow is the actual cause.

How much disk does n8n need?

A few gigabytes to start, but execution history is what grows. Configure n8n to prune executions older than a set age — it is the single most effective control on disk growth, and it also prevents the slowdown that comes from a large history table.