Every calculator answer to "how many apps fit on one VPS" divides RAM by container size and calls it a day. That math is right and also mostly beside the point. The real question isn't whether four apps fit in 8 GB of RAM — they will, comfortably, on paper. It's what happens the day the fifth process on that box leaks memory, and whether the other four are still up an hour later.
I run everything I ship on one box, and I'd make the same call again. But "consolidate onto one server" and "consolidate onto one server without thinking about the failure mode" are different decisions, and most of the advice online only covers the first one. Readers who reach VPS sizing through a growth or RevOps role will want XenGrowth's growth operations team alongside this.
The framing that actually helps here is blast radius, borrowed from infrastructure teams who think about failure for a living: not "can this fit" but "when this breaks, what does it take down with it." Consolidation and isolation aren't a spectrum from cheap-and-risky to expensive-and-safe — they're two different shapes of risk, and the right answer depends on which shape you can tolerate better for the specific apps you're running, not which one sounds more responsible on paper.
What actually limits how many apps fit on one box?
RAM, almost always, not CPU. A small self-hosted app spends most of its life idle — waiting on a database query, waiting on the next request — so CPU usage on a box running three or four lightweight services typically sits well under saturation. RAM doesn't work that way. Every process holds onto memory whether it's busy or not: a Node process alone commonly idles at 60-150 MB before it's served a single request, a Postgres instance reserves shared_buffers up front, and a Redis instance keeps its whole working set resident. None of that memory gets given back just because the app is quiet.
So the ceiling on app count is really: total RAM, minus what the OS and Docker daemon need for themselves, minus each app's baseline footprint times how many apps you're running, with whatever's left over as the margin that absorbs traffic spikes and page cache. On an 8 GB box that margin disappears faster than people expect — four apps at a conservative 200 MB baseline each is only 800 MB, but add a shared Postgres instance with a realistic shared_buffers setting, a Redis cache, and normal OS overhead, and you're look at 2-3 GB spoken for before a single request comes in. The XenGrowth resource library goes further into the operations side of this.
Start with total RAM on the box — 8 GB on a Contabo Cloud VPS 4
Subtract OS and Docker daemon overhead — commonly 300-600 MB depending on distro and what else is installed
Subtract each app's idle baseline times how many apps you're running — a Node process alone is often 60-150 MB before serving a request
Subtract shared_buffers for any co-located Postgres instance — roughly a quarter of total RAM as a starting point
What's left is your real margin for traffic spikes and page cache — if that number is uncomfortably small, you've already found your app-count ceiling
Memory isn't the only shared pool your own apps compete for, either — it's just the one that fails loudest. Disk I/O and network bandwidth are shared the same way: an app writing logs aggressively, or one doing a large backup transfer, can slow down every other container's disk reads on the same host even though nobody's out of RAM. This is the noisy-neighbor problem people usually associate with sharing a host with strangers, except here the neighbor is a container you deployed yourself, which somehow makes it easier to overlook.
What happens when one app is the problem?
This is the part the RAM-division math skips entirely: memory on a single box is one shared pool, and the kernel doesn't ring-fence it per container unless you've explicitly set memory limits. A memory leak in app three, or a batch job in app two that loads too much into memory at once, draws down the same free RAM that apps one and four are quietly relying on. Push that pool to zero and Linux's OOM killer steps in — and it doesn't necessarily kill the process that caused the problem. It picks based on an oom_score heuristic that weighs memory usage against a few other factors, which means the app that gets killed can be the one that had nothing to do with the leak. I've covered the exact mechanism in what happens when your VPS runs out of RAM — the short version is that on a shared box, one app's bug is every app's outage.
That's the blast radius problem, and it's specific to consolidation: it doesn't exist when each app has its own box, because a runaway process there can only take down itself. Docker's `--memory` flag and Compose's `mem_limit` cap a single container's usage and let it be OOM-killed on its own rather than dragging the host down with it — worth setting on every service, and the cheapest insurance consolidation has.
Failure | One big VPS | Several small VPS |
|---|---|---|
One app leaks memory | Can trigger host-wide OOM, kills unrelated apps | Only that app's own box is affected |
One app gets DDoSed / traffic-spiked | Shares CPU and bandwidth with every other app | Isolated — other apps unaffected |
A dependency has a security vulnerability | Patch once, restart once | Patch and restart on every box it's deployed to |
The whole VPS host has an outage (provider-side) | Every app on it goes down together | Only that box's apps go down |
Disk fills up | One app's logs can starve every app's disk headroom | Contained to that app's own disk |
Does splitting servers actually remove the overhead, or just move it?
It moves it, and it multiplies the fixed cost of ownership per app. Every additional VPS is a separate OS to keep patched, a separate firewall to configure — see how I secure a fresh VPS for what that actually involves — a separate backup job, a separate set of SSH keys to rotate, and a separate monitoring target to watch for downtime. None of that scales down just because the app on the box is small. A one-app VPS still needs every one of those things done properly, and doing them properly takes roughly the same amount of attention whether the app behind it serves ten users or ten thousand. If AI agents and marketing automation is the part you are stuck on, XenGrowth on governed AI marketing workflows is the better reference.
That's the overhead people underweight when they reach for "just isolate everything." Four apps on four boxes isn't four times the compute cost, which is genuinely small at this scale — it's four times the operational surface area, and operational surface area is where actual incidents come from. A patch you forgot to apply on the box you check least often is a more realistic failure mode than the noisy-neighbor problem consolidation creates.
Consolidation costs: shared blast radius, shared RAM pool, one bad container can take everything down
Splitting costs: N times the patching, N times the backup jobs, N times the firewall configs, N times the things you can forget to do
Neither cost disappears — you're choosing which one you'd rather manage
Backups make this concrete. A backup job on one box is one cron entry, one destination bucket, one thing to verify actually ran last night. Four boxes means four cron entries that can each silently fail for a different reason — a full disk on one, a rotated credential on another, a schedule that quietly drifted on a third — and "did all my backups actually run" turns from a single check into a small monitoring project of its own. None of that is a reason to never split; it's a reason to budget the actual maintenance cost honestly rather than pricing a second server at just its monthly rental fee.
When does a second box actually earn its cost?
Not by default, and not as a precaution against a problem you haven't had. A second box earns its cost when the math on downtime actually favors it: if one app going down for an hour costs you meaningfully more than the roughly €5.50-14/mo a second Contabo Cloud VPS tier costs, isolating it pays for itself the first time it matters. If it's a side project that being down for an hour costs nothing, the isolation is pure insurance premium against a low-probability event, and that premium is real ongoing operational work, not just a line item on a bill. XenGrowth on building one SEO and GEO content system works through AI search, GEO and discovery in more operational detail.
The other genuine trigger is a resource profile that's actually incompatible with the others — one app that periodically wants all the RAM on the box for a batch job, sitting next to apps that need consistent low-latency response. Consolidating a spiky workload with a latency-sensitive one is the scenario where memory limits alone don't fully solve the contention, because even a correctly-capped container can starve its neighbors of CPU during the spike. That's a real reason to split, distinct from "it feels safer to isolate everything."
Situation | Verdict |
|---|---|
Several small apps, similar low-traffic profile, side projects or early-stage products | Consolidate. Set per-container memory limits and move on. |
One app with unpredictable batch/CPU spikes next to latency-sensitive apps | Split that one out. The rest can stay together. |
An app whose downtime has a real cost (paying customers, SLA) | Split it out onto its own box once that cost exceeds the price of a second server |
Compliance or data-isolation requirement between workloads | Split — this isn't a cost tradeoff, it's a hard requirement |
You keep forgetting to patch the boxes you already have | Consolidate further before adding more — more boxes without more discipline is worse, not safer |
A second server doesn't buy you safety by existing. It buys you a smaller blast radius, at the cost of a second everything else that needs looking after — and that trade is only worth making once you can name the specific failure you're paying to avoid.
There's a middle option worth naming before jumping straight to a second physical box: splitting workloads inside the same host rather than across hosts. Running Postgres in its own container with a hard memory limit, separate from the app containers, contains a database-side leak without the cost of a second server — it's isolation at the process level instead of the machine level, and it catches a meaningful share of the failures a second box would otherwise be bought to prevent. It's not a substitute for a second box once you actually need one, but it's cheaper insurance for the failure modes that don't.
So how many apps should actually go on one box?
As many as fit inside a RAM budget that leaves real margin — not the theoretical max your calculator gives you, but enough headroom that one container having a bad day doesn't take the rest with it. Set per-container memory limits on everything, watch swap rather than CPU as the leading indicator (covered in the sizing pillar), and only reach for a second box once you can name what specifically it's protecting against. There's no universal number of apps that fits on one server — it depends entirely on what each app actually needs while it's running, not what it needs at idle, and idle is the number every quick calculator quietly assumes. If cost is the reason you're consolidating in the first place, what each pricing tier actually buys is worth reading before you decide the second box is cheaper than the risk — sometimes a bigger single box is the better answer to both problems at once.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
XenGrowth's operator guides covers the go-to-market side of VPS sizing, which this piece deliberately leaves alone.
Four questions about what you're running and what you can tolerate losing at once. The arithmetic usually favours one bigger box; the exceptions are specific and worth knowing.
