KVM 1 Limits: How Many Workflows Before It Slows Down?

A Hostinger KVM 1 VPS (1 vCPU core, 4 GB RAM, 50 GB NVMe storage) will hold somewhere around 10 to 20 light automation workflows without any real slowdown, and plenty of people run 30 or 40 mostly-idle ones on it, because the number stored in n8n barely matters. What actually decides the ceiling is how many of those workflows fire at the same moment and how heavy each execution is: one AI agent workflow pulling a 20 MB PDF through an LLM node can peg that single core harder than 40 schedule triggers that ping a webhook once an hour. Neither Hostinger nor n8n publishes an official “max workflows” figure, so the numbers here come from resource math on KVM 1’s specs plus the failure patterns that show up consistently on 1-core boxes.

If your workflows involve headless browsers, video processing, or more than two or three concurrent executions, KVM 1 is the wrong plan and KVM 2 is the honest starting point.

The real limit on KVM 1 is concurrent executions, not the number of workflows you save

Saved workflows sitting inactive cost you almost nothing. n8n loads them from the database when they run, and an inactive workflow is a row in a table. You could have 200 of them saved on KVM 1 and the server wouldn’t blink. That’s why “how many workflows” is a question with a slightly awkward answer: the count people worry about isn’t the count that breaks things.

What consumes CPU and RAM is an execution. Every time a workflow runs, n8n spins up work in the Node.js process, holds the data from each node in memory, and writes execution history to the database when it finishes. Two executions at once on a single core means the core time-slices between them.

Ten at once and everything crawls.

So a more useful way to size KVM 1 is by execution profile. Here’s what I’d plan for, based on 1 vCPU and 4 GB RAM:

Those are working estimates, not vendor numbers. The point is that the profile column matters ten times more than the count column.

Note: these figures assume n8n is the only meaningful thing on the box. Stack a WordPress site, a database for something else, and a Docker registry on the same KVM 1, and cut every number above roughly in half.

What counts as one workflow?

n8n counts a workflow as one canvas, however many nodes it contains. A 40-node workflow with three branches is still one workflow, and it will hammer your KVM 1 far harder than five 4-node workflows. If you’re trying to size a server, count nodes and data volume, not canvases.

Sub-workflows complicate this too. A parent workflow calling a sub-workflow with the “Execute Sub-workflow” node creates a second execution record, and in the default setup that sub-execution runs in the same process. Ten parent runs each calling two sub-workflows is thirty executions on the books, not ten.

KVM 1’s 1 vCPU and 4 GB RAM are what set the ceiling

Hostinger’s entry VPS plan gives you 1 vCPU core, 4 GB RAM, 50 GB NVMe disk, and 4 TB of monthly bandwidth. Specs and plan names do change, so check Hostinger’s VPS page for the current numbers before you buy. Those four values map onto workflow capacity in fairly predictable ways.

The single core is the hard wall. n8n runs on Node.js, and Node handles one thing at a time per process. With one core there’s no second core to pick up the slack when a node starts crunching. A JSON transform over 10,000 items, a Code node doing string work, or a crypto/hash operation all block.

While that’s happening, your webhook responses queue behind it.

4 GB RAM is more generous than you’d expect, until one node isn’t careful. A rough budget on a fresh Ubuntu + Docker install: 400 to 700 MB for the OS and Docker daemon, 250 to 500 MB for the n8n container at idle, and whatever your executions need on top. That leaves a couple of gigabytes of headroom, which is fine for normal API work. The problem is that n8n holds all item data for a workflow run in memory.

Pull a 300 MB binary file through an HTTP Request node and it lives in RAM. Do that twice at once and the Linux OOM killer terminates the n8n process, which looks exactly like “my server crashed for no reason.”

50 GB of NVMe sounds like plenty and quietly isn’t. Execution history is the culprit. n8n stores the input and output data of every node for every run by default. High-frequency workflows with chunky payloads can add gigabytes a week to a SQLite database. I’ve seen small n8n boxes where the database file was the single biggest thing on the disk.

Pruning fixes it, and I’ll cover that further down.

4 TB of bandwidth is rarely the binding constraint for automation work, since API calls are small. It becomes relevant if your workflows move media files, in which case you’ll also want to think about how big those files get before they hit the server at all.

KVM 1 versus n8n’s own minimums

n8n’s self-hosting documentation puts the baseline for a small deployment well below KVM 1’s specs, so you’re not scraping the floor here. The n8n docs are worth reading on scaling because they draw the same line I would: the default single-process setup is for light use, and anything with real throughput wants queue mode with separate workers. Queue mode on 1 vCPU doesn’t help much, though.

Workers need cores.

Five things that decide how many workflows KVM 1 can handle before slowing down

Trigger overlap and cron collisions

This is the mistake I see most. Someone builds fifteen workflows, sets every schedule trigger to run “every hour,” and n8n dutifully fires all fifteen at the top of the hour. On one core, fifteen simultaneous executions means each one takes far longer than it did in testing, and the last one might not finish before the next hour’s batch starts.

Stagger them. One at :05, one at :12, one at :20. Same total work, a fraction of the peak load.

Polling triggers add background cost too. Every polling node wakes up on its interval and makes an API call whether there’s new data or not. Twenty workflows polling every minute is 28,800 wake-ups a day on a single core.

Webhooks cost nothing while idle, so prefer them when the service supports them.

Payload size per execution

Two hundred items of small JSON is nothing. Two hundred items where each carries a base64-encoded attachment is a memory event. The rule I use: estimate the largest single execution’s data volume, double it for n8n’s internal copies between nodes, and make sure that fits in your free RAM with room to spare.

On KVM 1, treat anything over 500 MB of in-flight data as a red flag.

Splitting helps. Split In Batches (Loop Over Items) with a batch size of 50 or 100 keeps peak memory flat regardless of how many records you’re processing, at the cost of a longer total runtime. On a 1-core box that trade is almost always worth taking.

AI, LLM, and agent nodes

Calling an external API like OpenAI or Anthropic is light on your CPU, since the model runs on their hardware. What isn’t light: the vector work, the text splitting, embedding batches, and the memory buffers an AI Agent keeps between turns. Chat workflows with a Postgres or Redis memory node also add database round trips per message.

Running a local model on KVM 1 is not on the table. Ollama with even a small quantised model wants more RAM than the whole plan has, and inference on one vCPU with no GPU is measured in minutes. If local inference is the plan, you’re shopping for a much bigger box.

Headless browsers and heavy binaries

Puppeteer, Playwright, and anything Chromium-based launches a full browser per run. That’s several hundred megabytes of RAM and a lot of CPU. One at a time on KVM 1 is survivable if you’re patient.

Two is where it falls over. Same story for FFmpeg conversions and large image manipulation. If scraping is central to your setup, run one workflow at a time with a concurrency limit, or use a hosted scraping API and let someone else’s servers do the lifting.

Execution history growth

Slowdown here is sneaky because it creeps in over weeks. The execution list in the UI gets slower to load, then the whole editor feels laggy, then workflows themselves slow down because every completed run writes a big blob into a database that’s now several gigabytes. SQLite in particular gets unhappy with concurrent writes at size.

Pruning and moving to PostgreSQL both fix it, and I’d do both on any n8n box that’s meant to run more than a handful of active workflows.

Signs your KVM 1 is already at its limit

You don’t need a monitoring stack to catch this. Hostinger’s hPanel shows CPU, RAM, disk, and bandwidth graphs for the VPS, and the browser terminal gets you onto the box in a few clicks. Here’s the sequence I run when someone says their workflows got slow:

1. Check load average with uptime. On 1 vCPU, a load average above 1.0 means the core has a queue. Sustained above 2.0 means everything is waiting.
2. Run free -h and look at swap. If swap is being used steadily rather than in brief spikes, RAM is the bottleneck and executions are being served off disk.
3. Run htop and sort by memory during a scheduled run. Watch the n8n process climb. If it approaches your total RAM, you’re one bad payload away from the OOM killer.
4. Check disk with df -h and du -sh on your n8n data directory. A database file in the multi-gigabyte range explains a laggy UI on its own.
5. Open n8n’s Executions list and look at durations for the same workflow over time. A run that took 4 seconds last month and takes 40 now is a resource problem, not a workflow problem.
6. Look for executions stuck in “running” or marked as unknown. Those are usually processes that died mid-run, which is the OOM killer’s signature.

The symptom order is fairly consistent: webhook responses get slow first, then scheduled runs start overlapping, then the editor becomes unpleasant, then something gets killed. If you’re already seeing the third symptom, don’t wait for the fourth.

Note: an n8n instance can also look slow when the problem is entirely external. A third-party API that went from 200 ms to 8 seconds will make your workflow durations balloon while CPU sits at 3%. Always check the per-node timings before blaming the server.

How to get more workflows out of KVM 1 before you upgrade

Most KVM 1 boxes I look at are running an untuned default install. There’s real headroom to reclaim. Do these in order:

1. Add a swap file. 2 GB is a sensible amount on a 4 GB box. It won’t make things fast, but it turns “n8n got killed” into “n8n got slow,” which is a much better failure to have at 3 a.m. Create it with fallocate, set permissions to 600, run mkswap and swapon, then add the entry to /etc/fstab so it survives a reboot.
2. Turn on execution data pruning. Set EXECUTIONS_DATA_PRUNE=true, then EXECUTIONS_DATA_MAX_AGE to the number of hours you actually want to keep (168 for a week) and EXECUTIONS_DATA_PRUNE_MAX_COUNT to cap the total. This one change fixes most mysterious gradual slowdowns.
3. Save less per run. In each workflow’s settings you can stop saving successful execution data while keeping failures. On chatty, high-frequency workflows that cuts database writes dramatically and you still keep the runs you’d need for debugging.
4. Move from SQLite to PostgreSQL. SQLite is the default and it’s fine for a dozen light workflows. Past that, PostgreSQL handles concurrent writes far better. Running it in a container on the same KVM 1 costs you 150 to 300 MB of RAM, which is usually a net win.
5. Cap concurrency. n8n supports a production concurrency limit via environment variable, so extra executions wait in line instead of piling onto the core all at once. On 1 vCPU, a limit of 2 or 3 keeps things responsive. Total throughput barely changes; the difference is that nothing times out.
6. Stagger every schedule. Spread cron triggers across the hour. Free, takes ten minutes, and often the single biggest improvement.
7. Push heavy steps off the box. Convert images with an external API, do the scraping with a scraping service, hand PDF generation to a third party. Let KVM 1 do orchestration, which is what it’s genuinely good at.
8. Set sensible timeouts. A workflow with no timeout that hangs on a dead API holds memory indefinitely. Workflow-level timeouts stop one stuck run from degrading everything else for hours.

While you’re in there, get your backup situation straight. Hostinger keeps automatic VPS snapshots on a rolling schedule, and it’s worth knowing how long those copies stick around before you start editing environment variables on a live box. Exporting your workflows as JSON to somewhere off-server takes two minutes and has saved me more than once.

When to stop tuning KVM 1 and move to KVM 2 or higher

Upgrade when any of these are true: you regularly need more than two or three executions running at the same time, a single execution routinely handles hundreds of megabytes, you’re running headless browsers as part of normal operation, you want to run queue mode with real workers, or the instance is doing paid work for clients and downtime costs money.

Rough guide to where the plans land for automation work:

Confirm the current vCPU and RAM per plan on Hostinger’s own page, since plan configurations get revised.

Hostinger’s VPS upgrades are in-place, so you keep your data and your IP and take a short reboot rather than rebuilding from scratch. That’s a genuine advantage of starting on KVM 1: an undersized plan is a temporary problem, not a migration project. The reasoning behind that first move up from cheaper hosting is much the same logic I’ve laid out for outgrowing a shared plan, where the trigger is contention rather than raw capacity.

One more thing worth saying plainly: if your workflows are mostly triggered by web forms on a site you also host, keep the site and the automation on separate boxes if you can. A traffic spike on the site shouldn’t be able to starve your automations, and a runaway workflow shouldn’t take the site down. People who’ve fought a WordPress install that mysteriously crawls will recognise the pattern.

Things people get wrong about KVM 1 and workflow limits

Mix-up: More workflows saved in n8n means a slower server.

Reality: Inactive workflows cost effectively nothing. A hundred saved and switched off will not slow KVM 1 down. Two active ones firing every minute with big payloads absolutely will.

Mix-up: 4 GB of RAM means a workflow can process a 4 GB file.

Reality: n8n keeps item data in memory and copies it between nodes, so peak usage runs well above the file size, and the OS and Docker have already claimed a chunk. Treat 500 MB of in-flight data as your practical ceiling on this plan and stream or batch anything larger.

Mix-up: Switching n8n to queue mode fixes a slow KVM 1.

Reality: Queue mode splits work across worker processes, and workers need cores to run on. On 1 vCPU you’ve added Redis and extra processes to the same single core. Queue mode pays off on KVM 4 and up.

Mix-up: A slow n8n instance always means the plan is too small.

Reality: Unpruned execution history, an untimed-out workflow, or a slow external API cause the majority of “it got slow” reports I see on entry VPS plans. Rule those out before you spend money.

What this means for you

If you’re learning n8n, automating your own business, or running a handful of client automations that fire a few hundred times a day, KVM 1 is enough and you shouldn’t overthink it. Turn on pruning, add swap, stagger your schedules, and keep an eye on the RAM graph in hPanel. That setup will carry you a long way.

If your plan involves AI agents on large documents, browser automation, or a busy webhook endpoint that other people depend on, start on KVM 2. The difference in monthly cost is small next to the time you’d spend fighting an undersized box, and the second core is what stops one heavy execution from freezing everything else.

Either way, the setup path is the same. Hostinger’s VPS templates include a one-click n8n option, which puts Docker and n8n on the box for you and saves an hour of terminal work. Verify the template list is current when you order, and if you’re pointing a domain or subdomain at the instance for webhook URLs, running it on a subdomain keeps things tidy, with an SSL certificate on top so incoming webhooks arrive over HTTPS.

Check current KVM 1 and KVM 2 pricing on Hostinger and apply the code hHostCouponHub at checkout for up to 85% off, with the discount and terms shown on the order page before you pay.

Frequently asked questions

How many n8n workflows can 1 vCPU actually run at once?

Plan on two or three concurrent executions on a single vCPU before response times noticeably degrade, and one at a time for anything involving a headless browser or large file. Set n8n’s production concurrency limit to enforce that so extra runs queue instead of competing for the core.

Is KVM 1 enough for n8n in production?

For light, low-concurrency automations with pruning enabled, yes. For anything other people rely on during business hours, KVM 2 is the more sensible floor because the second core means a single heavy execution can’t lock up your webhook endpoint.

Why did my n8n container stop running on KVM 1?

The usual cause is the Linux OOM killer terminating the process after a workflow pulled too much data into memory. Add a 2 GB swap file, batch large data sets with Loop Over Items, and check dmesg for kill messages to confirm.

Will more RAM or more CPU help my workflows more?

More CPU, in most cases. Workflow slowdown on KVM 1 usually shows up as a queued core rather than exhausted memory, so a second vCPU makes a bigger difference than extra gigabytes. RAM matters more if your workflows move large files or binaries.

How do I stop my n8n database from filling the 50 GB disk?

Set EXECUTIONS_DATA_PRUNE=true with a max age and max count, and turn off saving data for successful executions on your high-frequency workflows. Check the size of your n8n data directory monthly with du -sh so growth doesn’t surprise you.

If you’re starting fresh, deploy on the plan that matches your heaviest workflow rather than your average one, keep a copy of your setup notes somewhere outside the server (the same documentation habits that pay off with any hosting apply here), and remember the upgrade is a reboot away. Start your VPS with the hHostCouponHub code applied and size up later if your execution graph says you need to.

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.