How to size a VPS without overpaying

VPS plans are sold by memory tier, which makes them easy to compare and easy to get wrong. The two failure modes are buying far more than you need because it felt safer, and buying the smallest tier and then spending a weekend fighting the out-of-memory killer.

Start from what you are actually running

Rough working figures for common workloads, assuming a lean Linux install with no desktop environment:

• A Discord bot or small script — a few hundred megabytes. Even the smallest tier is generous.
• A web app with a database — 1 to 2 GB is usually comfortable for modest traffic.
• A single small game server — driven by the game, not the VPS. Budget the game's requirement plus about 1 GB for the system.
• A Pterodactyl node hosting several game servers — the sum of every server's memory, plus overhead. This is where tiers get large quickly.
• CI runners and build environments — bursty. Build memory, not idle memory, is what matters.

Add the overhead people forget

The operating system, your web server, the database, the monitoring agent and the backup process all want memory before your application gets any. On a small tier this overhead is a meaningful percentage of the total, not a rounding error.

A reasonable rule: work out your application's steady-state need, add 25% headroom for spikes, then add the system overhead on top. If the result lands right on a tier boundary, take the larger tier — being permanently at 95% memory is a bad place to operate from.

CPU is usually not your constraint

For most VPS workloads, memory runs out long before CPU does. The exception is anything doing sustained computation: video transcoding, large builds, or a busy game server where a single thread is the bottleneck. If that is you, the clock speed of the underlying hardware matters more than the vCPU count.

Measure it on the box you have

If you already run the workload somewhere, measure it rather than estimating. On Linux:

free -h                 # current memory picture
vmstat 1 10             # is it swapping?
ps aux --sort=-%mem | head -12   # biggest consumers

The number to watch is swap activity. Some cached memory use is healthy and normal — Linux will happily use spare memory for page cache and give it back on demand. Sustained swapping is the real signal that you are short.

High memory "used" figures alarm people unnecessarily. Look at available memory and swap-in rate, not the used total.

Disk and transfer

Storage is easier to reason about, with one trap: backups. Keeping several full copies of your data on the same server multiplies your disk requirement and defeats the point of having backups. Budget disk for your data plus working space, and keep archive copies somewhere else.

Transfer allowances only matter if you are serving large files or media. A bot, an API and a small site will not come close.

A sensible approach

1. List every process that will run on the box.
2. Add up their steady-state memory, then add 25%.
3. Add about 1 GB for the operating system and supporting services.
4. Round up to the next tier rather than down.
5. Check whether anything you run is single-thread bound before worrying about vCPU count.
6. Plan your backups to live somewhere other than this server.