How we host multiple production sites on Cloudways

I look after production sites for clients and for myself, and they run on several Cloudways servers instead of one. The whole arrangement costs about $200 a month, which I will put on the table immediately because it is the first thing anyone asks about a multi-server setup. The second question is why anyone would pay it when the platform puts no limit on how many applications share a single server. The answer is the reason this article exists: with several sites, the structure matters more than the specs.

One server per blast radius

A server is the unit of failure. Applications on the same box are separated at the application level, but underneath they share one machine's RAM, CPU and disk. A busy cron job or a traffic spike on one site makes itself felt on every site sharing that server.

So I draw server boundaries around blast radius. Sites that belong together operationally share a box: my own projects together, several sites for the same client together. A site whose paying client expects an explanation for every minute of downtime gets its own server, or shares one only with sites I control completely. The test I apply is blunt: if this server fell over for an hour, how many unrelated people would notice, and would any of them be justified in being angry at another one of my clients?

That second clause is the whole argument. When one server hosts a client's experimental side project next to another client's revenue site, every resource dispute between those sites becomes a dispute between your clients, with you in the middle. Separate servers make the dispute impossible.

How the applications are organised

Each site is its own application in the panel, with its own domains, its own TLS certificates, its own Git settings, its own staging environment and its own backup configuration. Nothing about one application's setup leaks into another's.

Around the applications, the panel has two organising features I lean on. Projects group applications, which keeps the server list navigable once you are past a handful of sites. Team access is granted per server or per application, so a freelancer hired for one site reaches exactly that site and nothing else. And when a project ends, the server itself can be transferred to the client. Handing over a whole server, working and configured, beats exporting a site and walking someone through a rebuild on their end.

Staging and cloning carry the workflow

Every change I ship goes through staging first. Each application gets a staging copy, changes get tested there, and pushing staging to live is one click. As of October 2026, staging and cloning are included in every plan instead of being sold separately, and that pricing decision ends up shaping behaviour. When testing is free and takes a minute, you stop debating whether a change is small enough to skip it.

Cloning does the heavier jobs. A new client site starts life as a clone of a known good setup, so my baseline configuration comes along for the ride. A risky upgrade gets rehearsed on a clone first. Cloning an application to a different server is how a site moves onto its own box when it has outgrown shared company, which is the split described above.

Updates

Updates are the part of hosting several sites that compounds: the count of things needing attention multiplies while your attention does not. WordPress core, themes and plugins all ship updates on their own schedule.

The platform's SafeUpdates option automates the routine end of that: it detects updates, tests them on staging and deploys them. On quiet brochure sites I let it. On sites with revenue attached I keep updates manual and run them through staging myself, because I want a human looking at the result when the site is taking money. Once your count of sites makes tab-switching the bottleneck, the Site Manager add-on, from $3 per application per month as of October 2026, pulls the same tested-update flow plus cross-site monitoring into one dashboard.

Backups and the restore test

Automated backups run offsite on a schedule, on-demand backups sit there for use before risky changes, and offsite storage bills at $0.033 per GB per server as of October 2026, which across all my servers has never been a number I noticed on the invoice.

The schedule is the smaller half of the story. A backup you have never restored is a claim, and I treat the restore as the part that needs proving. I run a restore test on a staging clone on a calendar basis and after anything structural changes, and the method is written up in how to test a Cloudways restore safely. The short version: restore onto a clone, never onto live, then check the result the way a visitor would.

Monitoring

The panel watches server resources in real time across a large set of metrics, and CloudwaysBot pushes alerts to email and Slack when something needs eyes. I keep that and add one thing the platform cannot see from inside: an external uptime check on every domain. The panel knows the server is healthy; an external probe knows a visitor in another country can load the page, DNS included. Both views are cheap, and they fail in different ways, which is the point.

The cost shape, honestly

Billing is per server per month, sized by RAM and CPU, plus add-ons, plus that small offsite backup charge. My roughly $200 covers several servers and a few add-ons. The structure is a choice, and it is worth being plain about the alternative: a single small site can sit on an entry tier for a fraction of that, and current prices live on the Cloudways pricing page, since hosting prices move and my October 2026 figures will age.

What the money buys is the ability to say a specific sentence to a specific client: your site is unaffected. When one server has a problem, that sentence stays true for everyone whose sites are elsewhere, and it stays true without anyone working a weekend to make it so.

If you are sizing your first server, the server size guide covers where to start and what to watch. For the full case for the platform itself, read the Cloudways review, and the managed versus VPS comparison puts the trade in numbers at your own hourly rates.