How Many Active Users Can Share One n8n KVM Instance?

Around 5 to 15 active users can share one n8n KVM instance running on 2 vCPU and 8 GB of RAM, where "active" means people who log in, build, and run automations during the same working hours. That band holds for normal automation work: API calls, CRM syncs, database rows, small JSON payloads, a handful of workflows firing at once. Load the same box with file processing, long AI prompts, or thousands of webhook hits an hour and it tops out nearer 3 or 4 people.

Step up to 4 vCPU and 16 GB with queue mode and Redis, and a single instance carries 30-plus builders without the editor going sluggish. What sets the ceiling is the number of executions running at the same time and how much data each one pulls through memory.

An n8n user costs the server almost nothing until their workflows start running

Someone logged into the editor is cheap. Dragging nodes, renaming things, reading node docs, expanding a JSON output panel: nearly all of that runs in the browser. The server hands over the workflow definition, saves it back, and answers a few API calls.

Ten people doing that at once barely moves the needle on a small KVM box.

Three kinds of load actually consume resources, and they scale very differently.

Production executions. Scheduled workflows and webhook triggers. These run whether anyone is logged in or not, so a "quiet" instance with 40 sleeping workflows can be busier at 3am than at 3pm.

Manual test runs. A builder clicking "Execute workflow" to check a change. These are the expensive ones per user, because n8n holds the full item data in memory and streams it to the browser so you can inspect every node's output.

Editor traffic. Loading canvases, saving, browsing execution history. Light on RAM, but it hits the database on every save and every history page.

That mix is why seat counts get misleading. Five analysts poking at small workflows all afternoon can be gentler on the box than one person running an hourly job that pulls 40,000 rows out of a warehouse.

What one active builder actually adds to the instance

A fresh n8n container idles in the low hundreds of megabytes of RAM. Each concurrent execution stacks on top of that, and the size depends almost entirely on how many items pass through the workflow and how big each item is.

For planning, I assume one active builder generates one or two concurrent runs during a busy stretch, plus whatever their production workflows are doing in the background. So "10 active users" often means 12 to 20 concurrent executions at peak, not 10.

Note: these are planning numbers, not published limits. n8n doesn't advertise a supported user count for self-hosted instances, because the workload varies too much between teams. Measure your own with docker stats before you size up.

If you're still weighing whether to leave a shared plan behind for something like this, n8n is one of the clearest cases for a VPS: it's a long-running Node.js process with real memory needs, and shared hosting won't run it at all.

RAM runs out before CPU on nearly every shared n8n box

Memory is the wall you hit first. n8n keeps the item data for a running workflow in memory so each node can pass it to the next one, and it keeps that data around for the execution's lifetime. Two or three large runs firing together can push a 4 GB box into swap, and once it swaps, the editor feels broken for everyone.

Rough peak RAM per concurrent run, by workload type:

Two settings change the file row dramatically. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem writes binary data to disk instead of holding it in memory, which is the single biggest win on a small instance. And N8N_PAYLOAD_SIZE_MAX caps incoming webhook payloads, defaulting to 16 MB in current releases.

Raising that cap raises your memory risk with it, so pair any change there with sensible upload limits on whatever is sending you data.

CPU behaves differently. The n8n main process is Node.js, so it runs on a single thread. One workflow never uses more than one core, no matter how many you buy.

Extra vCPUs buy you parallelism across runs, not speed within a run. A Code node crunching a big array blocks that thread while it works, which is exactly when other users report the UI hanging.

How much RAM does n8n need per active user?

For a team of light-to-moderate builders, I budget roughly 400 to 600 MB per active user on top of a 1 GB base for the container, the OS, and the database. That maths puts 8 GB at a comfortable 10 or so users, with headroom for one heavy run to spike without taking the instance down.

Add swap even if you don't plan to use it. A 2 GB swap file on a KVM 2 gives the kernel somewhere to go during a spike instead of the OOM killer terminating n8n mid-execution.

SQLite works for one person; a shared instance wants PostgreSQL

n8n defaults to SQLite, and it's fine for a single user testing things. Put five people on it and you start seeing slow saves and locking during writes, because SQLite serialises writes and n8n writes constantly: every execution start, every node finish, every history entry.

Switch to PostgreSQL before you invite the second or third user, not after. Migrating later means exporting workflows and credentials and rebuilding, which nobody enjoys on a Friday. Postgres on the same VPS is fine at this size; it needs maybe 300 to 500 MB of RAM for a small team.

While you're there, turn on execution pruning. The variables are EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE, and EXECUTIONS_DATA_PRUNE_MAX_COUNT. Without pruning, execution history grows until your 100 GB disk is the thing that fails, and a full disk on a shared instance takes everyone down at once.

Check n8n's docs for the current defaults in your version, since they've changed across releases.

Hostinger's KVM tiers line up with rough user bands

Each KVM plan maps to a realistic team size once you know your workload profile. Here's how I'd match them, based on the specs Hostinger lists at the time of writing:

KVM 2 is the sweet spot for most teams asking this question. It has enough memory that one careless workflow won't kill the instance, and enough CPU that the editor stays responsive while executions run.

Note: Hostinger changes plan specs and pricing periodically, and the numbers above are the listed resources, not a guarantee about n8n performance. Confirm the current specs on the VPS pricing page before you buy, and check how many restore points you get on the plan you pick. Credentials and workflows for a whole team are worth backing up properly.

One practical note on setup time: provisioning a KVM VPS takes minutes, and Hostinger keeps an n8n template in its application list, so you can have a working instance up before your coffee goes cold. That template is a starting point, though. It won't set your binary data mode, your pruning policy, or your Postgres connection for you.

Queue mode is what carries one n8n KVM instance past 15 active users

Queue mode is the answer once the default single-process setup starts stalling. In this mode, the main n8n process handles the editor, the API, and webhooks, then pushes execution jobs onto a Redis queue. Separate worker processes pick jobs off that queue and run them.

Two things improve immediately. The editor stops competing with executions for the same thread, so the UI stays quick even when the instance is busy. And you get real parallelism, because each worker is its own process on its own core.

The setup needs three pieces running together: n8n with EXECUTIONS_MODE=queue, a Redis instance, and PostgreSQL. Queue mode won't run on SQLite. n8n's self-hosting documentation covers the environment variables and the worker command, and it's worth reading the version that matches your release rather than a blog post from a year ago.

Sizing workers is straightforward. Give each worker one vCPU and budget its concurrency setting against your RAM. The worker's --concurrency flag defaults to 10 in current releases, which means up to 10 executions in one process.

Ten concurrent runs at 300 MB each is 3 GB from a single worker, so on a 16 GB box I'd run two or three workers with concurrency dialled down to 5 each, then raise it while watching memory.

On the main process, N8N_CONCURRENCY_PRODUCTION_LIMIT caps how many production executions run at once. Setting it deliberately is better than letting a traffic spike decide for you. When the limit is hit, jobs wait instead of crashing the box.

Note: queue mode adds moving parts. Redis and Postgres both need to be monitored and backed up, and a Redis outage stops executions cluster-wide. If you're a two-person team on KVM 2, the default single-process mode is the right call until you outgrow it.

The community licence allows multiple logins; shared projects are a paid add-on

Multiple people can log in to a self-hosted community instance, each with their own account and their own workflows. What sits behind the paid licence is the team layer: shared projects, granular roles, workflow sharing between users, SSO, and advanced log streaming. n8n has moved several of these between tiers over the years, so check the current self-hosted licensing page rather than trusting a number you read somewhere.

There's also a usage restriction worth knowing. n8n ships under its Sustainable Use License, which permits internal business use of the software. Hosting n8n as a service for your clients to log into, or reselling access, is a commercial arrangement you need to sort out with n8n directly. Agencies building automations for clients on their own instance are generally fine; agencies renting out logins are not.

For a small team, the practical shape of community edition is this: everyone gets an account, everyone builds in their own space, and you coordinate on naming and credentials manually. That works well up to maybe 5 or 6 people. Past that, the lack of shared projects starts to bite before the hardware does.

While you're setting up access for other people, put n8n behind a proper hostname with HTTPS rather than an IP and port. A certificate on the login page matters more than usual here, because n8n stores API keys and OAuth tokens for every service your team connects.

Size your instance from a week of real numbers

Here's the process I'd follow instead of guessing. Plan on about a week of observation, since weekly workflows and month-end jobs only show up if you watch long enough.

1. Start on KVM 2 with Docker Compose, PostgreSQL, and n8n in the same stack. This is the cheapest configuration that won't need rebuilding later.
2. Set N8N_DEFAULT_BINARY_DATA_MODE=filesystem and turn on execution pruning before anyone else logs in. Retrofitting these after your disk fills is a bad afternoon.
3. Add a 2 GB swap file. It's insurance against a single oversized run terminating the process for everyone.
4. Run docker stats during your busiest hour and note peak memory for the n8n container. Do it on three different days, because one sample tells you very little.
5. Check the executions list for runs that took over a minute or moved more than a few thousand items. Those are the workflows setting your ceiling, and often one or two of them account for most of the load.
6. Watch for out-of-memory kills in your container logs. A restart loop under load is the clearest signal you need more RAM, not more tuning.
7. Add queue mode with Redis once peak memory sits above 70% or the editor lags while executions run. Move to KVM 4 at the same time so your workers have cores to sit on.

Warning: test credential and workflow restores before you rely on them. A shared instance holds every connected account your team uses, and rebuilding 40 OAuth connections by hand takes days.

Things people get wrong about sharing one n8n instance

Mix-up: unlimited workflows in the community edition means unlimited capacity.

Reality: the licence puts no cap on workflows or executions, and your hardware absolutely does. Unlimited is a licensing statement about what you're allowed to run, not a promise your 4 GB VPS can run it.

Mix-up: more vCPUs make workflows finish faster.

Reality: a single execution runs on one thread, so a workflow that takes 90 seconds on 2 vCPU takes 90 seconds on 8. Extra cores let more runs happen side by side, which is what you want when several people share an instance, but they don't speed up any individual run.

Mix-up: every user needs their own instance to keep their work separate.

Reality: separate instances give you hard isolation, and they also multiply your patching, backup, and monitoring work by the number of users. One instance plus a licence that includes projects is usually less effort. The exception is a single user with genuinely heavy workloads, like video processing, who deserves their own box so they can't take the team down.

What this means for your team

If you're sizing this today, start at KVM 2 with Postgres and filesystem binary mode. That configuration handles a small team's real work, and you'll learn more from a week of docker stats output than from any estimate, including mine. The upgrade path from there is clean: queue mode and Redis first, more RAM second, more instances last.

The teams that run into trouble almost always share one trait, which is that nobody knows what the instance is actually doing. Two or three forgotten workflows polling an API every minute will quietly eat a core. Keeping a short record of what runs where, and how the stack is configured, pays for itself the first time something breaks; the best way to write that down is whatever your team will actually update.

One more thing to sort early: give n8n its own subdomain rather than a bare IP. Webhook URLs bake the hostname in, so changing it later means editing every external service that calls your workflows.

For hardware, KVM 2 is where I'd put a small team, and KVM 4 if file-heavy or AI workflows are in the mix. You can compare the current KVM VPS plans and apply code hHostCouponHub for up to 85% off the first term. Look at the renewal rate as well as the intro price, since renewals are higher and a shared automation box tends to stay running for years.

Frequently asked questions

How much RAM does a self-hosted n8n instance need for a team?

Budget around 400 to 600 MB per active user, plus about 1 GB for the container, OS, and database. That puts a 5-person team at roughly 4 GB of working memory and makes 8 GB the comfortable choice with headroom for spikes.

Can two people edit the same n8n workflow at the same time?

They can both open it, and that's where saves get messy. n8n warns when the version on the server is newer than the one in your editor, but coordinating who owns which workflow is still a manual job on the community edition, since shared projects and permissions are licensed additions.

How many concurrent executions can one n8n KVM instance handle?

On 2 vCPU and 8 GB, plan for 10 to 20 concurrent light executions, or 3 to 5 heavy ones moving large payloads. Queue mode with two workers on 4 vCPU and 16 GB pushes that to 20 or more concurrent runs, controlled by the worker concurrency setting rather than raw core count.

When should I split one shared instance into several?

Split when a single team's workflows regularly saturate the box on their own, when one group's data can't legally sit alongside another's, or when you're running automations for separate clients who need isolated credentials. Below that, adding RAM and workers to one instance is cheaper and far less work to maintain.

Where to go from here

Pick the plan that matches your peak, not your average: KVM 2 for a small team on normal automation work, KVM 4 if files or AI nodes are involved. Start your n8n VPS here with code hHostCouponHub, get Postgres and pruning in place on day one, and let a week of real numbers tell you when to size up.

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.