n8n Server Requirements

How much machine a self-hosted n8n instance actually needs, what the database adds, and the point at which one instance stops being enough. Most sizing guidance you will find online is written for queue mode, which most people never need, so it reads as a much bigger requirement than it is.

The short answer

A single n8n instance running normal workflows is not a demanding piece of software. Two vCPU and 2 GB of RAM comfortably runs a real workload of scheduled jobs, webhooks and API calls, because n8n spends most of its life waiting on other people’s services rather than computing. The n8n main process itself sits around 300 MB at rest.

What actually drives the number up is not how many workflows you have defined. It is how much data a single execution holds in memory at once, and how many executions run concurrently.

What consumes memory in n8n

n8n passes data between nodes as items held in memory for the life of the execution. That has one important consequence for sizing: a workflow that fetches ten thousand rows and maps them through five nodes is a far heavier tenant than a hundred workflows that each move a webhook payload.

• Payload size per execution. Large HTTP responses, spreadsheet imports and binary files are the usual cause of an instance that was fine and suddenly is not.
• Concurrency. Ten executions running at once each hold their own working set. A schedule that fires several workflows on the same minute is a spike you did not plan.
• Execution history. Saved execution data accumulates in the database. It is a disk and database question rather than a RAM one, but it is the thing that grows quietly for months and then matters.

The practical implication: if you process big payloads, split them. Batching a large dataset into chunks does more for stability than any amount of extra RAM, because it changes the peak rather than raising the ceiling.

The database is a requirement, not an optimisation

n8n defaults to SQLite, which is fine for a trial and a poor idea in production. It handles concurrent executions badly and is awkward to back up and restore reliably. PostgreSQL is the production answer and it is not free in resource terms: budget roughly 500 MB to 1 GB for it, growing with your execution history.

That figure is the one most sizing guides quietly fold into the same box as n8n itself. On a DIY VPS it comes out of the same RAM as your workflows, along with the container runtime, a reverse proxy and the operating system. On our plans the PostgreSQL cluster is a separate high-availability component with its own memory, so the RAM in the plan name is RAM for n8n.

CPU: usually not the constraint

n8n is dominated by waiting. An execution spends its time on network round trips to APIs, not on computation, so two cores go a long way. The exceptions are real but specific: heavy data transformation in Code nodes, large JSON parsing, and AI workflows that do meaningful local work rather than calling a model API. If your workflows are mostly integrations, add RAM before cores.

When you need queue mode

By default n8n runs everything in one process. Queue mode splits it: a main instance accepts triggers and hands executions to separate worker processes through Redis, so the main process stays responsive no matter how long a job takes. It is the standard answer to scaling n8n, and it is also the reason most published sizing advice looks so heavy.

You need it when one of these is true, and not before:

• Long executions are blocking short ones. A workflow that takes five minutes will make an incoming webhook wait behind it in single-process mode. In queue mode the main instance acknowledges immediately and a worker does the work.
• You see a visible backlog. The clearest signal is executions sitting in a waiting state for more than a few seconds in the n8n UI. That is a queue forming, and no amount of extra RAM on one process removes it.
• One heavy job can take the instance down with it. Isolation is often the real motivation rather than throughput.

Queue mode adds two things to your requirements. Redis, which is small at around 128 MB but is another component to run, and RAM per worker: each worker process consumes roughly 200 to 500 MB depending on what your workflows carry. Two workers is the sensible starting point, and you add more only when the backlog says so. Workers want RAM far more than they want cores, which is why the usual scaling path adds memory two or three times before it adds CPU.

Being straight about it: a multi-worker queue-mode deployment needs a Redis component and more memory than the tiers above provide, so it is not what these plans are. They are single-instance n8n with a high-availability database, which is what the large majority of self-hosted instances actually are. If you have measured a backlog and genuinely need workers, you have outgrown a one-click deployment and should size a dedicated stack for it.

Storage, and the thing that grows

n8n itself needs very little disk. Execution history is what grows, and it grows in proportion to how often your workflows run rather than to how many you have. A workflow polling an API every ten minutes produces around 4,300 executions a month on its own. Prune saved execution data on a retention policy rather than waiting for the disk to make the decision for you, and keep failed executions longer than successful ones, because those are the only ones you will ever read.

Requirements that are not hardware

Two of them matter more than any specification. Webhooks need a stable public HTTPS URL, which means a real domain, a valid certificate and a reverse proxy in front of n8n; a self-hosted instance without that can run schedules but cannot receive anything. And an automation platform has to be up when the trigger fires, which rules out a laptop and makes uptime a requirement in the same sense that RAM is.

Frequently asked questions