Cloud Hosting for Agencies Managing Client Sites

The problem agencies actually have

An agency hosting portfolio is not one big system. It is thirty small ones, each with a different owner, a different content management system version, a different contract and a different idea of what "urgent" means.

That shape creates problems a product team never meets. A single compromised plugin on one client site can affect neighbours on the same box. A client who stops paying still owns their content. A developer who leaves still has credentials to eleven servers. And the person who set up the hosting three years ago left no notes.

Good agency hosting is therefore mostly about boundaries: between clients, between environments, between billing accounts and between people. The technology is the easy part once the boundaries are decided.

Three isolation models

Most agencies end up running two of these at once, which is fine as long as the rule for which client goes where is written down. The usual dividing line is whether the client has custom application code or just a content site.

Containerising each site is a fourth option that sits between the first two. It gives per-site dependency isolation on shared hardware, at the price of a build pipeline. Our guide to running Docker on a cloud server covers the operational side.

Who owns the account

This question decides more than it appears to. If the agency owns every provider account, invoicing is simple and support is fast, but every client offboarding becomes a migration project and the agency carries the payment risk.

If the client owns the account and grants the agency access, offboarding is a permissions change rather than a data move. The trade is that you now operate inside someone else's billing arrangement, with whatever quotas and constraints they have.

A workable middle path is agency-owned accounts with a contractual handover clause and, crucially, a rehearsed handover procedure. Knowing that you can export a client cleanly changes the tone of a difficult conversation.

Whichever model you use, keep the DNS registrar in the client's name wherever possible. Control of the domain is the one asset that makes every other dispute resolvable, and the record mechanics are set out in DNS setup for cloud servers.

Access control that survives staff turnover

The failure pattern is familiar: shared root passwords in a spreadsheet, SSH keys added ad hoc, and a departing contractor whose access nobody can fully enumerate.

• One named identity per person at the provider, never a shared login, with multi-factor authentication enforced.
• Group-based permissions so that adding or removing a person is one change, not thirty.
• SSH access through per-person keys managed by configuration tooling, so revocation is a commit rather than a memory exercise.
• A quarterly access review that compares the provider's user list against the current staff list.
• Credentials for client systems in a shared password manager, with per-client vaults rather than one flat store.

The underlying concepts are the same across providers even though the vocabulary differs, and they are laid out in cloud IAM fundamentals. The effort is front-loaded, which is exactly why it gets skipped and exactly why it pays off.

Standardising the stack

Profitability in agency hosting comes from sameness. Every variation is a thing a junior developer has to learn before they can safely touch a site at nine on a Friday evening.

Pick one web server, one PHP or runtime version policy, one caching approach, one backup tool and one monitoring agent. Build the server once with a provisioning script, then create every future server from that script rather than by hand. Ansible or cloud-init handles this well for a fleet of modest size.

Standardise the deployment path too. A single command or pipeline that deploys any client site removes the category of incident where someone edits a file directly on production and it is overwritten at the next release.

For content sites, the most common stack is Nginx with PHP-FPM and MariaDB, and the migration path for existing sites is covered in migrating WordPress to a cloud server.

Backups, monitoring and what you promise

Agencies get into trouble by promising availability they have not engineered and backups they have not tested. Both problems are solved the same way: decide the real capability, then write the contract to match it.

For backups, define retention per client and keep at least one copy outside the provider account that holds the live site. A snapshot stored beside the server it protects is not an off-site backup, and the distinctions are drawn out in cloud backup strategies. Restore one client site at random every month; an untested backup is a hypothesis.

For monitoring, uptime checks per site are the minimum. Add certificate expiry alerts, because a lapsed certificate is the most common way a small site goes dark, and disk space alerts, because a full disk is the most common way a server does.

Then write down what you actually offer: business hours response, a stated restore window, a named escalation path. Clients accept modest commitments that are met far more happily than ambitious ones that are not.

Agency questions

The relevant account listings are DigitalOcean and Vultr, compared in detail in DigitalOcean versus Vultr. For provisioning references, see the DigitalOcean Droplets documentation and the Nginx documentation.