Server Capacity Planning: Know What You'll Need in a Year Before Paying Today

Server capacity planning is not guessing a big number and paying it today out of fear of tomorrow. It is three calculated steps: measuring a real baseline for what your site consumes now (how much CPU, RAM, and disk per 1,000 visits), then modeling growth at a realistic monthly rate to project next year's number, then upgrading at the 70% sustained-use threshold rather than at the first passing peak. The result is that you pay for what you actually need and add resources when you need them, instead of buying empty capacity you pay for month after month unused.

The golden rule: start right-sized, not oversized. A server with half its resources idle is not safety, it is trapped money. Real safety is knowing your current number precisely, knowing exactly when you hit the ceiling, and being able to upgrade fast without migration. On Cloud you add +2GB RAM for 600 SAR per year or +1 vCPU for 500 SAR on the same server within minutes, so the need to buy a reserve upfront disappears. This guide builds the three steps with numbers you can apply today.

Step one: measure the baseline

You cannot plan what you do not measure. The baseline is your site's consumption under real load across a full week that includes peak days. The tools are ready on any Linux VPS: htop for live CPU and memory, vmstat and sar for the trend over time, df and du for disk, iostat for input and output pressure. The goal is a clear number: how much of each resource your site uses at 1,000 visits.

Reference numbers per 1,000 visits

These are practical engineering estimates that vary by application weight, but they are a realistic starting point:

These are concurrent-peak figures, not daily totals. A site with 30,000 evenly spread monthly visits may see a concurrent peak no higher than the 1,000-visit consumption, because what matters is requests in the same instant, not the total.

Step two: model growth

After the baseline, project where you will be in 12 months. The simple method: take your real monthly growth rate from your analytics (Google Analytics or server logs) and apply compound growth. If your site grows 8% monthly, it roughly doubles in a year (1.08 to the power of 12 is about 2.52x). At 5% monthly the factor is about 1.8x. At 15% monthly it is about 5.35x, a sharp climb that deserves finer planning.

A fully worked example

Say your site today peaks at 3GB RAM and 1.5 vCPU on 40,000 monthly visits, growing 8% monthly:

• After 6 months: growth about 1.59x, so the projected peak is about 4.8GB RAM and 2.4 vCPU.
• After 12 months: growth about 2.52x, so the projected peak is about 7.5GB RAM and 3.8 vCPU.

Today's baseline fits the Growth 4GB plan on a tight margin, or a Business 8GB plan on a comfortable one. The next-year number (7.5GB) says Business 8GB covers you for almost a full year before the first upgrade. The smart call: start with Business, not Enterprise, because you will add resources when needed, not before.

Step three: the upgrade threshold at 70%

The industry rule: upgrade when usage settles above 70% of any resource for days in a row. Why 70% and not 90%? Because the margin from 70 to 100 is the safety cushion for sudden peaks, campaigns, and seasonal demand. A server running at a sustained 90% lives on the edge, so any spike pushes it into choking or an out-of-memory (OOM) event that kills processes without warning.

The crucial distinction here is between a transient peak and sustained use. A jump to 95% for a few minutes during an evening campaign is normal and calls for no upgrade. But an average staying above 70% throughout working hours for days is the real signal. Set an alert that notifies you at sustained 70%, not at every momentary jump.

Which resource hits the ceiling first?

Watch all four, and whichever reaches 70% first dictates the upgrade:

• RAM: usually the first to run out in PHP applications and databases. Fix: +2GB for 600 SAR.
• vCPU: hits the ceiling in heavy processing (images, reports, search). Fix: +1 vCPU for 500 SAR.
• Disk: grows slowly but never comes back, as media, logs, and backups pile up. Fix: +100GB SSD for 500 SAR.
• Bandwidth: hits the ceiling as traffic and heavy media grow. Fix: +1TB transfer for 1,150 SAR.

Why not buy empty capacity upfront

The common temptation: buy Enterprise 16GB from day one and relax. The problem is you pay the price difference for long months on sleeping memory. Let us compare over a year between starting on Enterprise directly and starting on Business then upgrading resources on demand:

Cloud's decisive advantage is that upgrading is not a migration. You add memory or CPU on the same server within minutes with no file transfer and no meaningful downtime, so there is no penalty for starting small. This flips the planning equation: instead of buying a reserve out of fear that upgrading is hard, you start right-sized and grow gradually. See pricing and plans for all add-ons in SAR.

Instant peak vs daily average

A common planning mistake is confusing total daily visits with concurrent load in the same instant. The server does not suffer from a hundred thousand visits spread over the day, but from a thousand concurrent requests in the peak minute. So compute your capacity on concurrency peak, not the total. A practical method: take your visits in the busiest hour, not the daily average, and multiply by a safety margin for campaigns and events. Saudi store audiences, for example, concentrate in the evening and in specific seasons, so a Ramadan or White Friday peak can equal several times an ordinary day, and planning for the average means a guaranteed choke at peak, exactly when you need performance most.

Continuous monitoring, not a single snapshot

Measuring once is not enough, since load changes across the week and the season. Install continuous monitoring that records the trend, as tools like Netdata or Prometheus with Grafana give you a graph of memory, CPU, and disk over time, so you see when peaks recur and how the baseline grows month after month. This turns the upgrade decision from a guess into reading a number. Set an alert that notifies you when any resource exceeds a sustained 70% for more than a few hours, not at every momentary jump, so the alert does not become noise you ignore after a week.

Do not plan for memory alone

Many capacity plans focus on memory and neglect disk, and disk is the only resource that does not come back on its own, because media, logs, backups, and outputs pile up without stopping. Monitor disk growth monthly and set an alert at 75%, because a full disk stops the database suddenly and causes failures that are hard to diagnose. The fix is either periodic cleanup of old logs, or moving static files to separate storage, or adding +100GB SSD for 500 SAR per year when needed, before it fills up rather than after.

The practical takeaway

A correct capacity plan in three steps: (1) measure your baseline over a full week with htop and sar and pin down your consumption per 1,000 visits, (2) apply your compound monthly growth to learn the 12-month number, (3) pick the plan that covers today's number with a margin, and upgrade resources at sustained 70%, not at the first peak. Start with the right-sized plan rather than the biggest, and rely on adding +2GB RAM for 600 SAR and +1 vCPU for 500 SAR when needed. Empty capacity is not safety; safety is knowing your number and being able to grow without migration.