Web hosting for agencies: managing 20+ client sites without chaos
TL;DR: Once an agency passes a handful of sites, hosting stops being a technical choice and becomes an operating model. Four decisions matter: how sites are isolated from each other so one hacked site cannot spread, how ownership and billing are split between you and the client, how updates, backups and monitoring are run across all sites, and what support promises you can actually keep. Put each client in an isolated environment, keep domains and billing in the client's name, standardise your maintenance routine and price it as a care plan.
Why agencies outgrow ad-hoc hosting
Most agencies start the same way: each client gets whatever hosting was convenient at the time. After twenty or so sites you find yourself with logins in five dashboards, different PHP versions, a client who stopped paying but whose site still runs, and no clear answer to "who is responsible when this goes down".
The fix is not simply a bigger server. It is deciding, deliberately, how sites are separated, who holds which account, and how routine work happens. If your question is about reselling hosting to clients as a product, that is a different model, covered in our guide to reseller hosting. This post is about running client sites well, whether or not you bill for hosting.
Decision 1: isolation between client sites
The biggest operational risk in agency hosting is cross-contamination. If twenty sites share one account and one of them has an outdated plugin that gets exploited, an attacker can often reach the others, because they share the same file system and user. Our guide to what to do in the first hour after a hack shows how painful the cleanup is for one site, and it is much worse for twenty.
Good isolation means each client site runs under its own user and file permissions, with its own database credentials, so a breach stays contained. You can achieve that in several ways:
- Separate accounts per client on a shared or reseller-style platform, which is the simplest approach and often enough.
- Separate containers or virtual servers for larger or more sensitive clients.
- A well-configured VPS with a separate system user and PHP-FPM pool per site, if you have the skills to manage it.
Avoid one big WordPress Multisite for unrelated clients. It shares a code base and users, which makes it a poor fit for separate businesses, as we explain in WordPress multisite: do you need it.
Decision 2: who owns what, and who pays
Agencies get into trouble when the lines are blurry. A clean split looks like this:
- Domain: registered in the client's name, with the client as owner and you as an authorised contact. Never register a client's domain in your own name as a convenience. If the relationship ends, it becomes a hostage situation.
- Hosting account: either in the client's name (cleanest) or in yours, with a clear written statement that you can transfer it on request.
- Billing: decide whether the client pays the host directly or you bill hosting as part of a care plan. Write it into your contract.
- Content and code: state who owns it on termination and which assets are licensed rather than transferred.
If you bill hosting through your agency, mind GST. Our guide to GST on web hosting and domains explains rates and input credit.
Decision 3: running maintenance across many sites
Without a routine, updates get skipped until something breaks. A workable standard for every site:
- Updates: WordPress core, plugins and themes on a regular cycle, tested first on staging for important sites. Our guide to safe WordPress auto-updates helps you decide what to automate, and the staging environment guide shows the testing flow.
- Backups: automated, off-server, with a restore actually tested, as described in how to back up a WordPress site properly.
- Monitoring: uptime checks on every site that alert you before the client notices. See uptime monitoring you can trust.
- Security: a malware scan and a plugin audit on a schedule. Our plugin audit guide tells you what to keep and remove.
- PHP version: keep every site on a supported, patched branch. The October 2026 PHP flaws were a reminder that the runtime needs attention too, see our PHP2Shell guide.
Management dashboards can speed up repetitive work across sites, but they depend on a disciplined routine underneath. Document the routine first.
Decision 4: access, security and handoff
- Give each team member their own login, never a shared one, and remove access when someone leaves.
- Use a password manager and two-factor authentication everywhere that supports it, as covered in two-factor authentication for WordPress.
- Grant clients the access they need, usually editor rights, rather than full administrator rights that let them install risky plugins.
- Keep a handoff pack for each client: domain registrar, hosting account, DNS records, backups location, emergency contact and login recovery.
A site you cannot transfer cleanly in an afternoon is a liability, for the client and for you.
Decision 5: pricing and support promises
Hosting is the part of your service that fails at inconvenient times, so be careful about what you promise.
- Package it. Many agencies sell a monthly care plan that bundles hosting, updates, backups and monitoring, priced per site, rather than selling raw hosting.
- Define response times. Promise only what your team can cover, including nights and weekends, or state clearly what "business hours" means.
- Know your upstream. If your hosting provider is down, you own the client conversation. Choose a provider whose support responds when you need it, and check its SLA.
- Scope the exclusions. Say what is not included, such as content changes, plugin development and recovery from a client-caused issue.
Hosting structures compared
| Structure | Isolation | Management effort | Cost per site | Best for |
|---|---|---|---|---|
| Ad-hoc, separate shared plans per client | High | High (many dashboards) | Highest | Very few sites |
| Reseller or multi-account platform | Good | Low to moderate | Low | Many small to mid sites |
| One VPS with separate users per site | Moderate, depends on setup | High, needs skills | Low | Technical agencies |
| Separate VPS or cloud per client | Highest | High | Highest | Large or sensitive clients |
| WordPress Multisite for unrelated clients | Low | Moderate | Low | Rarely appropriate |
A rollout plan for an agency with scattered sites
- Inventory every site: domain, registrar, host, PHP version, owner, billing and last update date.
- Fix ownership gaps, starting with any domain not in the client's name.
- Choose the target structure from the table above and a hosting partner that fits.
- Migrate in batches, least critical sites first, using staging and a rollback plan. Our guide to migrating without downtime covers the process.
- Standardise the routine: updates, backups, monitoring and reporting.
- Update contracts to reflect ownership, billing and support terms.
- Report monthly to clients so they see the value of what you do invisibly.
FAQs
Should each client have their own hosting account?
Generally yes, because it isolates risk and makes handoff simple. It can be done on a multi-account platform without paying for a separate server per client.
Is it safe to host many client sites on one VPS?
It can be, if each site runs under its own user and PHP pool and you keep software updated. Without that separation, one compromised site can reach the rest.
Who should own the domain, me or the client?
The client. Register it in their name and list yourself as an authorised contact, so they keep control if you part ways.
How do I handle a client whose site was hacked?
Contain it first, restore from a clean backup if you have one, and find how the attacker got in before bringing it back. Our guides on hacked site cleanup cover the steps.
Do I need a management dashboard for many WordPress sites?
It helps with bulk updates and monitoring, but it is not a substitute for a defined routine. Decide the routine, then pick tools that support it.
What should my hosting SLA with clients promise?
Only what you can deliver, including who responds, when and how. Tie your promise to your own upstream provider's capabilities.
How many sites can a VPS realistically hold?
It depends entirely on the sites. A set of small brochure sites can share a modest server, while a few busy stores can fill a large one. Measure real usage and leave headroom.
Conclusion
Agency hosting is mostly an operating question: isolate each client, keep ownership and billing clear, run one standard routine across all sites, protect access and promise only the support you can deliver. Get those right and the choice of server becomes a much smaller decision.
HostCloud can help agencies set up isolated, easy-to-manage hosting for client sites. See the options at https://hostcloud.in.
Sources: