Per-site isolation
Isolation is the difference between an incident and an outage. Every site we host runs inside a kernel-level CloudLinux LVE cage with its own CPU, RAM, IO and process ceilings, its own CageFS filesystem view, its own PHP version and its own database throttle. A site that is attacked, compromised or simply running a punishing query is contained where it sits — and the isolation baseline is included on every plan, not sold back to you as an upgrade.
The worker fleet runs CloudLinux OS, which pushes multi-tenancy down into the kernel. Each site gets a Lightweight Virtual Environment — an LVE — that is a hard boundary rather than a polite convention. Nothing a site does inside its cage can be spent out of someone else's budget.
LVE caps CPU, RAM, IO, IOPS, processes and entry-processes for every site independently. When a site exceeds its ceiling it is throttled inside its own cage — the fault is logged against that site, and the sites either side of it carry on unaffected.
A plugin stuck in a loop, a badly written cron job or a crawler hammering an endpoint hits the site's own process and entry-process limits first. One site cannot simply consume the machine.
Because entry-processes are capped per cage, a flood aimed at one site cannot open unlimited work on the host. LiteSpeed connection and request throttling and the Imunify360 network firewall sit in front of that, so the attack stays the target's problem.
Every LVE fault is recorded per site and flows into the platform's policy engine, which can tighten or relax limits automatically. You see why a site was throttled, and when — graduated, reversible and logged.
Resource isolation stops a site being loud. Filesystem isolation stops it being nosy. CageFS gives every tenant a private, restricted view of the machine.
Under CageFS, a tenant sees its own files and a minimal, sanitised set of system binaries — and cannot see other tenants, other tenants' sites, or sensitive system files. The usual shared-hosting failure mode, where one compromised account becomes a reading position over every other account on the box, is closed off at the kernel.
This matters most on the day something goes wrong. If a site is compromised — through a stale plugin, a stolen credential, a vulnerable theme — CageFS is what keeps the blast radius to that single cage. Our security specification is deliberate about the wording: CageFS contains breaches. Containment is the honest claim, and it is the one that decides whether an incident is a one-site clean-up or a fleet-wide one.
Backups reinforce the same boundary. Per-site backups are immutable, offsite and air-gapped, with tested restores, so even a worst-case compromise on one site has a clean, independent recovery path that does not depend on the state of the machine it was running on.
Web-tier isolation is only half the story. On a WordPress fleet, the thing that most often makes a server feel slow is one site's queries, not one site's traffic. That is handled explicitly.
CloudLinux MySQL Governor throttles database usage per site, so one site's heavy queries cannot slow the server for everyone else. It is the anti-slowdown control, and it runs whether or not the noisy site ever notices it is being restrained.
The fleet runs MariaDB (or Percona), chosen for WordPress workloads rather than inherited by default, with Governor sitting on top of it as the per-tenant fairness layer.
A per-site Redis object cache absorbs repeated reads before they reach the database, which lowers the pressure Governor has to arbitrate in the first place. Caching and isolation work as one system.
CloudLinux alt-PHP gives each site its own PHP version selector, its own extensions (imagick, gd, redis and the rest) and its own hardened settings — with LSAPI workers bounded by that site's LVE limits, so PHP concurrency is part of the cage rather than an escape from it.
Isolation decides how far a problem spreads. Enforcement decides what happens next. We replaced the blunt on/off suspend with a state machine, driven by durable workflows and enforced on the worker through LiteSpeed, LVE and Imunify.
Isolation is not a plan feature that appears three tiers up. It is a property of the substrate, so it is identical whether you are running one WooCommerce store or two thousand network sites.
Bulk and PBN networks run on the same LVE and CageFS substrate, alongside footprint-aware CDN account rotation and static-HTML delivery. Isolation is what makes density safe: sites share a fleet without sharing fate.
Managed WordPress, WooCommerce, PHP, static and Node sites get the same cages plus full self-service — your own PHP version and extensions, Redis object cache, staging and push-to-live.
For workloads that need a stronger boundary than the density-optimised default, full container-per-site isolation is offered as a provisioning-driver variant: same engine, same control plane, different placement, at higher overhead.
LVE and CageFS isolation, the proactive WAF and real-time malware scanning are included for every customer, because an infected or runaway site threatens its neighbours and our IP reputation. One-click malware cleanup and advanced protection tiers are the paid add-ons — the baseline is not.
The commercial temptation in hosting is to sell safety in tiers: put the cheap customers on a shared box with soft limits, and charge the ones who care for a boundary. We do not, because the customer who did not pay for isolation is precisely the one whose compromised site becomes everybody else's incident.
We host more than 100,000 PBN sites across every niche, on a fleet where density is the whole economic proposition. That only works if the isolation underneath it is unconditional. Kernel-level cages, a private filesystem view, per-site database throttling and per-site PHP are the price of running at that scale without shared fate — so they are on for everyone, on every plan, from the first site you deploy.
The result is a platform that behaves predictably under other people's bad days. Behind it sits a 99.99% uptime assurance, per-site immutable offsite backups with tested restores, and a full audit trail of every enforcement action taken on your sites.
Isolation is designed specifically to stop that. LVE caps CPU, RAM, IO, IOPS and processes per site, MySQL Governor throttles database usage per site, and LSAPI workers are bounded by the site's own cage — so a neighbour's traffic spike or heavy query load is throttled against their ceiling, not yours. Every fault is logged per site, and the policy engine can tighten a noisy site's limits automatically.
The honest answer is containment rather than a guarantee. CageFS gives each tenant an isolated filesystem view — a compromised tenant cannot see other tenants, their sites, or sensitive system files — and a confirmed malware or phishing case moves that site to quarantined: offline, files locked, no execution, isolated for forensics. That is what limits the blast radius. Alongside it we run real-time malware scanning and a proactive WAF on every site, plus per-site immutable offsite backups with tested restores, so recovery never depends on the state of the machine involved.
It is included on every plan. LVE and CageFS isolation, the proactive WAF and real-time malware scanning are baseline for every customer, because an infected or runaway site threatens its neighbours and our IP reputation — we cannot sensibly leave it optional. What is sold as an add-on is one-click malware cleanup and remediation, and advanced protection tiers such as enhanced WAF rules, priority scanning, bot management and higher DDoS tiers.
It is throttled inside its own cage rather than switched off. Throttled means tighter LVE limits and rate limiting with the site still up and serving, and it recovers automatically once the cause clears. You are notified with the reason, the transition is logged with its evidence, and it is appealable. If the load is genuine growth rather than a fault, the answer is a larger plan, not a permanent throttle.
No — a suspended site serves a branded, reason-specific holding page (billing, maintenance or abuse) so it reads as intentional rather than broken. Suspension reverses on payment, on fix, or on appeal. Quarantine is stricter and works differently: it reverses only after cleanup and review, never automatically.
On Mainstream Hosting, yes — CloudLinux alt-PHP gives each site its own PHP version selector, its own extensions such as imagick, gd and redis, and its own hardened settings, all bounded by that site's LVE limits. Footprint-Free Hosting deliberately runs a more standardised, locked-down per-site configuration, because configuration variety is itself a footprint.
Yes. CloudLinux LVE and CageFS is the density-optimised default across both product lines. For workloads that need a harder boundary, full container-per-site isolation is offered as a provisioning-driver variant — the same engine and control plane with different placement, trading overhead for stronger separation.
Yes. Footprint-Free Hosting starts with a card-free 7-day trial covering up to five sites — no payment details, no commitment. Deploy a few sites, push some load through them, and see how the cages behave before you decide.
Start a card-free 7-day trial on Footprint-Free Hosting — up to five sites, no payment details, no commitment. Kernel-level isolation, the proactive WAF and real-time scanning are included from the first deploy.
Start free