A single-user n8n instance running scheduled workflows is comfortable on 2 vCPU and 2 GB of RAM. What pushes it higher is almost never the number of workflows — it is the size of the data a single execution holds in memory, and the database that keeps every execution afterwards. Most people who outgrow a small server outgrow it for one of those two reasons, not because they built more automations.
This guide explains what actually consumes resources in a self-hosted n8n instance, so you can size a server against your own workload instead of guessing.
What decides how much server n8n needs?
n8n is a Node.js application. In its default configuration the main process both serves the editor and runs every execution. That has three consequences worth understanding before you pick a plan:
- Memory is per execution, not per workflow. n8n holds the items flowing through a workflow in memory. A workflow that pulls 50 records uses very little. The same workflow pulling 50,000 records, or one that downloads a 200 MB file, can use more memory than the whole rest of the instance combined.
- CPU matters when executions overlap. One workflow every ten minutes barely registers. Twenty webhook calls arriving in the same second compete for the same event loop.
- Disk grows quietly. Every execution is written to the database with its data. Left unpruned, an instance running a few hundred executions a day will fill a small disk in months.
How much RAM does n8n need?
Start from what a single execution carries, not from the workflow count.
- API calls returning small JSON payloads: 1–2 GB is enough for a personal instance.
- Batch jobs over thousands of rows: plan for 4 GB. Splitting a large batch into loops keeps the peak far lower than processing everything in one node.
- Binary data — PDFs, images, video, file uploads: 4 GB and up, and switch binary storage off the database (see below).
Node.js also caps its own heap. If your instance dies during a large execution with an out-of-memory error while the server still has free RAM, raise the heap limit rather than the plan:
NODE_OPTIONS=--max-old-space-size=3072Set it below the server’s total memory, not equal to it — the operating system and the database need their share.
How much CPU does n8n need?
For scheduled workflows that run one at a time, a single core copes. Two cores is the point where the editor stays responsive while a workflow is running, which matters more in daily use than raw throughput.
Go higher when executions genuinely overlap: webhook-driven workflows that fire in bursts, or several schedules that land on the same minute. If your triggers are all set to run at the top of the hour, staggering them buys you more than an extra core does.
How much disk does n8n need?
The application itself is small. The execution history is what grows. Two settings keep it under control:
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168That keeps a week of history. If you only care about failures, stop storing successful runs entirely:
EXECUTIONS_DATA_SAVE_ON_SUCCESS=noneAnd if your workflows move files, keep binary data out of the database, where it bloats both the disk and every backup:
N8N_DEFAULT_BINARY_DATA_MODE=filesystemWhich plan fits which workload?
| Workload | Sensible starting point | Why |
|---|---|---|
| Learning n8n, a handful of scheduled workflows, small JSON payloads | 2 vCPU / 2 GB / 50 GB NVMe | The editor stays usable while a workflow runs, and a week of history fits easily. |
| Daily business automation, a few webhooks, occasional batch of a few thousand rows | 3 vCPU / 4 GB / 75 GB NVMe | Headroom for one heavy execution without starving the editor or the database. |
| Binary files, larger batches, or overlapping webhook traffic | 4 vCPU / 6 GB / 100 GB NVMe | Binary handling and concurrent executions are both memory-hungry. |
| High volume, or you need executions isolated from the editor | Queue mode across separate workers | Beyond this point, splitting the roles beats buying a bigger single server. |
These map onto the n8n hosting plans; the same tiers appear on the general VPS hosting page if you want to run n8n alongside other services.
When should I move to queue mode?
Queue mode splits n8n into a main process that receives triggers and one or more worker processes that run the executions, coordinated through Redis:
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=127.0.0.1It is the right move when a long execution makes the editor unusable, when you want more executions running in parallel than one process can handle, or when a crashing workflow must not take the whole instance with it. It is the wrong move as a first optimisation: it adds Redis and at least one more process to operate, and most instances that feel slow are slow because of an unpruned database or one oversized execution.
Does the database choice matter?
Yes, past the experimentation stage. n8n defaults to SQLite, which is fine for a single user and a modest history. PostgreSQL handles concurrent writes better and makes backups and restores far less painful, which is what you want the day something goes wrong:
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=127.0.0.1
DB_POSTGRESDB_DATABASE=n8nMove to PostgreSQL before the instance matters to anyone but you. Migrating a small database is a short job; migrating a large one under pressure is not.
Two settings people forget
Neither affects sizing, but both cause the kind of failure that looks like a resource problem:
- Timezone. Schedule triggers follow the instance timezone, which defaults to UTC. Set
GENERIC_TIMEZONEto yours, or your “every morning at 08:00” workflow will run at a time you did not intend. - Public URL. Behind a reverse proxy, n8n needs to know the address the outside world uses, or the webhook URLs it generates will point somewhere unreachable. Set
WEBHOOK_URLto your public HTTPS address.
The short version
Size for the largest single execution you expect, not for the number of workflows. Prune the execution history from day one. Keep binary data off the database. Move to PostgreSQL before the instance becomes important, and to queue mode only when a single process is genuinely the limit.
If you would rather not run the server yourself, managed n8n hosting covers the infrastructure side — persistent storage, backups and monitoring — while the workflows stay yours.