"How many Docker apps can I run on one VPS?" is the question behind every self-hosting budget and every small hosting business plan. The honest answer is: it depends almost entirely on memory, and you can estimate it with arithmetic instead of guesswork. This post gives you the real method — how to budget by RAM, why memory (not CPU) is usually the ceiling, and worked examples for common server sizes — so you can plan capacity before you run out of it.
The short answer: count memory, not containers
People ask "how many containers" but the server does not care about container count — it cares about resource consumption. And of the resources, memory is almost always the binding constraint for self-hosted apps. Here is why the two limits behave so differently:
- CPU is shareable and elastic. Ten apps that are each idle most of the time coexist happily on a few cores, because they rarely all peak at once. When they do contend, CPU degrades gracefully — everything just gets a bit slower.
- Memory is not shareable. An app holding 500 MB is holding it whether busy or idle. When memory runs out, the kernel does not slow things down — it kills a process. There is no graceful degradation; there is a crash.
So capacity planning is fundamentally a memory-budgeting exercise. Get the RAM math right and the CPU usually takes care of itself for typical web workloads.
The method: sum the realistic peaks, keep a reserve
Four steps:
Rough per-app memory appetites
Real numbers vary with configuration and load, but these ranges orient the planning:
| App type | Ballpark peak RAM | Examples |
|---|---|---|
| Lightweight services | ~100-300 MB | RSS reader, small automation, static tools |
| Typical web apps + database | ~400-800 MB | Wiki, analytics, note tools (app plus its database) |
| Media servers | ~500 MB idle, much more transcoding | Media streaming — transcoding spikes CPU and RAM |
| Browser-based desktops | ~2 GB each | Streamed Linux desktops, remote browsers, IDE workspaces |
| Search / heavy data engines | ~1-2 GB and up | Full-text search, large document stores |
The spread is enormous — a browser-based desktop is roughly ten times a lightweight service. This is why "how many apps per VPS" has no single answer: it depends entirely on which apps.
Worked examples
A 4 GB VPS. Reserve ~1 GB for host and panel, leaving ~3 GB. That comfortably runs a handful of lightweight-to-typical apps — say a wiki, an analytics tool, an RSS reader, and an automation flow — with headroom. It does not run a browser-based desktop and much else; one 2 GB desktop nearly fills it alone.
An 8 GB VPS. Reserve ~1.5 GB, leaving ~6.5 GB. That is room for perhaps eight to ten typical web apps, or a couple of browser-based desktops plus a few light services, or one heavy search engine with capacity to spare. A genuinely useful self-hosting server.
A 16 GB VPS. Reserve ~2 GB, leaving ~14 GB. Now you are into small-hosting-business territory: a dozen or more typical apps, or a fleet of browser workspaces, or a mixed catalog. This is where density starts paying for the server.
The step that makes the math hold: enforce it
An estimate is only reliable if reality is prevented from exceeding it. Without enforced limits, one app's memory leak consumes everything you budgeted for the others, and the kernel starts killing processes across the whole server. So the plan must be enforced, not just calculated:
- Set a memory limit on every container at its budgeted peak plus modest headroom. Now a misbehaving app dies alone instead of taking neighbors with it. (How to set limits correctly.)
- On a multi-customer server, cap each customer's total. A per-account ceiling means your density assumptions survive contact with real usage. Panelica enforces this with a per-account kernel slice that caps the sum of a customer's containers.
- Watch actual usage and adjust. The panel streams live per-container memory; your first estimates are hypotheses to correct with data.
Frequently asked questions
Why is CPU rarely the limit?
Because typical web apps are idle most of the time and their CPU peaks are brief and rarely synchronized. Memory, by contrast, is held constantly. CPU becomes the limit for genuinely compute-heavy workloads (transcoding, search indexing, builds) — for those, budget CPU explicitly too.
Does swap let me overcommit memory?
Technically, but avoid it for app servers. Swapping app memory to disk turns a fast app into a painfully slow one and hides the real problem. Budget honestly and keep apps out of swap.
How do I find an app's real peak?
Run it under realistic load and watch the live memory stats. Start from the template's minimum, then observe — the peak during actual use is your budgeting number, not the idle figure.
Can I fit more by using lighter app variants?
Absolutely. Choosing a lightweight editor over a full streamed desktop, or a lean app over a heavy one, changes density dramatically — sometimes ten-fold. When density is the goal, app selection is your biggest lever.
The takeaway
Capacity is a memory budget, not a container count. Reserve for the host, sum each app's realistic peak, keep headroom, and — the part that makes the estimate real — enforce a memory limit on every container and a total cap per customer. Do that, and "how many apps fit on this VPS" stops being a gamble and becomes arithmetic you can trust. Panelica gives you both the live usage data to estimate with and the kernel-level limits to hold the plan together.