What Is CloudLinux?

If you’ve ever read a shared hosting review and seen phrases like “CloudLinux account isolation” or “LVE resource limits,” you’ve encountered CloudLinux without necessarily knowing what it is. This glossary entry explains what CloudLinux actually does, why hosting providers use it, and what it means for the performance and security of your site.

CloudLinux is a commercial Linux operating system built specifically for shared hosting environments. It was released in 2010 by CloudLinux Inc, the same company that makes Imunify360, KernelCare, and HardenedPHP. It’s based on CentOS but uses a modified kernel that adds the isolation and resource management features shared hosting providers need.

Unlike CentOS or AlmaLinux, which are free and community-maintained, CloudLinux requires a paid licence per server. Hosting providers pay for that licence and pass the benefit on to customers through more stable and secure hosting environments.

Thousands of hosting providers run CloudLinux, including many reviewed on TSH: HostPapa, WHC, CanSpace, VentraIP, Namecheap, and Hostinger among them. When a review mentions “CloudLinux account isolation,” it means the server is running this operating system.

The Core Problem CloudLinux Solves

Standard Linux was not designed to host hundreds of unrelated websites simultaneously. When multiple customers share the same server, one badly written script, a sudden traffic spike, or a compromised account can consume server resources and degrade performance for everyone else. On standard Linux, there is no kernel-level mechanism to prevent this.

CloudLinux’s solution is to wrap each hosting account in its own isolated environment at the kernel level. Not a virtual machine, not software-level throttling, but kernel-level isolation that the operating system itself enforces.

LVE: Lightweight Virtual Environment

LVE is the core technology that makes CloudLinux different from standard Linux. It creates a lightweight resource container around each hosting account, limiting how much of the server’s resources that account can consume.

The limits cover:

• CPU: Maximum percentage of processor time the account can use
• RAM: Maximum memory allocation per account
• Disk I/O: Maximum read and write speed to storage
• Number of processes: Maximum concurrent processes the account can spawn
• Inodes: Maximum number of files the account can hold

When an account hits its LVE limits, it slows down or queues requests rather than continuing to consume shared resources. The critical point is that only the account that hit its limit is affected. Other accounts on the same server continue running normally.

This is what “CloudLinux account isolation” means in practice. A WooCommerce store on the same server as your blog could receive a traffic spike, max out its LVE allocation, and your site would be unaffected. On a standard Linux server without CloudLinux, that same spike would slow every other site on the server.

Hosting providers manage LVE limits through the LVE Manager inside WHM, setting per-account resource allocations based on the plan tier.

CageFS: Filesystem Isolation

CageFS is a virtualized, per-user filesystem that goes further than resource isolation. Without CageFS, all users on a shared server can potentially read files from other accounts if a script is misconfigured or a vulnerability is exploited. Linux was never designed with this many unvetted users in mind, and the default filesystem structure exposes more than it should.

CageFS puts each account into its own private filesystem view. From inside a CageFS environment, a user can only see their own files, their own processes, and a safe subset of system files they need to run applications. Other users’ files, system configuration files, and sensitive paths are invisible.

This prevents several specific attack vectors:

Symlink attacks: A malicious script creates a symbolic link pointing to another account’s files (such as a WordPress configuration file containing database credentials). Without CageFS, Apache or PHP follows the symlink and serves the contents. Inside CageFS, the target of the symlink doesn’t exist in the user’s filesystem view.

Privilege escalation: Exploits that attempt to access system files or escalate a script’s permissions are blocked because the files those exploits target aren’t visible from inside the cage.

Information disclosure: Scripts can’t read configuration files, environment variables, or process listings from other accounts on the server.

CageFS is transparent to end users. WordPress, Joomla, Drupal, and custom applications run normally inside it. No script changes are required. The isolation happens at the operating system level without any application awareness.

Per-Site CageFS Isolates (2026): CloudLinux launched a beta of per-site filesystem isolation in January 2026, extending CageFS isolation to individual websites within the same hosting account. Previously, CageFS isolated accounts from each other but all sites within one account shared a filesystem view. Per-site isolates mean a compromised plugin on one WordPress site can’t read the files of another WordPress site on the same account. Phase 2, adding per-site PHP Selector support, followed in February 2026.

PHP Selector

The PHP Selector is a CloudLinux component that lets each hosting account choose its own PHP version and extensions independently of other accounts on the same server.

Standard shared hosting typically runs one PHP version server-wide. When a hosting provider upgrades the server from PHP 7.4 to PHP 8.1, every site on that server moves to the new version simultaneously. Sites that haven’t been tested on the new version can break.

With the PHP Selector, each account chooses from the available PHP versions: 7.4, 8.0, 8.1, 8.2, 8.3, and others depending on what the provider makes available. Over 120 PHP extensions can be enabled or disabled per account. A site that requires an older PHP version for a legacy plugin can stay on 7.4 while the account next to it runs 8.3.

This is particularly useful for agencies and developers managing multiple client sites with different requirements. One cPanel account can run multiple WordPress installations each on a different PHP version, without conflict.

The PHP Selector works on top of CageFS. Because each account already has its own isolated environment, PHP can run in genuinely different versions without the accounts interfering with each other.

MySQL Governor

MySQL Governor monitors database usage per account in real time and throttles MySQL and MariaDB queries when a user exceeds their allocation. Without this, a single account running heavy database queries during a traffic spike can saturate the database server and slow every other site’s query responses.

With MySQL Governor, the same heavy query load is throttled to the account’s allocation. Using the dbtop utility, server administrators can see per-account database usage in real time and identify which accounts are consuming disproportionate resources.

HardenedPHP

HardenedPHP backports security patches to old PHP versions that are no longer maintained by the PHP.net community. PHP 7.2, 7.1, 7.0, and 5.6 are end-of-life at the official level, but a significant portion of the web still runs on them. When vulnerabilities are discovered in these versions, no official patches are released.

HardenedPHP provides security fixes for these unsupported versions, allowing sites that can’t immediately upgrade to a supported PHP version to remain protected in the interim.

CloudLinux and Imunify360

CloudLinux Inc also makes Imunify360, a security product that many hosting providers deploy alongside CloudLinux OS. The two products are complementary rather than redundant.

CloudLinux OS handles isolation and stability at the operating system level: LVE limits resource consumption, CageFS isolates filesystems, PHP Selector provides version flexibility, MySQL Governor manages database load.

Imunify360 handles active security at the application level: a web application firewall (WAF), real-time malware scanner, brute force protection, and Proactive Defense PHP runtime sandbox that catches malicious code as it executes rather than after the fact.

The combination of CloudLinux OS and Imunify360 is now the industry standard stack for serious shared hosting providers. ConfigServer Firewall (CSF), which many providers used historically, has reached end of life and Imunify360 is the supported replacement.

What to Check as a Hosting Customer

When evaluating a shared hosting provider, CloudLinux is a meaningful quality signal. A provider running CloudLinux has paid for the licence and is operating a more technically sophisticated shared hosting environment than one running standard Linux.

Things worth checking:

Does the provider run CloudLinux? This is sometimes stated directly in tech specs or the plan feature list. If it isn’t mentioned, it’s reasonable to ask support.

Are CageFS and LVE both active? Some providers run CloudLinux but don’t enable all components on entry-tier plans. Checking whether CageFS is enabled on your specific plan is worth a quick support question if security is a priority.

Is the PHP Selector available? This is usually visible directly in cPanel as a “Select PHP Version” option. If it’s there, PHP Selector is active.

Does the plan include Imunify360? Some providers include it on all plans, others only on higher tiers. The difference is meaningful for active security scanning and malware removal.

Most shared hosting plans from reputable providers include CloudLinux as standard. It’s one of the reasons shared hosting from established providers is meaningfully safer than running the same workload on an unmanaged VPS without equivalent isolation.