How to Size a VPS for Your Application

A VPS (Virtual Private Server) gives you a guaranteed slice of a physical server: a set number of CPU cores, a fixed amount of RAM, a disk of a given size and speed, and a bandwidth allowance. Choose too small and the application slows down or fails under load. Choose too large and you pay every month for capacity you never use.

Sizing is not guesswork. It is a measurement exercise: find out what your application actually uses, understand what each resource constrains, and leave headroom for peaks and growth. This guide walks through that process.

The Four Resources That Matter

A VPS is defined by four resources, and each one limits a different thing.

CPU (vCPU cores). The processor does the computing: running PHP, executing application code, compressing responses, encrypting TLS connections. CPU-bound applications — WordPress with many plugins, a busy API, image processing — need more cores. A single core can serve a surprising amount of traffic for a cached site, but an uncached dynamic application will saturate one core quickly.

RAM (memory). Memory holds what the server is actively working with: the operating system, the web server, PHP processes, the database cache, and any in-memory stores such as Redis. RAM is usually the first resource to run out on a busy application server, because each concurrent PHP process consumes memory and the database wants as much cache as it can get. When RAM runs out, the server starts swapping to disk, and performance collapses.

Disk (storage). Disk holds the operating system, the application, the database and the files. Two things matter: size and speed. Size is straightforward — add up the application, the database, logs and backups, then leave room for growth. Speed matters more than most people expect: a database on a slow disk is slow no matter how much CPU you have. NVMe SSD storage is the standard to look for; traditional spinning disks and older SATA SSDs are measurably slower for database work.

Bandwidth (network). Bandwidth is the amount of data transferred to and from the server, usually measured monthly. It matters for media-heavy sites, file downloads and video, and for any application with a large or distant audience. A CDN can reduce origin bandwidth dramatically by serving static assets from edge locations — see CDN vs web hosting and when you need both.

Step 1: Measure What You Have Now

If the application already runs somewhere — shared hosting, an existing VPS, a local server — measure it before choosing a size. Guessing from the application’s description is unreliable; two WordPress sites with the same theme can use ten times different resources depending on their plugins and traffic.

Measure over a representative period, including a peak:

• CPU: average and peak usage. Sustained CPU above 70–80% means the server is near its limit.
• Memory: peak usage, including database cache. Watch for swap usage — any sustained swapping means RAM is too small.
• Disk: total used space, growth rate over the last few months, and disk I/O wait. High I/O wait means the disk cannot keep up.
• Traffic: requests per second at peak, and monthly bandwidth.
• Concurrency: how many simultaneous users or requests the application serves at peak. This is the number that drives CPU and memory sizing.

If you have no existing server to measure — a new application — estimate from the stack: a small WordPress site, a Node.js API, a Laravel application and a game server all have different profiles, and the frameworks’ own documentation usually gives minimum and recommended requirements. Start small, measure, and scale.

Step 2: Work Out the Per-Request Cost

The most useful sizing calculation is simple: how much CPU and memory does one request cost, and how many simultaneous requests must the server handle?

For a PHP application, the calculation looks like this:

• Each PHP worker process uses a certain amount of memory — commonly 30–80 MB for WordPress, depending on plugins.
• The number of workers you can run is roughly the available RAM divided by the per-worker memory, minus what the operating system and database need.
• The number of simultaneous requests the server can handle is roughly the number of workers, adjusted for how long each request takes.

Example: a server with 4 GB of RAM, where the database and operating system need about 1.5 GB, leaves 2.5 GB for PHP. At 50 MB per worker, that is about 50 workers — 50 simultaneous requests. If each request takes half a second, the server can handle roughly 100 requests per second. That is a rough estimate, not a guarantee, but it turns sizing from a feeling into arithmetic.

The same logic applies to other stacks: Node.js, Python and Java applications each have their own per-process memory footprint, and the calculation is the same.

Step 3: Size for the Peak, Not the Average

Averages hide the problem. A site that serves 10 requests per second on average but 200 per second for ten minutes after a newsletter goes out needs to survive the 200, not the 10. Size for the peak, and size for the peak you expect after growth, not the peak you had last year.

As a rule, plan for:

• Peak traffic plus 50% headroom. If your peak is 100 simultaneous users, size for 150.
• Growth over the next 6–12 months. If traffic is growing 10% a month, a server that is exactly right today will be too small in a few months.
• Background work. Backups, cron jobs, search indexing and updates all consume resources. If they run during peak hours, they compete with visitors.

Headroom is not waste. A server running at 40% CPU has room to absorb a spike; a server running at 90% has none. And a server with no headroom is a server that will page you at 2 a.m.

A Practical Starting Point

These are starting points for common workloads, not prescriptions — measure your own application and adjust:

Note the pattern: RAM and disk speed matter more than raw CPU for most web applications. A database that fits in memory and sits on fast storage will outperform a CPU-heavy server with a slow disk.

Step 4: Separate the Database When It Makes Sense

On a small VPS, the web server and the database share the same machine, and they compete for the same RAM. As the application grows, that competition becomes the bottleneck. The database wants memory for its caches; the web server wants memory for its workers; neither gets enough.

When you see sustained high memory usage and the database and web server fighting for resources, consider separating them: a VPS for the application and a managed database or a second VPS for the database. This also improves reliability — a runaway web process cannot starve the database — and lets you scale each tier independently. It adds complexity and cost, so it is a step for growing applications, not for a first VPS.

Step 5: Plan for Scaling, Not Just Sizing

The size you choose today is not permanent. A good VPS plan lets you scale vertically (more CPU, RAM or disk on the same server, usually with a reboot) and, for larger applications, horizontally (more servers behind a load balancer). Before committing to a provider, check:

• Can the plan be upgraded without migration or downtime beyond a reboot?
• Is there a larger plan with the same operating system and configuration, so an upgrade is a resize rather than a rebuild?
• Does the provider offer snapshots or backups, so a resize can be rolled back if something goes wrong?

[TO BE CONFIRMED: Offshore Hosting’s VPS plan sizes, upgrade process, and whether resizing requires downtime.]

Common Sizing Mistakes

• Sizing for the average. Peaks are what break servers.
• Forgetting the database. The database is often the largest memory consumer on the server, and it is the one most often left out of the calculation.
• Choosing disk by size alone. A large slow disk is worse than a smaller fast one for most applications.
• Ignoring bandwidth. A media-heavy site can exhaust a monthly bandwidth allowance long before it exhausts CPU or RAM.
• Never re-measuring. Applications change — new plugins, more traffic, larger databases. Review resource usage quarterly and resize before the server tells you it is too small. See how to monitor VPS CPU, RAM and disk usage.

Sources

• WordPress requirements: https://wordpress.org/about/requirements/
• MySQL 8.0 reference manual — optimization: https://dev.mysql.com/doc/refman/8.0/en/optimization.html
• NGINX documentation: https://nginx.org/en/docs/
• PHP supported versions: https://www.php.net/supported-versions.php

Sources

• {‘title’: ‘WordPress requirements (PHP and MySQL/MariaDB versions)’, ‘url’: ‘https://wordpress.org/about/requirements/’}
• {‘title’: ‘MySQL 8.0 reference manual — optimizing the server’, ‘url’: ‘https://dev.mysql.com/doc/refman/8.0/en/optimization.html’}
• {‘title’: ‘NGINX documentation’, ‘url’: ‘https://nginx.org/en/docs/’}
• {‘title’: ‘PHP supported versions and end-of-life dates’, ‘url’: ‘https://www.php.net/supported-versions.php’}

← All guides · Knowledge Base