n8n Self Hosting Cost, Sized by Memory Not CPU Cores

n8n's self hosting cost is lower than most blog posts claim, because they're all copying the same wrong number. n8n itself is not CPU hungry. The project's own documentation says as much, and a Cloud instance sitting idle uses somewhere around 100MB of memory. What actually drives cost isn't the tool, it's the data moving through your workflows. Size for memory and for your largest payload, not for cores, and your bill stays small.

What does n8n actually need to run?

Less than the internet tells you. I've had three separate clients this year forward me articles recommending 4 vCPUs and 8GB minimum for "production n8n", and none of those numbers came from anywhere real. They came from one blog copying another blog. n8n's own hosting docs are blunt about this: the application is not CPU intensive. It's a Node process running workflow logic, calling APIs, moving data between nodes. That's not compute heavy work, it's I/O and memory work.

What matters is what your workflows do. A handful of automations pulling data from a CRM and pushing it to Slack will run comfortably on modest hardware. A workflow that pulls a 200MB file from S3, transforms it, and pushes it somewhere else needs the memory to hold that file in the process. That's the distinction most "requirements" articles miss entirely.

How much RAM does n8n need?

This is the number to actually plan around, and n8n's documentation is explicit that memory requirements usually supersede CPU. An idle instance sits light. What matters is your peak, set by your busiest workflow's largest single payload sitting in memory, plus whatever concurrent executions you allow.

I won't give you a table of "2GB for X workflows, 4GB for Y" because that table doesn't exist honestly. It's always a guess dressed up as a spec. What I tell clients instead: start on a modest VPS, watch memory usage under real load for a week, and scale from evidence rather than a number someone invented. Our VPS hosting guide covers providers that make resizing painless, which matters more than getting the first size right.

So what's the real n8n self hosting cost then?

Cheaper than the scare-number posts suggest, for most small to mid sized automation setups. The VPS itself is the smallest line item. The real costs sit elsewhere: a managed Postgres instance if you don't want to run your own, Redis once you're in queue mode, and your own time keeping backups and updates current. None of these are large, but people budget for the server and forget the rest, then act surprised.

If you're comparing providers, our n8n hosting comparison breaks down where the actual cost differences show up between platforms, rather than pretending the server spec is the whole story.

Why does Postgres matter more than the VPS size?

Because it's the decision that ages worst if you get it wrong. n8n recommends Postgres 13 or newer for anything beyond a trial, and I'd go further: use it from day one even if you're "just testing", because the migration later is annoying and entirely avoidable.

SQLite works fine to kick the tyres. It's explicitly not recommended once you enable queue mode, and if your automation does anything the business actually depends on, you'll hit that ceiling faster than expected. Give each n8n instance its own dedicated database too, not a shared one. I've watched contention between instances sharing a database cause execution delays that took a client's team a full afternoon to diagnose, when the fix was simply separating the databases from the start.

Do I need SQLite, or should I skip straight to Postgres?

Skip straight to Postgres if there's any chance this becomes real. SQLite is genuinely fine for a local trial, a proof of concept you're running on your own machine to see if n8n suits your workflows. The moment you're deploying something colleagues depend on, move to Postgres, because the day you need queue mode, SQLite is off the table entirely and you'll be migrating live workflows under pressure instead of setting it up properly at the start.

This is the same logic I push in most of my hosting advice: the boring, slightly-more-effort choice at the beginning saves you a painful migration later. See our piece on site migration without losing SEO for the same principle applied to a different kind of move.

When do you actually need queue mode?

When executions start backing up, not before. Queue mode splits n8n into a main process and separate worker processes, so executions run in parallel rather than queuing behind each other on a single instance. It requires Postgres and Redis reachable from every worker, which adds real operational overhead: more services to monitor, more things that can fail independently.

You don't need this to begin. Most people running n8n for internal automation, agency client work, or small business workflows never hit the volume where a single main process becomes the bottleneck. Turn it on when you see executions piling up, not because a blog post told you production n8n requires it. The official queue mode documentation is worth reading properly before you flip that switch, because the reachability requirements between workers, Postgres and Redis catch people out.

What VPS should you buy for n8n?

Something you can resize without drama matters more than a specific spec sheet. n8n runs well in Docker, which is the deployment method the official installation docs lead with, and Docker is what most self hosters should actually use rather than a bare install. Look at providers on our Docker hosting shortlist if containers are new territory, and cross reference against the VPS hosting comparison for raw specs and renewal pricing that doesn't triple after year one.

If you're running n8n alongside other self hosted tools, like an OpenClaw setup or similar, size the box for the combined footprint of everything running, not n8n in isolation. Multi-tool VPS boxes are where the memory math actually gets interesting, because it's rarely one application eating your RAM, it's three quiet ones adding up.

How do binary files and large payloads change the picture?

This is the honest caveat that makes every other number in this article meaningful. n8n's baseline footprint is small. What isn't small is a workflow node holding a large file, a bulk CSV export, an image transform, a video file passed between nodes in memory. That's where a small instance runs out of headroom, and it has nothing to do with n8n being inefficient. It's simply physics: the data has to live somewhere while it's being processed.

Before you size anything, ask "what is the largest payload my workflows will realistically handle" rather than "what does n8n need". That single question reframes the entire sizing exercise and stops you either overpaying for capacity you'll never use, or undersizing and hitting out of memory errors the first time someone runs a bulk import. Track your actual instance uptime once it's live using our uptime calculator, so you know whether memory pressure is causing restarts you haven't noticed yet.

Frequently asked questions

Is n8n CPU intensive?

No. n8n's own documentation states the application is not CPU intensive, and memory requirements usually matter more than CPU when sizing a server for it.

Can I run n8n with SQLite in production?

You can for very small, low stakes setups, but it's not recommended once you enable queue mode, and most production use cases outgrow SQLite quickly enough that starting on Postgres saves a migration later.

Do I need Redis to self host n8n?

Only if you're running queue mode. A standard single instance setup with Postgres doesn't require Redis at all. Redis becomes necessary the moment you split n8n into main and worker processes.

What's the cheapest way to self host n8n?

A small VPS running n8n in Docker with a Postgres database, either self managed or a lightweight managed instance, covers most people's needs without touching queue mode or Redis at all. If you'd rather run this on hardware you already own, our guide to hosting your own web server at home covers the trade offs of that route honestly.

Final thoughts

Stop sizing n8n off numbers you found on a random blog. Size for memory, size for your largest realistic payload, put Postgres in from day one, and only reach for queue mode when executions are actually backing up. Do that and your self hosting cost stays exactly as low as n8n's own architecture allows it to be.