Cloudways server size guide

Picking a server size feels like a test you can fail, so people overbuy to be safe. On Cloudways that instinct costs money every month for headroom the panel will hand you in one click the day you need it. Vertical scaling resizes a server, RAM, CPU and storage together, while preserving its configuration. That fact should change how you choose: the wrong size is a correction, not a migration. Start small, measure, resize when the numbers say so.

Start one size under your instinct

Provision the smallest server your workload can plausibly run on, then let real traffic argue with that estimate for a few weeks. Two reasons. The bill matches reality from month one, and the panel's monitoring will tell you more about your workload in a month of real traffic than any planning worksheet can before it exists.

If you want a number before any data exists, use the server size calculator: it turns what you know about a site into a starting RAM and vCPU band on stated assumptions. If you are running several sites on one server, the WordPress capacity estimator does the same across the set. Treat what comes out as the band you provision against, then let measurements take over.

RAM goes first for WordPress

A WordPress site spends RAM before it spends anything else. Every PHP worker holds memory while it runs. MySQL wants its share for buffers and temp tables. If the object cache runs in Redis or Memcached, that is RAM too, spent deliberately. CPU matters during traffic spikes and admin work, and storage matters for large media libraries, but the size step a busy WordPress site climbs is almost always a RAM step, because exhausted RAM degrades everything at once before anything cleanly fails.

The flexible plans step up through RAM and vCPU together, from 1GB at the bottom through 2GB, 4GB and 8GB as of October 2026, with prices left to the pricing page since they move. Two boundary details are worth knowing. Applications per server are unlimited, bounded only by what the server can carry. And servers at 4GB and above include Object Cache Pro, caching software the platform bundles in at that tier, which is a genuine line in the sand when you are weighing 2GB against 4GB.

Sizing by visits is a habit from hosts that meter visits. These plans do not, which pushes the real question to the front: how much memory does your stack hold at your worst hour.

What to watch

The panel's server monitoring gives a real-time view across sixteen-plus metrics. The ones that matter for sizing are sustained RAM use, CPU during your traffic peaks, and disk activity when the database is busy. Sustained is doing the work in that sentence: a single spike during a backup or a search-engine crawl means little, while RAM sitting high through ordinary afternoons is the server telling you the next tier is near.

You will usually feel a too-small server before the graphs confirm it. The wp-admin that used to load instantly starts taking seconds. Pages flicker 502 errors during busy periods as PHP processes run out of room. First bytes get slow even at quiet hours. Symptoms first, metrics second, because symptoms are what your visitors experience while you are still opening dashboards.

Scale the box or split the site

When a server is tight you have two moves, and they solve different problems. If the whole server is simply small for its combined workload, scale it vertically: one click, a few minutes, configuration preserved. Every site on the box benefits and nothing about how you work changes.

If one site is eating the server while the rest are fine, scaling up buys that site company it does not need and buys everyone else headroom they were not missing. The right move is splitting the hungry site onto its own server, which is a clone operation, then resizing the original back down. I wrote up how I draw those boundaries in how we host multiple production sites. The short rule: a site that dominates its server's resources should also dominate its own server's bill.

Optimise before you resize

Some pressure is a sizing problem wearing a disguise. Before paying for the next tier, check that the built-in caching is switched on and working: the server-side caching stack, Varnish and the rest, is on the platform, and Breeze, the caching plugin the panel preinstalls, deserves a settings check of its own. Check the object cache is running. Check plugin hygiene and page weight, because a page hauling megabytes of images stresses every tier equally.

A caching misconfiguration presents as slowness, exactly like an undersized server, and the fix for one is an afternoon while the fix for the other is a monthly line item. Spend the afternoon first. When you have, and the metrics still say the server is the limit, resize without guilt: that is what the button is for.