How Much RAM to Reserve for n8n When Hosting Other Apps

Reserve 1 GB of RAM for n8n as a practical working minimum when it shares a server with other apps, 2 GB once your workflows handle files, images, or large API responses, and roughly 500 MB extra per additional worker if you run queue mode. That figure sits on top of everything else on the box: around 400 to 500 MB for a Linux OS plus Docker, whatever your websites and databases need, and about 20% of total RAM left free as headroom for spikes. On a 4 GB VPS, a realistic split is 1 GB n8n, 500 MB OS and Docker, 700 MB for Postgres and Redis, 1 GB for a small WordPress site or two, and the rest untouched. n8n idles at only a few hundred megabytes, so the number you reserve is really about surviving the peaks, not the average.

n8n sits quietly at 200 to 400 MB, then spikes hard during a run

A freshly started n8n container on Docker typically holds somewhere around 200 to 400 MB of resident memory with nothing running. That's the Node.js process, the editor UI, and the internal scheduler doing very little. If all you ever look at is docker stats on an idle server, you'll conclude n8n is tiny and give it 512 MB.

Then a workflow fires.

n8n is a Node.js app, and it keeps the data moving between nodes in memory. Every item that passes from one node to the next lives in the heap until the execution finishes. Pull 20,000 rows from an API, and that whole array sits in RAM while the next node chews through it.

Download a 40 MB PDF attachment and, with default settings, that binary data goes into memory too, base64 encoded, which inflates it by roughly a third.

This is why the same n8n install can idle at 300 MB on Monday and get killed by the kernel on Tuesday. The average tells you almost nothing. The peak is the number that matters, and the peak is set by your workflows, not by n8n itself.

Two other things push the peak up. Parallel executions each get their own slice of memory, so five webhooks arriving at once cost roughly five times one webhook. And error retries can stack: a failed run that retries three times while the original data is still held can triple the footprint for a few seconds.

Note: n8n's own documentation doesn't publish a single official RAM figure that covers every install, because consumption depends entirely on what your workflows move around. The numbers in this article are planning figures based on how the Node process behaves, not vendor-guaranteed minimums. Check the n8n self-hosting documentation for the current environment variables and hosting notes.

How much RAM to reserve for n8n depends on which of four tiers your workflows land in

Rather than one number, sort your setup into a tier. I've written these as "reserve," meaning the amount you hold back for n8n alone on a shared server, excluding OS, database, and other apps.

Most people reading this land in the second row. If you're running a business automation stack alongside a couple of client sites, 1 GB reserved for n8n is the figure I'd plan around, with 2 GB swap configured so a one-off spike gets absorbed instead of killing the process.

The binary-data tier is where budgets blow up. A single workflow that fetches invoices from Gmail, merges them, and uploads them to Drive can touch several hundred megabytes for one execution. Run that on a schedule while a WordPress site is serving traffic on the same 2 GB VPS, and something is getting killed.

Can n8n run on 512 MB or 1 GB of total server RAM?

n8n itself will start on a 1 GB server. Whether it stays up is a different question. On a 1 GB VPS you're fitting the OS, Docker, n8n, and SQLite into the same space, which leaves n8n roughly 400 to 500 MB of real working room.

That's enough for scheduled workflows with tiny payloads and a single user poking at the editor.

What you cannot do on 1 GB is run n8n plus Postgres, plus a website, plus anything else. And you shouldn't try queue mode there at all, since queue mode needs Postgres and Redis running alongside. If your plan involves other apps on the same machine, 4 GB is where things stop being a constant fight, and it's the entry point on most decent VPS plans anyway.

Budget the whole server first, then hand n8n what's left over

The mistake I see repeated in forums is picking n8n's number in isolation. Work top-down instead. Here's the arithmetic I use, and it takes about two minutes on paper.

1. Start with total server RAM. Whatever the plan actually gives you, not what the marketing page rounds to.
2. Subtract OS and container overhead. Budget 400 MB for a minimal Ubuntu or Debian install with Docker running. Add another 100 MB if you have Portainer, a reverse proxy like Nginx Proxy Manager or Traefik, and a monitoring agent.
3. Subtract your database. Postgres with default settings sits around 150 to 300 MB in light use; SQLite costs almost nothing beyond n8n's own process. Redis for queue mode adds 50 to 150 MB unless you're storing a lot.
4. Subtract your other apps. A small WordPress site with PHP-FPM and MariaDB realistically wants 1 GB to behave. A Node or Python API might be 200 to 500 MB. A Ghost blog, around 400 MB.
5. Hold back 20% of the total as headroom. On 8 GB, that's 1.6 GB you don't allocate to anything. This is what absorbs traffic spikes, backup jobs, and package updates.
6. What's left is n8n's ceiling. Compare it to the tier table above. If the leftover is under your tier's figure, either trim the workflows or move up a plan size.

Worked examples on 4 GB, 8 GB, and 16 GB

4 GB VPS, n8n plus one small WordPress site. OS and Docker 500 MB, MariaDB 400 MB, PHP-FPM and Nginx 600 MB, Postgres for n8n 250 MB, headroom 800 MB. That leaves roughly 1.4 GB for n8n. Comfortable for tier two, workable for light binary jobs if you switch binary storage to the filesystem.

8 GB VPS, n8n plus three WordPress sites plus Uptime Kuma. OS, Docker, and a reverse proxy 700 MB, three sites at 900 MB each is 2.7 GB, monitoring 150 MB, Postgres 400 MB, headroom 1.6 GB. n8n gets about 2.4 GB. Enough for attachments, PDF generation, and a second worker.

16 GB VPS, n8n in queue mode plus a client site and a staging copy. OS and Docker 800 MB, two sites 2 GB, Postgres 800 MB, Redis 200 MB, headroom 3.2 GB. That leaves around 9 GB, which supports a main instance at 2 GB and four workers at 1 GB with room to spare. This is the point where n8n stops being the constraint and CPU becomes the thing you watch.

Notice that in all three cases n8n is not the biggest consumer. WordPress usually is. If your server is already slow before n8n arrives, adding RAM for n8n won't fix it, and the cause is often something else entirely, which is worth ruling out first if you've been chasing a sluggish WordPress install for weeks.

How much RAM do queue mode workers actually need?

Queue mode splits n8n into a main instance that handles the editor, webhooks, and scheduling, plus one or more worker processes that execute the workflows. It needs Redis for the job queue and Postgres as the database, so the baseline cost of switching is higher than a single instance.

Each worker is its own full Node process, so it carries the same 200 to 300 MB idle floor as the main instance, plus whatever the workflows it runs consume. Budget 500 MB per worker for light jobs and a full 1 GB per worker if those jobs handle files. Two workers at 1 GB each is a reasonable starting shape on an 8 GB box.

Set a concurrency limit per worker rather than letting each one grab unlimited parallel jobs. n8n exposes N8N_CONCURRENCY_PRODUCTION_LIMIT for this, and capping it at something like 5 or 10 per worker gives you a predictable memory ceiling instead of a lottery. Check the current documentation for the default value in your version before you assume it's already capped.

Note: queue mode won't reduce your total RAM bill. It spreads execution across processes so one heavy workflow can't take down the editor, and it lets you scale horizontally later. If you're on a single 4 GB VPS, a single instance with sane settings is the better use of the memory you have.

Four changes that cut n8n's memory use before you pay for more RAM

Before upgrading the plan, work through these. On a real install I'd expect them to knock a meaningful chunk off peak usage, and the first one alone often solves a recurring out-of-memory problem.

Move binary data to the filesystem. By default, n8n keeps binary data in memory during an execution. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem writes it to disk instead, which takes file size out of the RAM equation almost entirely. If your workflows touch attachments at all, this is the single highest-value change on the list.

Disk is cheaper than memory on every VPS plan I've seen, and it pairs well with keeping an eye on sensible upload limits elsewhere on the server.

Prune old execution data. n8n stores every execution's data, and on SQLite in particular that database grows until queries get slow and memory use creeps up with them. EXECUTIONS_DATA_PRUNE=true with a maximum age set turns on automatic cleanup. Look up the current default retention window in the docs rather than guessing, then shorten it if you don't need weeks of history.

Cap payload size and batch your loops. N8N_PAYLOAD_SIZE_MAX limits how large an incoming request body can be, which stops a rogue webhook from trying to load something enormous. Inside workflows, the Loop Over Items node lets you process 100 or 500 records at a time instead of pulling 50,000 into memory at once. Splitting a big sync into batches is usually the difference between a workflow that finishes and one that dies at 80%.

Raise the Node heap limit deliberately, and set a container limit too. If you see heap allocation errors, NODE_OPTIONS=--max-old-space-size=2048 gives Node permission to use 2 GB of heap. That's a permission, not a reservation, so don't set it higher than the RAM you actually have free or you'll trade a clean n8n error for a kernel OOM kill that takes other containers with it. In Docker Compose, add a memory limit on the n8n service so a runaway execution can't starve your websites.

There's a fifth, less technical one: write down which of these you changed and why. Six months later, when a workflow starts failing, past-you will have forgotten the whole setup. Keeping short setup notes in a consistent format has saved me more debugging hours than any monitoring dashboard.

When n8n runs out of RAM, it usually dies silently rather than throwing an error

Recognising the symptoms saves a lot of guesswork. There are two distinct failure modes and they look different.

The first is a Node heap error. The execution fails and the log shows something about a JavaScript heap out of memory or an allocation failure. n8n is still alive, the editor still loads, and the failed execution appears in the list. This one is fixable with --max-old-space-size and batching.

The second is the Linux OOM killer. The kernel decides the machine is out of memory and terminates the process using the most of it, which is often n8n. In Docker you'll see the container exit with code 137, and docker ps -a shows it as recently restarted.

Nothing useful appears in the n8n logs because the process never got a chance to write anything. Run dmesg | grep -i oom on the host to confirm what got killed and when.

The nasty version is when the kernel picks something else. Your MySQL container goes down, a client site starts throwing database connection errors, and you spend an afternoon debugging WordPress when the actual cause was an n8n workflow processing a spreadsheet. Per-container memory limits prevent exactly this, which is why I listed them above.

Watch for a slower warning sign too: heavy swap use. If free -h shows swap filling up while your sites feel treacly, the server is over-allocated. Swap stops crashes, but reading from NVMe instead of RAM is orders of magnitude slower, and a workflow that normally takes 8 seconds might take 90.

Swap is insurance for spikes, not a substitute for the RAM you should have bought.

Before any of this troubleshooting, confirm your backups are actually running and that you know how far back they reach. Recovering from a corrupted SQLite file after an abrupt kill is much less stressful when you've checked how long your snapshots are kept in advance.

Common mix-ups about n8n memory planning

Mix-up: n8n is lightweight, so 512 MB is plenty even with other apps on the box.

Reality: the idle figure is genuinely small, but memory use scales with the data your workflows move, not with n8n's install size. A single workflow pulling a large dataset or handling one PDF can multiply the footprint several times over for the duration of the run.

Mix-up: switching to queue mode reduces RAM requirements.

Reality: it increases them. You add Redis, you must use Postgres, and every worker is a separate Node process with its own baseline. What queue mode gives you is isolation and the ability to scale out, which is a reliability win, not a memory saving.

Mix-up: the RAM figure on a VPS plan page is all available to your apps.

Reality: the OS, Docker, your reverse proxy, and your database eat into it before n8n sees anything. On a 2 GB plan, expect 1.2 to 1.4 GB of genuinely usable memory once the base stack is running.

Mix-up: CPU doesn't matter for n8n as long as RAM is sufficient.

Reality: Node is single-threaded per process, so one heavy workflow saturates one core. With two vCPUs shared between n8n, Postgres, and a couple of PHP sites, executions queue up behind each other and everything feels slow even with free RAM showing. Two cores is a floor, and four is where a mixed workload starts breathing.

What this means for your server choice

If you're planning a box that runs n8n alongside websites, 4 GB and 2 vCPUs is the honest entry point, 8 GB is where it stops being tight, and 16 GB is for queue mode with multiple workers or a genuinely busy automation stack. Reserving 1 GB for n8n on a 4 GB server works, provided you switch binary data to the filesystem, prune execution history, and configure swap.

Shared hosting is off the table for this, since you need Docker or Node and full control of processes, which is exactly the point where a VPS becomes necessary. A KVM-based VPS gives you dedicated RAM rather than a burstable allowance, and that distinction matters a lot for a process that spikes. Hostinger's VPS range at the time of writing starts at 4 GB on KVM 1, moves to 8 GB on KVM 2 and 16 GB on KVM 4, and their VPS dashboard includes an n8n template among the one-click options, which saves you the Docker Compose setup.

Confirm the current specs and template list on the plan page before you buy, since those change.

One thing worth deciding early: whether n8n shares a server with client sites at all. If a workflow bug can take down a paying client's website, that risk might not be worth the saving. Two smaller VPS instances often beat one bigger one for peace of mind, and it also makes routing cleaner if you're already running services on subdomains.

If a VPS is the direction you're heading, grab a Hostinger VPS plan with coupon code hHostCouponHub for up to 85% off, and pick the 8 GB tier if your workflows touch files at all. The price gap between 4 GB and 8 GB on a longer term is smaller than the time you'll spend fighting memory limits.

Frequently asked questions

How much RAM does n8n use when idle?

Around 200 to 400 MB for a single Docker container doing nothing but running the editor and scheduler. Add roughly the same again for each queue-mode worker you start, since every worker is a separate Node process with its own baseline.

Can I run n8n on a 2 GB VPS with other apps?

You can run n8n on 2 GB with one small companion app, like a static site behind Nginx or a lightweight monitoring tool. Adding WordPress with its own database to a 2 GB box alongside n8n leaves both fighting for the same few hundred megabytes, and one of them will get killed under load. Set binary data to filesystem mode and add 2 GB of swap if 2 GB is your only option.

Do I need PostgreSQL, and how much RAM does it add?

n8n uses SQLite by default, which is fine for personal use and costs almost nothing extra in memory. Postgres is recommended for production and required for queue mode, and it typically adds 150 to 300 MB in light use with default settings, more if you raise shared_buffers. The official PostgreSQL project documents the tuning parameters if you want to cap it deliberately.

Should n8n get its own server or share with my websites?

Share when you're self-hosting for personal or internal use and can tolerate a restart. Give n8n its own instance when client sites are on the line, when workflows regularly handle large files, or when you're running multiple workers. Separation also simplifies upgrades, since an n8n version bump can't affect anything else, and it's the same reasoning behind isolating heavier WordPress management tooling onto its own resources.

Work out your leftover figure using the six-step budget above, match it against the tier table, and buy the plan that clears your number with 20% spare rather than the one that barely fits. If you want the setup done in a few clicks instead of by hand, Hostinger's VPS plans with code hHostCouponHub include an n8n template and enough dedicated RAM at the 8 GB tier to run your automations and your sites without either one getting killed.

This page contains affiliate links. If you purchase through the links on this page, we may earn a commission, at no extra cost to you.