Search “n8n server requirements” and you get confident numbers: 320 MB minimum, 2 GB recommended, 4 GB to be comfortable. Almost none of them come from n8n.
I went looking for the official spec. It does not exist. What does exist is a handful of real numbers scattered across n8n’s docs, and they tell a more useful story than the made-up ones.
Does n8n Publish Official Server Requirements?
No. There is no minimum-hardware page anywhere in n8n’s documentation for self-hosting. The “320 MB” figure that circulates is real, but it is an n8n Cloud plan allocation - what n8n’s own hosting gives a Trial or Starter account - not a self-hosting requirement.
For completeness, those Cloud allocations are: Trial and Starter at 320 MiB RAM and 10 millicore burstable CPU, Pro-1 at 640 MiB, Pro-2 at 1280 MiB, Enterprise at 4096 MiB. Useful as a sanity check on how little n8n needs to run. Useless as a spec for a box you administer, because n8n Cloud is not running your file-heavy workflow in your memory.
Here is every official self-hosted number I could find:
| Source | Number | What it actually is |
|---|---|---|
| n8n Kubernetes sample manifest | 250 Mi request, 500 Mi limit | An example manifest, explicitly not a requirement |
| n8n’s Hetzner deployment guide | ”For most usage levels, the CPX11 type is enough” | A real recommendation for a real 2 GB / 2 vCPU box |
| n8n AI Assistant docs | ”At least 4 GB of RAM and 2 vCPUs” | A hard requirement, but only for the AI Assistant sandbox |
| n8n benchmarking docs | ”up to 220 workflow executions per second on a single instance” | Measured on a 4 GB AWS c5a.large with Postgres |
The Hetzner line is the most quotable thing n8n has said about sizing, and it points at 2 GB.
How Much RAM Does n8n Need?
Plan on 2 GB. n8n starts in a few hundred megabytes and idles happily there, but memory is what it runs out of first under real load, because binary data goes through memory by default and Node’s heap grows to fill whatever it thinks it has.
The honest ranges, by what you are actually doing:
| Workload | RAM | Why |
|---|---|---|
| Kicking the tyres, a few scheduled workflows, no files | 512 MB - 1 GB | It runs. Cap the Node heap or it will not. |
| Real use: webhooks, integrations, occasional attachments | 2 GB | The sensible floor for something you depend on |
| File-heavy work, big API payloads, many concurrent executions | 4 GB | Headroom for spikes rather than a hard requirement |
| AI Assistant enabled | 4 GB, 2 vCPU | n8n states this one outright |
That last row is the one people misread. The 4 GB and 2 vCPU figure is the requirement for n8n’s AI Assistant sandbox, not for an AI agent you build yourself: a practical floor for an agent workflow is 2 GB, because each tool call holds its context in memory for the length of the run. The n8n AI Agent node in practice has the sizing numbers n8n does publish.
Two things make small boxes fail in ways that look like n8n bugs, and both are fixable without spending more:
- Binary data in memory. n8n’s docs: “When handling binary data, n8n keeps the data in memory by default. This can cause crashes when working with large files.” Setting
N8N_DEFAULT_BINARY_DATA_MODE=filesystemmoves it to disk. - The Node heap ignoring your container limit. V8 sizes its heap from the host’s RAM, not from a cgroup limit, so in a container it will happily grow past the cap and get OOM-killed or push the box into swap. Cap it with
NODE_OPTIONS=--max-old-space-size=<about 65% of your limit>.
Both are covered in more detail in why n8n gets slow, because they show up as slowness long before they show up as a crash.
How Many CPU Cores Does n8n Need?
One works, two is comfortable, and more rarely helps. Most n8n workflows spend their time waiting on someone else’s API, not computing. n8n’s own benchmark hit 220 executions per second on a single 4 GB AWS instance, which is far more than most self-hosters will ever generate.
CPU becomes the constraint in three specific cases: heavy Code nodes doing real work in JavaScript, large data transformations held in memory, and many genuinely concurrent executions. If you are not doing one of those, adding cores to a slow instance changes nothing. Check what is actually busy before you upgrade - top with low CPU and high load means you have a memory problem, not a CPU one.
Worth knowing: in regular mode n8n does not limit concurrent production executions at all. N8N_CONCURRENCY_PRODUCTION_LIMIT defaults to -1, and the docs say “In regular mode, n8n doesn’t limit how many production executions may run at the same time.” On a small box, setting a real limit is often a better move than buying more CPU - it turns an overloaded instance into a slower one rather than a dead one.
How Much Disk Does n8n Need?
10 GB comfortably covers the application, the database and a normal 14-day execution history. Disk only becomes the constraint through two specific mistakes: binary data stored in the database, and never reclaiming pruned space on SQLite.
n8n prunes execution data by default - 336 hours and 10,000 executions - so history does not grow without bound. But on SQLite the file does not shrink. From the docs: “the disk space of any pruned data isn’t automatically freed up but rather reused for future executions data.” You get that space back with DB_SQLITE_VACUUM_ON_STARTUP or a manual VACUUM, and the docs warn it “is a long running blocking operation and increases start-up time.”
So: 10 GB for most people, 25 GB if workflows move files through filesystem binary-data mode, more only if you are deliberately keeping long history.
When Do I Need a Bigger Setup?
When executions start waiting on each other rather than on APIs. That is the only symptom that a bigger single box, or queue mode, actually fixes. Everything else on this page is configuration.
The progression, in the order it is worth taking:
- One instance, SQLite, 2 GB. This carries a surprising amount. Fix the binary-data mode and the heap cap first.
- One instance, PostgreSQL, 2-4 GB. Move the database when the editor is slow under a large history and WAL mode did not fix it. One warning if you do this on a managed pod: our daily backup captures n8n’s own data directory, so moving the database out of it means you now own backing that database up.
- Queue mode with Redis and workers. Only when concurrency is the binding constraint. It requires Redis, effectively requires PostgreSQL, and n8n’s docs say running it on SQLite “isn’t recommended”. See queue mode explained. One extra constraint if you also expose MCP: multiple webhook replicas break long-lived MCP connections unless every
/mcp*request is routed to one dedicated replica, which the n8n MCP server guide spells out.
Most people who think they are at step 3 are at step 1 with a default they never changed.
What This Means for Picking a Plan
2 GB is the number that matters, which puts n8n above the entry tier on almost every host. On InstaPods that is the $7/mo Build plan: 2 vCPU, 2 GB RAM, 25 GB SSD. The $3/mo Launch plan has 512 MB, which is why n8n is not offered on it.
Being straight about what that buys and what it does not. It buys a box that is correctly sized for n8n out of the box, with binary data on disk, the Node heap capped to the plan’s real memory limit, HTTPS in front, and the data directory backed up daily. It does not buy you more performance than the same specs elsewhere - 2 vCPU and 2 GB is 2 vCPU and 2 GB.
And if 2 GB is more than you want to spend on an automation tool, the answer is a different tool rather than a smaller pod. Footprint is one of the honest reasons people leave: nine self-hosted n8n alternatives compared by RAM and licence puts Node-RED on a Raspberry Pi and Activepieces at 1.5-2 GB. If footprint is the deciding factor, Node-RED vs n8n is the direct comparison: Node-RED idles at roughly 100 MB against n8n’s 2 GB.
If you would rather run it yourself, n8n’s own suggested Hetzner CPX11 is a reasonable call - though when we priced eight n8n hosts against their live pages, the CX23 at €5.49 gave 2 vCPU and 4 GB for less than the CPX11 costs, and in Hetzner’s US locations the CPX11 is €17.49. Check which continent you are on before taking that recommendation at face value.
Where the plans land for n8n specifically:
| Plan | Specs | Fits n8n? |
|---|---|---|
| Launch, $3/mo | 1 vCPU, 512 MB, 10 GB | No - below where n8n is comfortable |
| Build, $7/mo | 2 vCPU, 2 GB, 25 GB | Yes - the default choice |
| Grow, $15/mo | 2 vCPU, 4 GB, 50 GB | For file-heavy work or the AI Assistant |
| Scale, $25/mo | 4 vCPU, 8 GB, 100 GB | For an instance plus a database and real concurrency |
FAQ
Can n8n run on a Raspberry Pi? A Pi 4 with 4 GB, yes, for modest workflows. The constraints are the same ones as anywhere: binary data mode, the heap cap, and SD-card write endurance if you keep a lot of execution history. Use an SSD.
Does n8n need Docker? No. n8n installs globally from npm and runs as a service - that is how InstaPods runs it. Docker is the most documented path, not a requirement. Check the Node floor before you install: n8n 2.21.4 wanted Node 22.16 or newer, and the package published as latest on 2 September 2026 (2.37.7) declares Node 24 or newer.
Is SQLite good enough, or do I need PostgreSQL? SQLite is fine for a single instance, and n8n 2.x supports only SQLite and PostgreSQL - MySQL and MariaDB were dropped. Move to Postgres when you add workers, or when you want the database backed up separately from the app.
How much RAM does n8n use at idle? A few hundred megabytes. Idle usage is not the number that matters; peak usage during an execution that handles data is.
Do I need more RAM for more workflows? Not for having them. Storing 500 inactive workflows costs almost nothing. What costs memory is how many run at once and how much data each moves.
Want a box that is already the right size for n8n? Deploy n8n on InstaPods - $7/mo for 2 vCPU, 2 GB RAM and 25 GB SSD, with the binary-data and heap settings already correct. Or read what it costs to keep n8n running before you decide.