Memory is usually the first limit
For most server workloads, RAM decides the plan. CPU is shared over time and briefly busy cores just make things a little slower, but running out of memory makes processes crash. Size for memory first, then check CPU and disk.
Starting points by workload
| Workload | Starting plan | Why |
|---|---|---|
| VPN, bastion, small static site | Micro 1 vCPU / 2 GB | Light memory, low CPU |
| WordPress or small business site | Small 2 vCPU / 4 GB | PHP workers plus database |
| Production web app with worker | Medium 4 vCPU / 8 GB | Separate processes need headroom |
| Database-heavy site, search index | Plus 4 vCPU / 12 GB | Working set fits in RAM |
| CI runners, game servers, media | Pro 6 vCPU / 16 GB | Parallel CPU work |
| Large database, consolidation | Max 8 vCPU / 32 GB | Memory and cores together |
These are starting points. Measure once real traffic arrives.
Measure memory
free -h
ps -eo rss,comm --sort=-rss | head -15Look at the available column in free, not "free": Linux uses spare memory as a disk cache and gives it back on demand. If available memory regularly drops below about 15 percent, or the kernel log shows the out-of-memory killer (journalctl -k | grep -i oom), you need more RAM.
Measure CPU
uptime
top # press 1 to see each coreThe load average should generally stay below the number of vCPU. Sustained load above it means work is queuing. In top, a high wa value points to storage waits rather than CPU shortage, and a high st (steal) value on any VPS means the host is contended; on our clustered platform resources are allocated to your server, so steal should stay near zero.
Measure disk
df -h
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -15Keep at least 20 percent of the disk free. Databases, Docker images and logs are the usual culprits for growth. iostat -x 5 (from the sysstat package) shows whether the disk is busy, though on replicated SSD it is rarely the bottleneck for typical web workloads.
Use the graphs
The VeloxMedia control panel keeps CPU, memory and bandwidth history for every server. Look at a full week, including your busiest day, before deciding. A single snapshot of top at 3 a.m. tells you little.
Signs it is time to move up
- Available memory under 15 percent for long periods, or swap in constant use
- Load average above the vCPU count during normal traffic
- Database queries slowing as the dataset grows past available memory
- Disk more than 80 percent full
Signs you could move down
- Memory use under 40 percent and load under a quarter of vCPU, all week
- A server that only runs a single light service
Resizing
Plans change from the customer portal and your data, disk and dedicated IPv4 stay the same. Annual billing saves two months on whichever size you settle on, so it is worth measuring for a few weeks on monthly billing and switching once the size is stable.