Sizing your server: CPU, RAM, disk and bandwidth

Sizing comes down to finding the resource that runs out first. Here is how to think about each.

CPU

• Light sites, static content, small databases — 1–2 vCPU is plenty.

• PHP/Node apps under moderate traffic — 2–4 vCPU.

• Transcoding, builds, data processing — 4+ vCPU, or consider that you have outgrown a single box.

Watch load average and CPU steal. If load consistently exceeds your core count, you need more CPU.

RAM

• The OS wants 0.5–1 GB.

• Databases love RAM (for cache). Give PostgreSQL/MySQL several GB on any real workload.

• PHP-FPM / Node workers each take memory; multiply by concurrency.

• Compose/docker adds overhead per container.

Symptom of too little RAM: the OOM killer killing processes, swapping (a dead giveaway in top as high si/so), or workers restarting under load.

Disk

• Capacity — with headroom. A full disk breaks everything: databases corrupt, logs stop, deploys fail. Keep at least 20–30% free.

• Speed — NVMe for anything with a database or build workload.

• IOPS — many small random writes (databases, mail) are IOPS-bound, not GB-bound.

df -h            # free space
du -sh /var/*    # what is using it
iostat -x 2      # if installed: disk utilisation and latency

Bandwidth

• Audio scales with listeners: bitrate × listeners.

• Video scales fast: bitrate × viewers.

• Backups and transfers can spike suddenly.

• Exit/overage terms matter: check before a big launch — see Monitor your bandwidth.

The practical approach

1. Start one size smaller than your instinct; you can resize up.

2. Measure for a week — see Monitoring your resources.

3. Resize the resource that is actually constrained, not all of them.

Signs you bought too small

• Load average persistently above core count.

• Swap in active use.

• 502s under normal traffic.

• Database queries slow that used to be fast.

• Disk above 80%.

Signs you bought too big

• CPU under ~10% all day and RAM barely touched.

• You are paying for headroom you will not need for a year.

Being modestly over-provisioned is not a failure — but if you are at 5% utilisation across the board, a resize pays for itself.

Related reading

• Bandwidth vs CPU bottlenecks

• Monitoring your resources