How it is calculated
| vCPU | peak RPS × CPU ms ÷ 1,000 ÷ target utilization, rounded up |
|---|---|
| RAM | (OS + workers × memory per worker + database × share in RAM) × 1.2, rounded up |
| Disk | (10 GB system + app + logs + database) × (1 + growth headroom) |
Reference configurations
These are the VPS shapes we quote most often. They are configurations, not stock or prices: the price is shown in your quote.
| Name | vCPU | RAM | NVMe disk | Price |
|---|---|---|---|---|
| VPS 2 | 1 | 2 GB | 50 GB | Price shown at quote |
| VPS 4 | 2 | 4 GB | 80 GB | Price shown at quote |
| VPS 8 | 4 | 8 GB | 160 GB | Price shown at quote |
| VPS 16 | 8 | 16 GB | 320 GB | Price shown at quote |
| VPS 32 | 8 | 32 GB | 480 GB | Price shown at quote |
| VPS 64 | 16 | 64 GB | 640 GB | Price shown at quote |
Worked example
Worked example
An API peaks at 50 requests per second using 20 ms of CPU each: 50 × 20 ÷ 1,000 = 1 core busy. At a 60% target that is 1.67, so 2 vCPU. Four workers at 256 MB plus 1 GB for the OS is 2 GB; with a 20% buffer, 3 GB. Disk: (10 + 5 + 5) × 1.5 = 30 GB. Nearest reference configuration: VPS 4 (2 vCPU, 4 GB, 80 GB).
Assumptions and limits
- Shared-vCPU servers can lose CPU time to neighbours (steal time). If consistency matters, compare a virtual server with dedicated vCPU.
- Databases larger than RAM are limited by disk latency; measure before you size by CPU.
- Load-test the result. The VPS sizing guide lists the Linux commands to collect each input.
How we test this tool
Unit tests pin the worked example and check that a workload larger than every reference configuration returns no match instead of the biggest one.
Frequently asked questions
How do I find CPU time per request?
APM tools report it directly. Without one, run a load test at a known request rate and divide busy CPU seconds by requests served.
Related
Inputs stay in your browser. Tool maths last reviewed ; the unit tests that pin these formulas are listed in the evidence hub.