Short answer: the criteria that decide hosting for one site are nearly useless for choosing hosting for twenty client sites. Speed and price stop being the deciding factors, because at twenty sites the cost that hurts is your own time. What matters instead is who takes the support call, whether you can work in a client’s account without holding their password, whether one compromised site can reach the others, and how cleanly a client can leave you. Most hosting comparisons never mention any of those, because they are written for the person who owns one website.
This is the comparison written for the other case.
Why agency criteria are different#
A site owner picks hosting once, for one site, and optimises for price and page speed. An agency picks hosting once and then lives inside that decision twenty or fifty times over, every week, for years. The cost structure is completely different.
| One site owner | Agency with 20 client sites | |
|---|---|---|
| Biggest cost | The monthly invoice | Your hours |
| Downtime cost | One site is down | Your phone rings, and your reputation is the thing at risk |
| Who fixes a broken plugin | Them, eventually | You, today, because they are paying you |
| Security incident | Bad day | Bad day plus twenty client conversations |
| Switching cost | One migration | Twenty migrations, so realistically never |
| Access model | One login they own | Twenty logins you must not lose or leak |
| What “cheap” means | $5/month | An hour you did not have to spend |
The last row is the one that reframes everything. If a host saves you twenty minutes a month per site across twenty sites, that is about seven hours. At any realistic billable rate, seven hours is worth vastly more than the difference between a cheap plan and an expensive one. Hosting price is close to the least important variable in the decision, and it is the one every comparison leads with.
The criteria that actually decide it#
Who absorbs the work#
The single biggest variable is how much routine operational work the host does for you rather than leaving on your desk. Core and plugin updates, PHP version upgrades, TLS certificate renewal, malware scanning, backup verification. Each of these is a small job. Twenty of each is a part-time role.
Be specific when you evaluate this, because every host claims to be managed. The useful question is not “is it managed” but “what happens on Tuesday when a plugin vulnerability is disclosed?” Does the platform patch it, notify you, do nothing, or open a ticket asking you to act? A host that classifies and acts on plugin vulnerabilities automatically is doing work you would otherwise do by hand across every client site you run.
The related question is whether updates can be trusted to run unattended. Automatic updates that break a client site at 3am are worse than no automatic updates, which is why the useful version takes a restore point first and checks the site still responds afterwards. That distinction is the entire difference between the feature being an asset and being a liability.
Working in a client account without holding their password#
This is the one agencies consistently discover too late. The usual arrangement is that you either own the hosting account, or the client owns it and shares their login with you. Both are bad.
If you own it, the client is locked in, and separating is a chore that costs goodwill at exactly the wrong moment. If they own it and share the password, you now hold credentials for twenty accounts, those credentials are in a shared vault, staff turnover means revoking them, and nothing in the audit trail distinguishes you from them.
What you actually want is delegated access: the client owns the account and grants your login permission to work inside it, revocable by them, with your actions attributable to you. It is the only arrangement where both parties can walk away cleanly and where a security review does not turn up a spreadsheet of client passwords.
Ask whether the host supports this at all. Many do not.
Blast radius between client sites#
If one client’s site is compromised, can it reach the others? On old-style shared hosting the answer is often yes, because everything runs under one system account, and a malicious file dropped in one site can read files in the next. That is a bad conversation to have with nineteen other clients.
Per-site isolation is the thing to ask about, and the honest test is whether sites are separated at the operating system level or merely by folder permissions. This matters more for an agency than for anyone else, because you are the common factor. A compromise that spreads across your client base is a business-ending event in a way that one client’s bad day is not. It is worth reading what actually hardens a WordPress site at the server level rather than assuming a plugin covers it, since a security plugin runs inside the site it is defending and cannot help once the site is already executing someone else’s code.
Backups you have actually tested#
Every host has backups. Far fewer let you restore a single site quickly without a support ticket, and fewer still keep a copy somewhere other than the machine the site runs on.
Three questions separate real backup from the marketing version. How far back can you go? Can you restore one site, or one file, without restoring everything? And is there a copy off the platform entirely, so that a serious platform-level failure does not take the backups with it?
The last one is the one to press on. A backup on the same infrastructure as the site protects you against a customer deleting a page. It does not protect you against the scenario you are actually insuring against. Some hosts let you push a copy to storage you control, which is the arrangement that survives a genuinely bad day. If you are still running backups from inside WordPress, it is worth understanding what plugin backups can and cannot do before you rely on them for a client.
Staging that is not a manual chore#
Every client site needs a staging copy eventually, usually urgently. If creating one is a manual process, you will skip it, and you will eventually test something in production. The question is whether a staging site is one action from the panel and whether pushing changes back is equally simple.
Whose account is it, and what happens when they leave#
Plan for the client leaving, because some of them will, and how that goes decides whether they recommend you afterwards.
If the site lives in your account, somebody has to perform a migration, somebody has to pay for it, and the client feels the lock-in on the way out. If the client owns their account, they take it with them and the relationship survives. This is the practical argument against reselling that most agencies only appreciate after the first messy exit, and it is covered properly in how agencies make money on client hosting.
The switching cost you are signing up for#
Whatever you choose, you are choosing it for years, because migrating twenty sites is a project nobody schedules. That makes the migration story worth evaluating up front rather than at the end.
Two things matter. Does the host migrate sites for you, as a service, performed by a person? And what happens to the sites you already have elsewhere: is moving them your weekend or theirs? A host that will do the moving is removing the single biggest barrier to you ever changing your mind, which is also a reasonable signal about how confident they are. Migrations fail in predictable ways, and the failures are much less likely when somebody does it for a living.
The categories of host, and what each gets wrong for agencies#
Budget shared hosting. Cheap per site, and the economics look excellent across twenty clients. The problems are isolation, support quality when you actually need it, and the fact that every operational task lands back on you. You are paying with hours instead of money, which is a bad trade at agency rates.
Premium managed WordPress. Good infrastructure, genuinely less work, and priced accordingly. The common complaints are ticket-based support with no real control panel, per-visit pricing that makes client billing unpredictable, and limits that turn into surprise invoices when a client’s campaign works. Worth reading the overage terms before you commit clients to it.
Reseller plans. Built for exactly this use case, and the margin is real. What you are signing up for is a second business: billing, support hours, cashflow float, and client accounts that live inside yours. That suits a firm with a helpdesk already. It punishes a team of three who build websites.
VPS or cloud you manage yourself. Total control, lowest unit cost, and you have just hired yourself as a systems administrator. The trade is laid out in full in managed versus unmanaged hosting. For an agency the question is whether server administration is a service you intend to sell. If it is not, it is overhead with no revenue attached.
Two criteria that only bite at portfolio scale#
Performance you do not have to tune per site#
Speed comparisons are written for one site, where the answer is to tune that site. Across twenty client sites, per-site tuning is not a strategy, it is a recurring cost. What you want is a baseline that is fast without anyone doing anything, because the sites nobody has touched in a year are the majority of your portfolio.
The practical question is what the platform does by default. Is caching on before anyone configures it? Is it correct for a logged-in user and for a cart, or does it need a plugin and an afternoon per site? Does a new site arrive fast, or arrive needing work?
This changes which advice applies to you. A full optimisation pass is the right approach for a flagship client site that earns its tuning time. It is the wrong approach as a portfolio strategy, because you will do it twice and then never again, and the other eighteen sites will be whatever the default was.
The PHP version problem#
This one arrives on a schedule and catches agencies every time. PHP versions reach end of life, hosts eventually force the upgrade, and somewhere in your portfolio is a client site running a theme that was abandoned in 2019 and breaks on anything newer.
What matters is not whether the host supports current PHP, since they all do. It is whether you can set the version per site, whether you can test the upgrade somewhere safe first, and how much notice you get before a forced move. A host that upgrades everything on one date with thirty days notice will produce a very bad month for you, because you will be fixing eight client sites at once rather than one at a time.
Per-site version control and a staging copy turn this from an emergency into scheduled work. It is worth asking about specifically, because it is invisible until the first time it happens and then it is the only thing that matters for a fortnight.
Where Hostney sits#
We do not sell a reseller tier, and the reason is the one above: that model only works for firms already built to run a support desk, and it puts client sites inside your account. What we do instead is let the client own the account and bill directly, while you work inside it through delegate access, which they grant and can revoke. Your actions show up in the account’s own activity log as yours.
One honest limitation: delegate access is currently all-or-nothing per hosting account. Scoped and read-only access is not available yet, so a delegate can do what the owner can do. If you need to give a junior designer access to one site and nothing else, that is not something we can do today.
Sites run in isolated containers rather than sharing one system account, so a compromise on one client’s site does not have a path to the next one. Bot filtering and WAF rules run before a request reaches the site rather than as a plugin inside it, which is also why they keep working on a site that is already in trouble. Backups can be copied to S3-compatible storage you control, so a copy exists outside our platform entirely.
Migration is free and performed by a person, not a knowledge base article, and that applies to the sites you already have elsewhere. If you would rather move something yourself first, the self-service routes are on every plan including the trial.
On the commercial side, the arrangement is a partner programme rather than a reseller discount: the client pays us, you take a commission, and your invoice covers your own work. Current bounty and recurring rates are on the partner page since they are the kind of thing that changes.
Summary#
Price and page speed decide hosting for one site. For an agency they are close to noise next to the things that consume your week.
Judge a host on how much routine work it absorbs, whether you can work in a client account without holding their password, whether one compromised site can reach the next, whether backups exist somewhere other than the platform, and how cleanly a client can leave. Then look at the price, which will almost certainly be the smallest number in the decision.
The one thing worth deciding deliberately is ownership. An account the client owns costs you the reseller margin and buys you a clean exit, no support desk, and no cashflow float. For most agencies that is the better trade, and the arithmetic on twenty sites is less close than it looks.