One of our servers runs about fifty websites. It is economical, and it means any one of them having a problem can affect the other forty-nine.
This piece covers where the risks are and which boundaries are non-negotiable. Its practical relevance: your website is probably on a machine like this too — that is what shared hosting is — and knowing the risks tells you what to ask your provider.
Three risks that come with sharing
1. Resource contention.
CPU, memory and database connections are shared. One site being crawled heavily, or running badly written code that repeats expensive queries, or simply being attacked, consumes them and everything else slows down.
The symptom is unpleasant: your site becomes intermittently slow while you changed nothing. Logs reveal nothing, because the cause is not yours.
2. One compromise can reach everything.
The most serious. If every site’s files belong to the same system user and directory permissions are loose, breaking into one site grants read and write access to the others.
The usual path: a site running a plugin that has not been updated in years, a scanner finds the vulnerability, a backdoor file is uploaded, and from there the attacker edits the other sites — most often inserting hidden links or redirecting visitors elsewhere.
3. Shared configuration.
Where several sites share a configuration file, a change made for one affects all of them. A mistake does not break one site; it breaks every site.
We keep one rule for touching shared configuration: copy it to a timestamped backup first. Old-fashioned, and when the file you are editing is used by fifty domains it is the only reason you are willing to edit it.
Boundaries that are not optional
File permission isolation. Each site’s files should belong to a separate system user with no access to the others. The most basic and most effective measure — it confines a compromise to the site that was compromised.
Cheap shared hosting frequently omits this and runs everything as one user. It is the largest risk in that category and completely invisible from outside.
Separate databases. One database and one account per site, each able to reach only its own. Then even a successful injection cannot read anyone else’s data.
Resource limits. Cap CPU and memory per site, so a runaway site slows itself before it takes the machine down.
Separate logs. Access and error logs per site. Combined, they make it impossible to tell which site caused an incident.
A more thorough approach: keep visitors off the server
All of the above is about making sharing safe. There is another direction: move the publicly visited part off the server entirely.
If a site’s pages do not change between updates — true of most business websites — they can be generated in advance as files and deployed to a CDN. Visitors receive files, and the server is used only when content changes.
Both load and attack surface drop sharply: no public traffic reaches it, so there is no public attack surface against it.
Our own site works this way now. The server still exists as the place content is managed, and visitors never touch it. A useful side effect is speed — pages are served from the CDN with no journey back.
Not suitable for everything; anything with logins or transactions still needs dynamic capability. But for a presentation site it addresses performance, security and resource contention at once.
Working out what you are on
If you do not know what kind of hosting your site uses:
Look at the price. Packages at ten to forty a month promising unlimited traffic and unlimited websites are shared hosting, and quite likely the loosely isolated kind.
Ask three questions. Does each site run as a separate system user? Does each have its own database account? Are there resource limits? An inability to answer usually means no.
Watch for regular slowness. If your site slows at consistent times without your traffic increasing, the neighbours are the likely explanation.
Sharing is not the problem; neglect is
To be clear: there is nothing wrong with a shared server. Fifty small websites on fifty separate machines is absurdly expensive and leaves most of that capacity idle.
What determines the risk is whether anyone is looking after it: whether system updates are applied, whether plugins are upgraded, whether logs are read, how quickly someone responds to an incident.
A maintained shared server is considerably safer than a neglected dedicated one. When choosing hosting, who maintains it matters more than whether it is exclusive.
On the machine we maintain, every incident across those fifty sites has had the same cause — something left unupdated for a long time. So the most important part of the process is not isolation, it is updating regularly and having somebody actually look.
On the projects we host, sites are isolated by user, have separate databases and separate logs, and statically served sites do not execute on the server at all. None of that is a paid extra; it is the baseline for a shared arrangement, because when something goes wrong every client shares the consequences.