What "isolation" actually means in shared hosting
Most panels isolate per account. Doing it per website costs more and is the difference between one compromised site and all of them.
Every shared host says its customers are isolated from each other. It is true, and it is not the interesting question.
The interesting question is what happens inside one customer’s account.
The common design
Most panels give each customer a boundary — a user, a container, a jail — and put all of that customer’s websites inside it.
That is a real boundary and it does real work. Your neighbour cannot read your files.
But an agency with twenty client sites has one boundary around all twenty. If one of those sites runs an abandoned plugin with a file-upload flaw, whatever gets in is already inside the boundary that was protecting the other nineteen. The blast radius of the weakest site is every site that customer owns.
This is the ordinary way a hosting compromise becomes a hosting incident: not one site defaced, but a whole book of clients.
The alternative
Make the website the isolation unit rather than the account.
One unprivileged, id-mapped system container per site. A customer with five sites has five boundaries. A compromise of one reaches one.
It also makes noisy-neighbour behaviour predictable in a way per-account limits do not: CPU, memory and process limits are per site, so one site having a traffic spike hits its own ceiling rather than the account’s shared one.
What it costs
More containers. More memory overhead. More things for the control plane to converge.
It is a genuine cost, and it is why the cheaper design is common. We think it buys the thing customers actually assume they are already getting.
Where we do not do it
Worth being specific, because "isolate everything" is a slogan rather than an architecture.
Databases are not per-customer containers. They are shared instances on dedicated database nodes, with a per-customer database, user and grants. Running an engine per customer would hold the same software in memory once per customer, and at any real density that cost is not recoverable. The boundary there is the engine’s own permission system, which is a boundary that has been attacked for thirty years and is good at its job.
Mail runs on separate nodes entirely. Not for isolation between customers, but because mail has a different IP reputation model, a different scaling curve and a different attack surface from web. Putting it on a web node means one of those three problems eventually becomes all three.
The question to ask a host
Not "are my sites isolated" — everyone says yes.
Ask: if one of my sites is compromised, what does the attacker reach? The answer tells you which design you are buying.