When a website on a shared server gets hacked, what protects YOURS? The isolation architecture — invisible until the day it matters. Here is how the walls work.
The four walls (on properly built hosting) 1. **Filesystem walls:** each site runs under its own system user; open_basedir restricts PHP to its own folders. A compromised site can read and write ITS files — not the neighbour's. (Kairalmas configures exactly this per website.) 2. **Database walls:** one MySQL user per database, privileges scoped to that schema only. Site A's database credentials cannot open Site B's content 3. **Process walls:** separate PHP workers (own sockets per site) — one site's runaway script starves itself, not the server 4. **Resource walls:** per-account CPU caps and usage graphs — one site's viral spike throttles its own plan, not everyone's day
What weak isolation looks like (the horror story) Everything shared: one FTP user for all sites, databases reachable cross-account, one PHP pool. One outdated plugin on one customer's site becomes the launchpad for every site on the box. This is the architecture behind 'the whole host got hacked' stories.
The customer's half of the bargain Isolation contains breaches; it does not prevent them. Your half: updates (the security basics guide), unique passwords, sane plugins. The walls limit blast radius; your hygiene keeps the fuse unlit.
The verification question (for any host) 'Is each site's PHP restricted to its own files (open_basedir), with its own database user?' — a yes with specifics means real walls; a marketing shrug means shared fates.
Isolation is the hosting equivalent of fire doors: invisible, unglamorous, and the only thing standing between your neighbour's disaster and your business. Kairalmas builds them into every plan — the Launch trial lets you verify rather than believe.