Most people buy either too much or too little, because the numbers on a plan page mean nothing without a workload. This guide gives realistic figures per use case and shows how to measure your own.
1. RAM is the number that decides everything
CPU shortages make things slow. Running out of RAM makes the kernel kill processes, which takes your site down. So size for RAM first, and treat CPU as a secondary concern for most workloads.
Linux uses spare RAM for disk cache, so a server that looks full is often fine. The number that matters is available:
$ free -hIf available is comfortable, you have room. If it approaches zero and processes get killed, you are genuinely out.
2. Realistic figures per use case
| Workload | RAM | vCPU | Notes |
|---|---|---|---|
| Static site, small blog, personal proxy | 1 to 2 GB | 1 | Cheap plans handle this easily |
| WordPress or similar with a database | 2 to 4 GB | 2 | The database is the RAM consumer |
| 5 to 10 light Docker containers | 4 GB | 2 | The common self-hosting recommendation |
| Nextcloud, GitLab, or another heavy app | 8 GB and up | 4 | GitLab in particular is RAM hungry |
| Game server, CI runner, video work | 8 GB and up | 4 and up | CPU matters as much as RAM here |
Add roughly 20 to 30 percent on top of what you calculate. A server that runs at 95 percent of its RAM has no room for a traffic spike, a backup job, or a package upgrade.
3. Disk: count what you store, then double it
Your data is only part of it. The operating system, package cache, logs, Docker images, and database indexes all take space. Docker in particular grows quietly.
Small sites live comfortably on 40 GB. If you store user uploads, media, or database dumps, count that volume and double it, because backups and temporary files need somewhere to live during a restore.
4. Bandwidth is usually not your limit
For a normal website, monthly traffic is far below what any plan includes. Bandwidth becomes a real consideration only for media streaming, large downloads, or a busy proxy. Note that only outgoing traffic counts against your allowance on our plans; incoming traffic is free.
5. Measure before you upgrade
Watch the server under real load for a few days before you decide.
$ free -h $ uptime $ df -h
uptime prints load averages for the last 1, 5, and 15 minutes. As a rough rule, a load average steadily above your vCPU count means the CPU is the limit. A load average of 2.0 on a 2 vCPU server is fully used; the same number on 4 vCPU is half used.
Swap buys you a safety margin, not performance
A small swap file will not make a server faster. What it does is stop the kernel from killing your database during a brief memory spike. On a small plan that is worth having, but it does not replace having enough RAM.
6. When to move up
Upgrade when the numbers say so, not when the server feels slow:
availablememory near zero, or processes being killed: more RAM.- Load average consistently above your vCPU count while your workload has not changed: more vCPU.
- Disk over about 80 percent with normal cleanup already done: more disk.
If a graph spikes but returns to normal, that is a workload doing its job. Sustained pressure is what justifies a bigger plan.
Quick reference
| Question | Command | What to look for |
|---|---|---|
| Do I have enough RAM? | free -h | The available column |
| Is the CPU the limit? | uptime | Load average versus vCPU count |
| Is the disk filling? | df -h | Root filesystem above 80% |
| What is using it all? | top | The process at the top |
Where to go next
Read your usage graphs over a week before you decide; they show the pattern that a single command cannot. If the numbers say you need more, our upgrade guide covers what changes and how long it takes.