Shared hosting: why I took all my clients off it
I spent a morning looking for a button that didn't exist. That's when I understood when shared hosting stops being enough, and what really changes for the client when their technical person holds the server.
Davide Ruggeri
A year ago I spent a morning looking for a button that didn’t exist.
I had to put a reverse proxy in front of a client’s site. A half-hour job, if you have access to the machine. On that shared hosting there was nothing to be done: no server control panel, no virtual hosts, no configuration line within reach. The plan cost a few euros a month and worked perfectly well, for what it could do. The problem was that we had just started working on the site.
That morning I understood something I now tell every new client: shared hosting isn’t a bad product. It’s a product designed for sites that need to exist, not for sites that need to be worked on.
Shared hosting is fine, as long as you don’t touch anything
I want to be honest, because the “cheap hosting will ruin you” line is almost always pushed by people with expensive hosting to sell.
If you have a five-page brochure site that you update twice a year and that doesn’t need to do anything except load, shared hosting is the rational choice. It’s cheap, it doesn’t require any skills, and it comes with a support desk that answers. There’s nothing to improve.
The ceiling shows up the exact moment someone starts working on the site. And that moment usually coincides with the moment the site starts to matter for revenue.
The things I couldn’t do, in order of frustration
No layer in front of the site. All my work on gradually migrating from WordPress to a modern stack relies on a Node server that sits in front of the original application and intercepts requests. On shared hosting that layer doesn’t exist and can’t exist: Aruba’s shared plans, to name one, explicitly exclude Node from the supported technologies, along with Angular and Vue. It’s not a setting you can ask support to change, it’s a bricked-up door.
No serious way to work. No deploys from a repository, no staging environment, no way to roll back. The production site is the only copy in existence and you edit it right there, live, hoping for the best. There is a backup, it’s in the panel, and nobody has ever tried restoring it.
No persistent cache and a painfully slow admin panel. I’ll dwell on this one for a moment, because it’s the issue clients feel every day without being able to name it. Public pages are cached, so to visitors the site seems decent. The admin panel isn’t: that’s where you find out how much CPU you really have. If whoever writes the content waits six seconds every time they hit save, the content stops getting written. It’s a marketing problem disguised as a technical one.
The day the difference became obvious
On 13 August one of the sites I manage was attacked. I told the whole story in Hacked WordPress site: how I secured it and made it faster in a few hours.
Only one part matters here. Faced with a compromised site, on shared hosting you have one move available: clean it up and hope the way in was the one you closed. I had another one: shut WordPress down as a live application, generate a static build and point the proxy at the new origin. Same URLs, no database, no PHP running, and a faster site than before.
That move isn’t smarter than the first one. It’s just available, and it’s available because the machine is in the hands of someone who can get into it.
That’s the real advantage of hosting managed by a technical person, and it has nothing to do with server power: when something happens, the range of possible responses is wider.
What you give up, because you do give something up
Anyone selling you a solution with no downsides is selling, not explaining. So I’ll say it plainly.
With shared hosting, the client buys an infrastructure with an operations center running around the clock and written service agreements. With me, they buy me. If I disappear, there’s no night shift to take over. It’s a real trade-off, and it belongs on the table before signing, not after.
It also costs more than a shared plan, obviously. The right question isn’t how much the hosting costs, but how much being able to step in is worth. For a site that brings in leads and revenue, the answer is obvious. For a brochure site nobody touches, the answer is that it isn’t worth it, and I’m the one telling you.
In short
Shared hosting is a parking spot, and parking spots work. But if your site is the channel your clients come through, sooner or later someone will have to get their hands on it: to make it faster, to recover from an attack, to move part of it onto better technology. At that point the question won’t be how much you pay per month. It’ll be whether the person helping you can get in, or has to open a ticket.
Let’s talk
If your site is starting to matter and you’re wondering whether the infrastructure underneath can hold up, tell me about your project.