Pick too small and it grates: the VPS stutters as soon as a handful of users show up at once. Pick too large and it costs: month after month you pay for cores that never pass ten percent utilisation. The good news is that for most projects, the right size comes down to a few reference values and one simple question: what runs out first in your workload?
Find the bottleneck before you pick numbers
Every application has a typical bottleneck. Knowing yours tells you where more performance pays off — and where it does not:
- CPU-bound: game server ticks, video transcoding, builds and compile jobs. Cores or clock speed matter here, depending on the application.
- RAM-bound: databases, Java applications (Minecraft included), many containers side by side. Memory is what decides.
- IO-bound: anything doing lots of small reads and writes — databases, shops, CI. Fast NVMe storage matters more here than another CPU core.
A small website is demanding in none of those categories. A Minecraft server, by contrast, is demanding in two at once: CPU clock speed and RAM.
Reference values for typical projects
The values below are deliberately conservative starting points for normal operation — not guarantees, but a solid baseline:
| Project | vCPU/cores | RAM | Storage |
|---|---|---|---|
| Static site, small blog | 1–2 | 2 GB | 20 GB |
| WordPress/CMS with steady traffic | 2 | 4 GB | 40 GB |
| Nextcloud (private, few users) | 2 | 4 GB | your data + 30 % headroom |
| Docker host with 3–5 services | 4 | 8 GB | 60–80 GB |
| Minecraft server up to ~10 players | 3–4 (high clock) | 6–8 GB | 20 GB |
| Discord bot, small API | 1 | 1–2 GB | 10 GB |
| Database/shop backend | 4+ | 8–16 GB | 50 GB+, NVMe required |
Two patterns stand out. For many entry-level projects, far less is enough than instinct suggests. And as soon as Java, databases or several containers enter the picture, RAM is the last place to economise.
CPU: clock speed or cores?
"More cores equals faster" only holds when the application parallelises. Web servers, container hosts and build systems spread their work across many cores nicely. A Minecraft server, on the other hand, runs its game logic essentially in a single thread — eight extra cores do nothing for it, while a higher clock speed does a lot.
So ask yourself before you buy: does a lot run at the same time (→ cores), or does one thing need to be fast (→ clock speed)? For the second group, platforms with a high boost clock are worth a look; more on that in the server CPU comparison of EPYC, Ryzen and Xeon.
RAM: the most honest bottleneck
RAM is the resource whose shortage hurts most visibly — and the one most often misread. Worth knowing: Linux automatically uses free memory as a disk cache. Seemingly "full" RAM in htop is therefore often perfectly healthy; the number that counts is the available column in free -h.
The real alarm signal is the OOM killer. If your log (dmesg) shows processes being killed for lack of memory, the server is undersized. And do not treat swap as a way out — swap prevents the crash, but it does not replace RAM. Once a server swaps regularly, everything feels sluggish.
Storage: capacity is predictable, speed is not
Storage raises two separate questions. How much? Take your actual data plus roughly 30 percent headroom for the system, logs and updates — and remember that local backups occupy that space twice. How fast? For databases, shops and anything with lots of small accesses, NVMe is not a luxury but a requirement; on random access the gap to classic hard drives is a multiple, not a margin.
Rule of thumb: size for normal operation plus about 30 percent of headroom. Permanently below 20 percent utilisation is wasted money, permanently above 80 percent is wasted stability.
Measure instead of guessing
The best sizing decision happens after launch: watch actual consumption for two weeks. htop shows CPU and processes, free -h the memory, df -h the disk. Add a small monitoring tool and you will see load spikes over time as well.
The advantage of a prepaid model without a contract term: a misjudgement is not a two-year commitment. Start small, measure, top up deliberately — that is the cheapest strategy by a wide margin, and certainly cheaper than renting three times what you need "just in case".
Conclusion
Identify your bottleneck first (CPU, RAM or IO), start with the reference values from the table, and measure after two weeks. That way you pay for performance you actually use rather than numbers on a spec sheet. In the AMD EPYC configurator you can combine cores, RAM and NVMe storage freely and watch the price update live; for game servers, the Ryzen 9 line with its high clock speed is the better starting point.