How Many vCPU Cores Do Your n8n Workflows Actually Need

For most self-hosted n8n setups, 2 vCPU cores handle somewhere between 50 and 150 active workflows, though the honest answer is that workflow count is a weak predictor on its own: what actually eats CPU is execution frequency, the number of nodes per run, and whether those runs overlap. A single workflow polling an API every minute with heavy data transformation can pin a core harder than 80 workflows that fire once a day on a webhook. n8n's own documentation recommends a minimum of 2 CPU cores for self-hosted queue-mode deployments, and in practice a 2-core, 4GB box comfortably runs a few hundred low-frequency workflows, while teams pushing thousands of executions per hour typically move to 4 to 8 cores split across a main instance and separate workers. Below, I'll break down how to size this properly using concurrent executions rather than raw workflow count, with real numbers you can test against.

Workflow count is the wrong number to size your server on, and here's what to use instead

An n8n workflow sitting in your instance and doing nothing costs you almost no CPU. It's a row in a database and, if it's active, either a registered webhook path or an entry in the scheduler. That's it.

The CPU cost arrives the moment a workflow executes.

So the number that matters is concurrent executions, meaning how many workflow runs are happening at the same instant, multiplied by how much work each one does.

Here's the mental model I use when sizing a box:

Executions per hour × average execution duration ÷ 3600 = average concurrent executions

If you run 600 executions an hour and each takes 3 seconds, that's 1800 seconds of work spread over 3600 seconds. Average concurrency of 0.5. One core handles that with room to spare.

But averages hide spikes. If all 600 of those fire in a 5-minute window because they're all on a 0 * * * * cron, your real peak concurrency is closer to 30, and now you have a queue problem, not a CPU problem.

n8n is a Node.js application, and Node runs your workflow logic on a single thread per process. One n8n process uses roughly one core for JavaScript execution regardless of how many cores you throw at the machine. Extra cores only help when you run multiple processes: worker containers in queue mode, or multiple main instances behind a load balancer.

That single fact reshapes the whole sizing question. Adding cores to a single-process n8n install past 2 gives you diminishing returns fast.

Note: Node.js does use a libuv thread pool for filesystem and some crypto operations, so extra cores aren't entirely wasted on a single process. But your workflow's own logic, the Code nodes, the expression evaluation, the JSON handling, all runs on one thread.

A practical sizing table for n8n workflow count vs vCPU core requirement

These are working baselines I'd hand to someone spinning up a first instance. Treat them as starting points to load-test against, not guarantees, because a single badly written Code node can invalidate any of them.

Notice that the workflow count column and the CPU column don't move in lockstep. The bottom row has fewer workflows than the row above it and needs more hardware. That's the whole point.

RAM tends to become your constraint before CPU does in real deployments. Every execution holds its item data in memory, and n8n passes the full data set between nodes. Pull 50,000 rows from a database and map them through five nodes, and you're holding multiple copies of that payload.

I've watched instances with plenty of idle CPU get killed by the OOM reaper. If you're planning around big payloads, read up on sensible upload limits before you architect anything that shovels large files around.

What actually drives CPU load in an n8n instance

Four things, roughly in order of impact.

Execution frequency and trigger type

Schedule Triggers set to short intervals are the quiet killer. A workflow on a one-minute cron runs 1,440 times a day. Twenty of those and you're at 28,800 executions daily from twenty workflows.

Meanwhile a hundred webhook-triggered workflows might sit at zero executions for hours.

Polling triggers deserve special mention. Nodes that check an external service for new data (some integrations poll rather than receive webhooks) wake up on a schedule, make an HTTP request, compare results, and usually do nothing. Cheap individually, expensive at volume.

If a service offers a webhook, use the webhook.

Node count and node type per execution

An execution with 4 nodes costs a fraction of one with 40. But node type matters more than count. Ranked from cheapest to most expensive in my experience:

1. Set, IF, Switch, NoOp nodes: negligible, pure in-memory logic.
2. HTTP Request and API integration nodes: mostly waiting on network I/O, so low CPU but they hold memory and an event-loop slot for the duration.
3. Code nodes: run real JavaScript. A loop over 10,000 items with string operations inside will chew a core.
4. Item Lists, Split Out, Merge, Aggregate on large data sets: heavy JSON manipulation, and the cost scales with item count.

The pattern that burns the most CPU per execution is a Code node doing per-item work inside a loop over thousands of items. Running Code in "Run Once for Each Item" mode on 5,000 items means 5,000 separate function invocations.

Data volume per execution

n8n moves data between nodes as arrays of JSON objects. Every node receives the incoming array and outputs a new one. Serializing, deserializing, and copying large arrays is CPU work on top of the memory cost.

A workflow processing 100 items and one processing 100,000 items can be identical on paper and differ by two orders of magnitude in resource use. This is why I always ask about payload size before recommending a plan.

Concurrency and queue mode

In regular mode, n8n runs executions in the main process. Under load, executions stack up on one event loop and everything slows down together. In queue mode, the main instance handles webhooks and the editor UI while separate worker processes pull jobs from a Redis queue.

Each worker is its own Node process, so each can use its own core.

Queue mode is where extra vCPUs finally pay off. n8n's official scaling documentation covers the setup, and the short version is: one worker per available core, minus one core reserved for the main instance and the database.

Note: Queue mode requires Redis and adds real operational complexity. Below roughly 500 executions per hour, it's usually not worth the extra moving parts.

How to figure out your own core requirement in six steps

This is the process I'd run on a real deployment rather than guessing from a table.

1. Count your actual executions, not your workflows. Open the Executions list in n8n and filter by the last 24 hours. Note the total and, more importantly, when the clusters happen. If you're on a version with execution data retention limits, check what window you're actually seeing.

2. Record average and worst-case duration. The Executions view shows run time per execution. Find your slowest recurring workflow and treat that duration as your planning number, not the average. One 90-second workflow that runs every 5 minutes occupies far more of your event loop than the average suggests.

3. Calculate peak concurrency. Take your busiest 60-second window, count how many executions started in it, and multiply by average duration in seconds, then divide by 60. If that number is above 1, a single-process instance is already queuing work.

4. Watch real CPU during a peak. SSH in and run top or htop while your heaviest cron fires. Watch the n8n process specifically. If it sits above 80% of a single core during peaks, you need queue mode with workers, not a bigger single instance. Warning: run this on a staging copy if you can, since attaching a profiler or running heavy monitoring on a production instance during a load spike can push it over.

5. Add 40% headroom for RAM, less for CPU. CPU spikes are survivable and self-correcting; the queue drains. Memory spikes get your process killed. Whatever peak memory you measure, budget noticeably above it.

6. Test with a synthetic burst before you commit to a plan. Build a throwaway workflow that fires your typical payload 100 times in a minute, run it, and watch the box. Ten minutes of testing here saves a month of paying for the wrong tier.

Regular mode vs queue mode: which one your workflow count actually calls for

The split isn't about how many workflows you have. It's about whether your executions overlap.

Regular mode runs everything in the main n8n process. Simpler to deploy, one container, no Redis. Fine for the vast majority of people self-hosting for their own business. 2 vCPU and 4GB carries this a long way.

Queue mode separates the main instance from workers. You get true parallelism, the ability to scale workers independently, and resilience: a worker crash doesn't take down your webhooks or your editor.

Pick queue mode when any of these is true:

• Peak concurrency regularly exceeds 1 or 2 executions at once
• You have long-running workflows (30+ seconds) that block shorter ones
• Webhook response times are degrading during scheduled job bursts
• You need executions to survive a restart of the main process

Pick regular mode when your executions are sparse, short, and don't collide. Which describes most setups honestly.

There's a middle option people forget: staying in regular mode but fixing the workflows. Staggering cron schedules across the hour instead of stacking them all on :00, batching API calls instead of looping per item, and turning off "save execution data" for high-frequency runs that don't need auditing. I've seen those three changes cut CPU load by more than half without touching the hardware.

Cheaper than a plan upgrade every time.

Common mix-ups about sizing an n8n server

Mix-up: More vCPUs make n8n faster.

Reality: A single n8n process is bound to one thread for workflow logic. Going from 2 to 8 cores on a single-container install changes very little. You need multiple worker processes to use those cores, which means queue mode.

Mix-up: 500 workflows means you need a big server.

Reality: 500 inactive or webhook-only workflows can idle happily on 1 vCPU. Activation cost is near zero. It's executions that cost money.

Mix-up: n8n Cloud plans are priced by workflow count, so self-hosting must scale the same way.

Reality: n8n Cloud tiers are built around execution allowances and active workflow limits, which is a billing decision, not a hardware one. Self-hosted has no workflow cap at all; your only ceiling is your server. Check n8n's pricing page for the current Cloud tier details, since those change.

Mix-up: Memory and CPU scale together.

Reality: They diverge badly. Data-heavy workflows are memory-bound with idle CPU. Tight Code loops are CPU-bound with modest memory.

Size for whichever your workload actually stresses.

When to move from shared hosting to a VPS for n8n

Shared hosting isn't a real option for n8n. It's a persistent Node.js application that needs a long-running process, its own port, Docker or Node installed, and typically a PostgreSQL database. Shared plans don't give you that level of access.

So the practical entry point is a VPS. The tiers I'd map to workload:

1 vCPU, 1, 2GB RAM. Testing and personal use. It runs, and n8n will boot with SQLite. Expect trouble the moment you process a large data set, and don't run PostgreSQL on the same box at this size.

2 vCPU, 4GB RAM. The realistic starting point for anything you depend on. Room for n8n plus PostgreSQL in separate containers, and headroom for a few hundred moderate executions per hour. This is where most self-hosters should begin.

4 vCPU, 8GB RAM. Queue mode with two workers, or a single instance running genuinely heavy workflows. Agency territory.

8 vCPU, 16GB+ RAM. Four or more workers, thousands of executions hourly, large payloads. At this point you're also thinking about a separate database host.

Hostinger's VPS lineup covers all of these, and their KVM plans include an n8n template that handles the Docker setup for you, which removes a genuine hurdle if you haven't run Docker Compose before. If you're still weighing whether the jump makes sense at all, the trade-offs in moving off a shared plan apply directly here.

One thing worth verifying before you buy anywhere: whether the vCPUs are dedicated or shared. On oversubscribed shared-CPU plans, your available compute varies with what neighbours are doing, and steal time will make your n8n executions unpredictable in ways that look like application bugs. Check top for the st value if executions get randomly slow.

Reducing your core requirement instead of buying more

Before you upgrade, there's usually 30 to 50% of headroom sitting in your configuration.

Turn off execution data you don't need

By default n8n saves data for successful executions. On high-frequency workflows that's constant database writes and storage growth. You can set success executions to not save, or save errors only, per workflow in the workflow settings.

Keep full logging on the workflows you actually debug.

Stagger your schedules

If eight workflows all run hourly, don't leave them all on minute zero. Spread them: minute 0, 7, 14, 21, and so on. Same total work, flattened peak, dramatically better behaviour on a small box.

Batch instead of loop

Two hundred separate HTTP requests inside a loop cost far more than one request with a batched payload, when the API supports it. The Loop Over Items node with a sensible batch size also stops you holding every item in memory at once.

Prune your execution history

Old execution records bloat your database, and a bloated database makes every query slower, including the ones n8n runs constantly. n8n supports pruning via environment variables (EXECUTIONS_DATA_MAX_AGE and related settings). Setting a retention window of 7 to 30 days is sensible for most people. Verify the exact variable names against the current docs, since configuration names have shifted between major versions.

Move heavy lifting out of Code nodes

If you're doing serious data transformation, it's often cheaper to push that work to the source: a SQL query that aggregates before returning rows, or an API endpoint with proper filtering. Fewer items entering n8n means less CPU and less memory throughout the run.

Use PostgreSQL, not SQLite

SQLite is fine for testing. Under concurrent execution writes it becomes a bottleneck because of write locking. Switch to PostgreSQL before you scale up.

Same principle as any production app; if you've dealt with a sluggish WordPress install, the database layer is nearly always involved.

What this means for you

If you're starting out, buy 2 vCPU and 4GB, run in regular mode with PostgreSQL, and measure for two weeks. That covers a genuinely large share of real-world n8n use, and you'll have actual data instead of a guess when it's time to decide about more.

If you're already running and hitting limits, resist the instinct to buy cores. Check whether your executions overlap first. If they don't, more cores won't help and the fix is in your workflows or your schedules.

If they do overlap, go to queue mode and add one worker per spare core.

If you're planning something high-volume from day one, thousands of executions per hour or large data payloads, start at 4 cores with queue mode and expect to scale workers as you learn your real concurrency. Also sort out backups early: n8n holds your credentials and workflow definitions in its database, and losing that is a bad afternoon. Knowing how far back your restore points go matters more than most people realise until they need it.

If your n8n instance will be reachable over the public internet for webhooks, put it behind HTTPS with a valid certificate. Webhook payloads frequently carry API keys and customer data, and running them over plain HTTP exposes all of it in transit. Most hosts include free Let's Encrypt certificates, and it's worth confirming what your provider offers around certificate provisioning before you point a production webhook at the box.

Ready to size a box properly? Grab a Hostinger VPS with 85% off using code hHostCouponHub and pick a plan that matches the numbers above rather than guessing.

Frequently asked questions

How many vCPU cores does n8n need as an absolute minimum?

n8n runs on 1 vCPU with 1, 2GB RAM for light personal use, and the docs list 2 CPU cores as the minimum for a queue-mode setup. For anything you rely on, start at 2 cores and 4GB so you have room for PostgreSQL and occasional spikes.

Can 2 vCPU cores handle 500 n8n workflows?

Yes, if those 500 workflows execute infrequently or are triggered by webhooks that arrive spread out. Active-but-idle workflows cost almost nothing. The same 2 cores will struggle badly with 20 workflows if they run every minute with heavy data processing.

Does n8n use multiple CPU cores automatically?

No. A single n8n process runs workflow logic on one Node.js thread. To use more cores you need queue mode with multiple worker processes, one per core, coordinated through Redis.

How much RAM do I need per n8n worker?

Budget 1, 2GB per worker as a baseline, and more if your workflows handle large data sets. Memory scales with items held in an execution, so a worker processing 50,000-row payloads may need 4GB or more on its own. Watch actual usage during a peak run rather than trusting a formula.

Is n8n Cloud cheaper than self-hosting on a VPS?

For low volumes, Cloud is often cheaper once you count your own time on updates, backups, and monitoring. Self-hosting wins on cost at higher execution volumes and gives you no workflow limit, but you own the maintenance. Check n8n's current pricing page, since tier allowances change.

Size the server to your execution pattern, not your workflow list, then buy the smallest plan that clears your measured peak with headroom. If you're setting one up this week, the discounted VPS plans with code hHostCouponHub take 85% off, and a 2-core, 4GB box is the sensible place to start.

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.