# How to Size a VPS for Your Application

- Link: https://offshorehosting.pk/how-to-size-a-vps-for-your-application/
- Published: 2026-10-25T10:21:00+00:00
- Author: admin

# 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](https://offshorehosting.pk/blog/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:

  |  Workload |  Reasonable starting point |  
   |  Small brochure site or blog, low traffic |  1 vCPU, 1–2 GB RAM, 25 GB NVMe |  
 |  WordPress site with moderate traffic and a few plugins |  2 vCPU, 4 GB RAM, 50 GB NVMe |  
 |  WooCommerce or busy WordPress site |  2–4 vCPU, 8 GB RAM, 80–100 GB NVMe |  
 |  Small API or custom application |  2 vCPU, 4 GB RAM, 50 GB NVMe |  
 |  Application plus database on the same server |  4 vCPU, 8 GB RAM, 100 GB NVMe |  
 |  Database-heavy application |  Prioritise RAM and NVMe speed over CPU cores |

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](https://offshorehosting.pk/blog/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’}