How to Size and Choose a VPS for Your Project

Most VPS plans are bought by guesswork: an 8 GB plan for a site that never uses more than 1.5 GB, or a 1 GB plan where the kernel kills the database every night because memory ran out. A more accurate method needs no fancy tools: four numbers you pull from your current site, a few simple formulas that turn them into cores, memory, disk and traffic, and one latency measurement that settles the data centre. Here we apply it step by step to a realistically sized store, and finish with a checklist to run through before you order.

01Start from the workload, not the plan

Before you open the pricing page, collect four numbers from your current site, or from a test environment if the project is new:

• Peak dynamic requests: How many requests per second PHP or your application executes in the busiest minute, excluding images and static files served directly by the web server or the cache.
• Request time and CPU time: The average execution time of a dynamic request, and the part of it actually spent on the CPU. The rest is waiting on the database or an external service.
• Memory per worker: How much memory each PHP-FPM worker uses. On WordPress it’s usually between 50 and 120 MB, depending on plugins.
• Data size and growth: The size of the database and site files today, how fast they grow each month, and how much a single page transfers to the visitor on average.

If you’re on cPanel hosting you can download the raw access logs, and their common (combined) format is the same in Apache and Nginx, so the same commands work on both:

# The ten busiest minutes for dynamic requests, static files excludedgrep -vE '\.(css|js|png|jpe?g|webp|gif|svg|ico|woff2?)' access.log | awk '{print substr($4,2,17)}' | sort | uniq -c | sort -rn | head# Average memory per PHP-FPM worker and worker count on a running server (adjust the version)ps -o rss= -C php-fpm8.3 | awk '{s+=$1; n++} END {printf "%.0f MB x %d\n", s/n/1024, n}'# InnoDB data and index size in MBsudo mysql -e "SELECT ROUND(SUM(data_length+index_length)/1024/1024) AS mb FROM information_schema.tables WHERE engine='InnoDB';"

Divide the top number in the first result by 60 to get dynamic requests per second. The memory figure runs slightly high, because RSS counts memory shared between workers, which is an acceptable safety margin. If the project is new, run it on a test server and load it with a tool such as k6 to get the same numbers.

02CPU and memory on paper

Take a flower shop in Latakia, ward-latakia.sy, running WooCommerce. Its logs show the busiest minute last month carried 360 dynamic requests, or 6 per second, averaging 250 ms per request, of which about 150 ms was CPU time.

CPU

Average busy cores = requests per second × CPU time per request. Here 6 × 0.15 = 0.9 cores for PHP; add about half a core for the database and web server and the total is 1.4 cores. Since you don’t want utilisation above 65% at peak, divide by 0.65 to get 2.2, which means 3 virtual cores (vCPUs).

Worker count

Workers busy at the same moment = requests per second × total request time, which is Little’s law from queueing theory: 6 × 0.25 = 1.5 workers on average. Real requests arrive in bursts, so multiply by 4 or 5 and set pm.max_children to 8. Don’t raise it beyond what memory can hold, because every active worker claims its memory.

Memory

Add memory up component by component. After PHP, the biggest item is the InnoDB buffer pool: if the database has the server to itself, give it 50–70% of RAM; if it shares the server with the site, size it to the active data plus a margin, no more. And leave a quarter of memory free, because the kernel uses it as a disk cache that speeds up reads considerably.

03Disk and traffic

Work out the disk from four items: the OS and packages (5–8 GB), site files, the database and logs. Then add space at least the size of the database, because a backup dump is written to disk before it’s shipped off. For the flower shop: 6 + 8 + 0.7 + 2 + 1 = about 18 GB. Don’t plan for more than 70% usage: the database needs room for temporary tables and logs, and a full disk stops every write. So you need about 26 GB today, and 40 GB with a year of growth.

Disk speed matters more to the database than capacity. NVMe storage usually serves random reads in well under a millisecond, which is what queries need when their data isn’t in memory. We explain how to measure that yourself in a separate article on VPS vs VDS.

Monthly traffic = page views × what a page actually transfers after browser caching. The store serves 600,000 page views a month at an average of 1.2 MB, or about 720 GB, plus updates and shipping backups off the server. Serving images through a content delivery network (CDN) cuts that figure considerably. And ask the provider whether both directions count, or outbound only.

04Data centre: measure the latency

Every new HTTPS connection needs about three round trips before the first byte of the page arrives: one for the TCP handshake, one for the TLS 1.3 handshake and one for the request itself. If the round-trip time (RTT) between your visitor and the server is 80 ms, time to first byte can’t drop below 240 ms however fast your server is. That’s why the data centre’s location affects your site’s speed more than an extra core does.

Don’t assume the closest on the map is the closest on the network: packets follow the peering agreements between ISPs, and traffic from a neighbouring country may travel through Europe before it comes back. Measure from your audience’s own networks, a home line and a mobile network, at peak time:

# 50 packets to a test address in each candidate data centre: look at the average and the jitter (mdev)ping -c 50 203.0.113.10# The path hop by hop, with loss, per-hop latency and the network (AS) numbermtr -rwzc 100 203.0.113.10

Where do you get a test address? Ask the provider for one per data centre, or run a small server for a day in each candidate location. CoreVPS servers are billed by the day with no contract, so the test costs only a few days. Its data centres today are Germany, Finland, the UAE, the United States and Singapore, with Syria coming soon. Here’s how to read the result:

• Under 40 ms: Excellent for any interactive site or for a dashboard your team works in.
• 40 to 100 ms: Fine for most sites; caching, HTTP/2 and HTTP/3 soften the effect.
• Over 100 ms, or loss above 1%: Try another data centre, or put a CDN in front of your site, especially if the jitter is high.

05OS, virtualization and backups

Once you have the numbers, five questions settle the rest of the choice:

• Operating system: Pick a long-term support release your team knows: Ubuntu 24.04 or 26.04 LTS, Debian 13, or AlmaLinux and Rocky Linux if your tooling is built for the RHEL family. If you’ll install a control panel, check which systems it supports before ordering. And remember that Windows Server adds a licence cost.
• Virtualization type: Make sure it’s full virtualization such as KVM, not containers sharing the host’s kernel, or you may be unable to run Docker or load kernel modules.
• Backups: Find out where backups are stored and how much space you get. It must hold several copies, not one: at least twice your compressed data size.
• IPv6: Many mobile networks around the world now run on IPv6. Ask for an address, add an AAAA record for it, and make sure your web server and firewall work on it.
• Support and SLA: Ask technical support a real technical question during your first days, and judge the speed and quality of the answer. Read what the uptime agreement compensates: 99.97% means under 13 minutes of downtime a month.

06From numbers to a plan

Once you have the numbers, comparing plans is easy. Here are the specs of the ready-made CoreVPS plans, with the workload each one suits in our estimate:

The flower shop needs 3 vCPUs, 4 GB of memory, about 40 GB of disk and under 1,000 GB of monthly traffic: exactly VPS Pro. Every plan runs full virtualization on AMD EPYC 9454P processors, DDR5 ECC memory and NVMe storage in RAID 10, with one IPv4 and one IPv6 address. If you need a mix no ready plan matches, build your server resource by resource, and upgrade any resource later from the control panel without reinstalling.

Start with the disk you need and no more: growing a disk is usually easy, while shrinking it isn’t possible at most providers. After launch, watch the server for two weeks under real load. These signs tell you the estimate needs adjusting:

ProblemThe database stops suddenly, and the kernel log (dmesg) shows Out of memory

FixLower pm.max_children or the InnoDB buffer pool, and add swap as a safety net. If it keeps happening under normal load, add memory.

ProblemCPU hits 100% every night at the same hour

FixUsually a scheduled job: a backup, image compression or indexing. Move it to a quieter time or lower its priority with nice before you buy cores.

ProblemUsed memory is always at 90% but the site is fast

FixThat’s usually the disk cache, and it’s healthy. Look at the available column in the output of free, not at used.

07Before you order: the checklist

1. 01You pulled peak dynamic requests per second from the logs, not from monthly visitors.
2. 02You sized cores for utilisation of no more than 65% at peak.
3. 03You added memory up component by component and left a quarter for the disk cache.
4. 04You estimated disk for a year, with room for a database dump and usage under 70%.
5. 05You measured RTT and ran mtr from your audience’s network to each candidate data centre, at peak time.
6. 06You chose a long-term support OS you know, on full virtualization.
7. 07You know where backups are stored and how many copies fit.
8. 08You tested technical support with a real technical question.

If the numbers clash with the budget, memory comes first: too little CPU slows a site down, too little memory takes it down.