CloudLinux Explained: CageFS, LVE, PHP Selector and the Full Shared Hosting Isolation Stack

CloudLinux is the operating system layer that separates shared hosting from the Wild West of everyone sharing everything on one server. Without it, one badly configured WordPress site on your server can take down your site too. With it, every account gets its own container, its own resource limits, and its own PHP version. This guide explains every component in depth so you can evaluate any shared host intelligently.

What CloudLinux Is and How It Sits in the Server Stack

CloudLinux is an operating system, not a plugin or add-on. It replaces the standard Linux kernel with a patched kernel that adds per-account isolation at the OS level. It is built on top of AlmaLinux (formerly RHEL), so it maintains compatibility with all the standard hosting software stack: cPanel, Plesk, Apache, Nginx, LiteSpeed, MySQL, MariaDB. The isolation features are added at the kernel level, not through user-space workarounds.

The server stack with CloudLinux looks like this, from bottom to top:

1. Physical hardware (the actual server with CPU, RAM, NVMe storage)
2. CloudLinux kernel (patched Linux kernel with LVE, CageFS, and SecureLinks built in)
3. cPanel/WHM (account management layer that exposes the CloudLinux controls to the host)
4. Per-account cage (each cPanel account gets its own CageFS namespace)
5. Per-account PHP interpreter (PHP Selector assigns each account its own PHP version)
6. Your WordPress site (runs inside the cage, limited by LVE, PHP execution monitored by LVE)

CloudLinux licensing costs the hosting company roughly $12 to $15 per server per month. For a host running 100 servers, that is $1,200 to $1,500 per month in licensing fees. Budget hosts skip CloudLinux to save this cost. This saving decision directly impacts the reliability and security of every site on those servers.

CageFS: Filesystem Isolation Explained at the Kernel Level

CageFS stands for "caged filesystem." The implementation uses Linux kernel features called mount namespaces and bind mounts. Here is what that means in practice:

On a standard Linux server, every process sees the same filesystem tree starting at /. A PHP script running as user "accountA" can technically attempt to open /home/accountB/public_html/wp-config.php. Whether it succeeds depends on file permissions, but permissions are misconfigured all the time.

CageFS replaces this shared view with a per-account view. When CloudLinux starts a PHP process for Account A, the kernel creates a new mount namespace for that process. Inside that namespace:

• Account A's home directory (/home/accounta) is visible and writable
• A read-only copy of shared system binaries (/bin, /usr/bin, /lib) is bind-mounted into the namespace so PHP and bash work
• A filtered view of /proc shows only Account A's processes, not the entire server process list
• No other account's home directory is visible or mounted

The key security property: there is no path Account A's PHP can take to reach Account B's files, because Account B's directory is not mounted in Account A's namespace. Symlinks, relative paths, ../../../ traversal — none of these work across cage boundaries because the target simply does not exist in the cage.

LVE: Per-Account Resource Limits in Depth

LVE (Lightweight Virtual Environment) is the resource limiting layer. Every cPanel account on a CloudLinux server is assigned a set of five resource limits. Exceeding any limit triggers throttling or rejection of new requests in that resource category.

Here are the five limits and what typical shared hosting values look like:

What happens at each limit is important to understand:

• CPU limit hit: New PHP requests queue behind the limit. The request still runs but takes longer. Your site appears slow but does not return errors. This is the most common limit hit on shared hosting during traffic spikes.
• Memory limit hit: PHP processes are killed when they exceed the memory cap. WordPress returns HTTP 500 errors. You will see "fatal error: allowed memory size exhausted" in your error logs.
• I/O limit hit: Disk reads and writes are throttled. Database queries become noticeably slower. WooCommerce checkout may time out. Image resizing during uploads fails.
• Process limit hit: New PHP processes cannot spawn. The site returns HTTP 503 "Service Unavailable." Existing processes continue running until completion.
• Inode limit hit: File creation fails. You cannot upload images, install plugins, write cache files, or update WordPress. You get "No space left on device" errors even though the disk is not full. See the inode limit guide for a full breakdown of this failure mode.

PHP Selector: Per-Account PHP Versions and Extensions

PHP Selector is one of the most practically useful features of CloudLinux for site owners. It allows each account to independently choose:

• Which PHP version to use (currently PHP 5.6, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3)
• Which PHP extensions to enable or disable (imagick, redis, memcached, gd, soap, zip, and 70+ others)
• PHP configuration values (memory_limit, max_execution_time, upload_max_filesize per account)

Without PHP Selector, a host must set one PHP version globally. Changing it for one account changes it for all accounts on the server. This means hosts are forced into a conservative upgrade cycle, often running PHP versions one or two generations behind to avoid breaking legacy apps.

With PHP Selector, the host can run PHP 8.3 on the system level but let any individual account request PHP 7.4 for a legacy app. Each account's PHP processes run through the CageFS-mounted version the account selected. Multiple PHP versions coexist on the same physical server without conflict.

For you as a site owner, this means: you can update your account to PHP 8.2 or 8.3 right now through your cPanel without waiting for the host to upgrade the server globally. No support ticket required. The performance improvement from PHP 8.x over PHP 7.4 is approximately 20% to 35% for typical WordPress workloads, which directly translates to lower TTFB and better LCP scores.

MySQL Governor: Per-User Database Query Throttling

MySQL Governor addresses a shared hosting vulnerability that LVE does not fully cover. LVE limits I/O at the kernel level. But a badly written SQL query that consumes CPU inside the database engine — not disk I/O — can escape LVE's I/O limit and consume massive amounts of database server CPU.

Consider this scenario without MySQL Governor: A WordPress site runs a WooCommerce query like SELECT * FROM wp_postmeta WHERE meta_key = '_price' on a table with 2 million rows and no index on meta_key. MariaDB performs a full table scan. This single query consumes 100% of the database server's CPU for 8 seconds. Every other account's queries are blocked waiting for the database to respond. 400 sites experience database timeouts for 8 seconds because of one missing index.

MySQL Governor monitors database CPU consumption per account continuously. When an account's queries exceed a configurable CPU percentage threshold for a defined time window, Governor throttles that account's subsequent queries by introducing artificial delays. The runaway query gets slower. Every other account continues at full speed. The host can configure thresholds and response times.

Governor also logs all throttling events, giving the host and the account owner visibility into which queries are causing problems. For performance analysis, the MySQL Governor log is more useful than generic slow query logs because it attributes resource consumption to specific accounts.

SecureLinks: Blocking Symlink Traversal Attacks

SecureLinks is a CloudLinux kernel patch that prevents a specific but historically common attack class. The attack uses symbolic links to escape filesystem boundaries.

The attack without SecureLinks:

1. Attacker compromises Account A through a vulnerable WordPress plugin
2. Attacker creates a symlink: ln -s /home/accountb/public_html/wp-config.php /home/accounta/public_html/steal.php
3. Attacker requests https://accounta.com/steal.php via the browser
4. Apache follows the symlink. The OS resolves the path to /home/accountb/wp-config.php. The file permissions on the symlink show Account A as owner. Access is granted.
5. Account B's database credentials, secret keys, and table prefix are now in the attacker's hands

SecureLinks adds a kernel-level ownership check before following any symlink. If the symlink target is owned by a different user than the process following it, access is denied. The PHP process running as Account A is owned by Account A's system user. Account B's wp-config.php is owned by Account B's system user. The ownership mismatch causes the kernel to deny the access at the filesystem layer, before any file permissions are even checked.

This is why CageFS and SecureLinks are complementary. CageFS removes Account B's files from Account A's visible filesystem. SecureLinks provides a second layer: even if somehow a path to Account B's files exists in Account A's view, ownership verification blocks access. Defense in depth.

HardenedPHP: Security Patches Beyond End-of-Life

PHP versions reach official end-of-life (EOL) on a published schedule. After EOL, the PHP project stops releasing security patches. Any known vulnerability discovered after EOL remains unpatched in the official release.

CloudLinux's HardenedPHP program maintains patched versions of PHP beyond EOL dates. The backporting applies security fixes from newer PHP versions (and from vulnerability reports) to older branches that would otherwise be unpatched:

• PHP 5.6 (EOL December 2018): HardenedPHP continued patches through 2026
• PHP 7.0 (EOL December 2019): HardenedPHP patches available
• PHP 7.1 (EOL December 2019): HardenedPHP patches available
• PHP 7.2 (EOL November 2020): HardenedPHP patches available
• PHP 7.3 (EOL December 2021): HardenedPHP patches available
• PHP 7.4 (EOL November 2022): HardenedPHP patches available

This is critical for hosts that offer PHP Selector with legacy PHP versions. Without HardenedPHP, offering PHP 5.6 in 2026 would mean serving known-vulnerable software. With HardenedPHP, the old PHP binary has the security patches even though the official project stopped maintaining it.

Imunify360: The Malware Layer That Completes the Stack

CloudLinux developed Imunify360 as a separate product that most CloudLinux hosts also deploy. It adds a web application firewall (WAF), malware scanner, real-time file system monitoring, and reputation-based IP blocking on top of the CloudLinux isolation stack.

Where CloudLinux components contain the blast radius of a compromise (CageFS, LVE, SecureLinks), Imunify360 tries to prevent the compromise in the first place and detect it immediately if it happens:

• WAF: Inspects incoming HTTP requests for attack patterns (SQL injection, XSS, LFI, RFI) and blocks malicious requests before they reach WordPress. The WAF rule set is updated continuously by CloudLinux's research team.
• Malware scanner: Scans all files in all cPanel accounts continuously using a signature database of known malware. Infected files are quarantined automatically. You receive an email notification.
• Proactive Defense: An AI-based behavioral scanner that detects PHP code behaving maliciously even if it does not match any known signature. If a PHP file starts reading other accounts' files or trying to send spam, Proactive Defense quarantines it.
• IP reputation: Integrates with a shared blocklist of known malicious IP addresses. Requests from known attack sources are blocked at the server level before they hit Apache or Nginx.

The combination of CloudLinux (isolation and resource limits) and Imunify360 (detection and prevention) is the de facto standard security stack for quality shared hosting in 2026. A host advertising both is offering a meaningfully more secure environment than a host with neither.

How to Read LVE Stats in WHM and cPanel

If you are a site owner on CloudLinux shared hosting, you have access to your LVE stats in cPanel. Here is how to interpret them:

In cPanel, navigate to the "Resource Usage" section. You will see a dashboard with five panels — one per LVE resource. Each panel shows:

• Current usage as a percentage of your limit
• Average usage over the last 24 hours
• Faults: the number of times you hit your limit in the last 24 hours. Any fault means your site was throttled at that moment.

Via SSH, you can run more detailed queries:

# Show your LVE resource usage for today
lveinfo --user=yourusername --period=today --show-all

# Show entry point (request) faults by hour
lveinfo --user=yourusername --period=today --by-fault ep

# Show which processes were killed by memory limits
sar -v -f /var/log/sa/saXX | grep memory

If you are the host (accessing WHM), the "LVE Manager" section shows stats for all accounts simultaneously, sorted by resource usage. You can see at a glance which accounts are consistently hitting limits and need a plan upgrade, and which accounts are using almost nothing and could be moved to a denser package.

CloudLinux vs Container Isolation: What Is Actually Different

Premium managed hosts like Kinsta and WP Engine use container isolation (Docker, LXC, or Kubernetes) instead of CloudLinux. The comparison is important to understand:

The practical conclusion: CloudLinux shared hosting is significantly safer than raw Linux shared hosting without CloudLinux. It is not as isolated as running in a dedicated container. But at shared hosting prices ($3 to $15/month), CloudLinux + Imunify360 provides a security posture that would have required dedicated hosting just 10 years ago.

How to Verify Whether Your Host Uses CloudLinux

Four verification methods, from easiest to most technical:

1. Check cPanel for LVE Manager: If your cPanel home page has a "Resource Usage" or "LVE Manager" widget, CloudLinux is running. This is the simplest check.
2. Ask support: Ask your host directly "Do you use CloudLinux and Imunify360 on your shared hosting servers?" A quality host will confirm and describe the configuration. Silence or vague answers are a yellow flag.
3. SSH into the server: Run cat /etc/cloudlinux-release. If CloudLinux is installed, this file exists and shows the version (e.g., "CloudLinux release 8.9 (Sodalite)"). If the file does not exist, CloudLinux is not installed.
4. Check running processes: Run ps aux | grep lve via SSH. If you see processes like lvectl or clnodestat, CloudLinux is running.

Checking for CageFS specifically: if you are in a CageFS cage, ls /home will show only your own username, not all usernames. On a server without CageFS, ls /home shows every account's directory name (a privacy and security exposure in itself).

Where to Go Next

CloudLinux solves the isolation and resource fairness problems on shared hosting, but it does not solve the performance problem. Your site is still limited by the CPU generation and contention on the shared server. If you are consistently hitting LVE CPU or memory limits, the right solution is to upgrade to a managed VPS where you get dedicated resources. The PassMark CPU benchmark guide helps you evaluate the hardware quality of any host you are considering. For a complete picture of all the layers that affect your WordPress site's speed, the TTFB guide explains what the server stack contributes and what you control on the front end.

FAQ: CloudLinux, CageFS, and Shared Hosting Isolation

What is CloudLinux and why do shared hosts use it?

CloudLinux is an operating system built on top of RHEL (Red Hat Enterprise Linux), now built on AlmaLinux, that adds a kernel-level isolation and resource limiting layer specifically designed for shared hosting. Without CloudLinux, all accounts on a shared server share the same filesystem, the same PHP binary, and the same MySQL connection pool. One misbehaving account can exhaust CPU, memory, or disk and bring down every other account. CloudLinux solves this by enforcing per-account containers (CageFS), per-account resource caps (LVE), per-account PHP versions (PHP Selector), and per-account database query limits (MySQL Governor). Hosts use it because it is the industry standard tool for making shared hosting safe and predictable.

What exactly does CageFS isolate?

CageFS creates a private filesystem view for each cPanel account using Linux kernel namespace and bind mount mechanisms. Inside the cage, the account sees: (1) its own home directory as /home/username, (2) a set of read-only shared binaries and libraries that all accounts need (bash, ls, PHP, etc.) mounted from a shared pool, and (3) specific /proc and /dev entries required for basic operation. What the account cannot see: other accounts' home directories, other accounts' /proc entries, server configuration files containing database passwords or API keys, and anything outside its cage. A hacker who compromises Account A via a vulnerable plugin cannot read Account B's wp-config.php because Account B's files are literally not visible in Account A's filesystem view.

What are the five LVE resources and what happens at each limit?

LVE caps five resources per account. (1) CPU: measured in percent of a core, typically 100% to 400% (1 to 4 cores). If you hit the CPU limit, new PHP requests queue and take longer. The site slows but does not error. (2) Physical Memory (pmem): typically 512 MB to 2 GB. If you hit the memory limit, PHP processes are killed with a 500 error. (3) I/O: measured in KB/s, typically 1 MB/s to 5 MB/s. Disk reads and writes are throttled when the limit is hit, making database queries and file operations slower. (4) Processes (NPROC): typically 20 to 50 concurrent processes. If you hit the process limit, new PHP processes cannot start and the site returns 503. (5) Inodes: typically 100,000 to 250,000 filesystem entries. If you hit the inode limit, new files cannot be created and WordPress cannot write to the database or upload files.

How does PHP Selector work and why does it matter?

PHP Selector allows each cPanel account to independently choose its PHP version (currently PHP 5.6 through 8.3 are available) and its enabled PHP extensions, without requiring the host to change global server configuration. Technically, PHP Selector installs a per-user PHP interpreter via CloudLinux's alt-php packages, and uses a selector mechanism in the CageFS environment to redirect PHP execution to the user-chosen version. This matters because a single server may host WordPress sites (which need PHP 8.2), legacy Joomla installs (which may need PHP 7.4), and custom apps (which may need specific extensions like imagick or redis). Without PHP Selector, the host would have to set one global PHP version for all accounts, leaving legacy apps broken or newer apps unable to use modern features.

What does MySQL Governor do and how does it differ from LVE I/O limits?

MySQL Governor is a separate CloudLinux module that monitors and limits per-user MySQL and MariaDB query execution. LVE I/O limits throttle disk I/O at the kernel level for all operations. MySQL Governor specifically monitors SQL query execution: CPU time spent per user inside the database engine. If one user's queries consistently consume more than their allowed MySQL CPU share, Governor throttles that user's subsequent queries. This is important because a single misconfigured WordPress query (like SELECT * without a WHERE clause on a 500,000 row table) can consume 100% of the database server's CPU for seconds. Governor detects this per-user overage and throttles the offending user's next queries, protecting every other account on the database server.

What is SecureLinks and what attack does it prevent?

SecureLinks is a CloudLinux kernel patch that prevents symlink-based traversal attacks. The attack it prevents works like this: a hacker who has compromised Account A creates a symbolic link pointing to Account B's wp-config.php (example: /home/accounta/public_html/steal.php -> /home/accountb/public_html/wp-config.php). On a server without SecureLinks, when PHP follows the symlink, the OS checks the symlink's permissions (owned by Account A) and grants access. Account A's PHP can now read Account B's database credentials. SecureLinks adds a kernel-level check: before following a symlink, verify that the symlink's target is owned by the same user as the process following it. If not, deny access. This eliminates an entire class of shared hosting attacks.

What is HardenedPHP and what does it do?

HardenedPHP is a CloudLinux initiative that backports security patches to older PHP versions after their official end-of-life date. For example, PHP 5.6 reached end of life in December 2018, meaning the PHP project stopped releasing security patches for it. HardenedPHP continued patching PHP 5.6 for security vulnerabilities through 2026. This allows hosts to run legacy applications on older PHP versions while still receiving security patches. Without HardenedPHP, a host running PHP 5.6 for legacy apps would be running unpatched software vulnerable to known exploits. HardenedPHP also applies patches to PHP 7.1, 7.2, 7.3, and 7.4 beyond their official end-of-life dates.

Which hosting providers use CloudLinux?

Most quality shared hosting providers use CloudLinux. ChemiCloud, FastComet, A2 Hosting, InMotion Hosting, and Namecheap Shared Hosting all run CloudLinux. SiteGround migrated away from cPanel and CloudLinux to their own custom isolation stack (which achieves similar goals). WP Engine, Kinsta, and Cloudways use container isolation (Docker/LXC/Kubernetes) instead of CloudLinux because they do not run cPanel. ScalaHosting uses SPanel with their own isolation stack. The easiest way to verify: ask the host directly if they use CloudLinux, or check if your cPanel account has 'LVE Manager' or 'Resource Usage' in the sidebar. If it is there, CloudLinux is running.

How do I check my account's LVE resource usage in cPanel?

In cPanel, look for 'Resource Usage' or 'LVE Manager' in the home page. If your host uses CloudLinux, this widget shows your current CPU, memory, I/O, and process usage against your limits, updated every few minutes. You will see usage expressed as a percentage of your limit plus the number of 'faults' (times you hit the limit). If you are consistently at 80% or above on any resource, you are approaching a limit. Zero faults means you have never hit a limit. High fault counts mean the limit is affecting your site. You can also check via SSH: run lveinfo --user=yourusername --period=today --by-fault ep to see entry point faults by hour.

Does CloudLinux add performance overhead to shared hosting?

The overhead is real but small. CageFS adds approximately 1-3% CPU overhead from the namespace and bind mount operations each time a process accesses the filesystem. LVE enforcement adds less than 1% overhead when you are under your limits; it only adds significant latency when you are being actively throttled. MySQL Governor adds monitoring overhead of roughly 1-2% of database CPU. In practice, the overhead is completely invisible to users on a well-provisioned server. The performance benefit of not having noisy neighbors destroying your TTFB far outweighs the monitoring overhead. A server without CloudLinux running 400 accounts is more unpredictable than a CloudLinux server running the same load.

What happens when my site gets hacked on a CloudLinux server?

The damage stays contained to your account. CageFS prevents the attacker from reading other accounts' files. LVE prevents the attacker from consuming all server CPU to mine cryptocurrency (a very common post-hack activity). SecureLinks prevents the attacker from using your account's PHP to read other accounts' wp-config.php files. The server-level protections do not stop the hack from happening (that is your responsibility through plugin updates, strong passwords, and a WAF), but they prevent the hack from becoming a multi-tenant incident. Your neighbors are safe. The host's abuse detection systems (Imunify360 on most CloudLinux hosts) will typically detect the malware behavior within minutes and quarantine the compromised files automatically.

How does CloudLinux compare to Docker container isolation?

Docker containers isolate more completely than CloudLinux. A Docker container has its own filesystem root, network namespace, process namespace, and resource limits, all enforced by the kernel. CloudLinux uses CageFS (a partial filesystem isolation using namespaces) rather than full container isolation. The trade-off is: CloudLinux works with existing cPanel-based shared hosting without requiring a container per account. Running 400 Docker containers for 400 shared hosting accounts would be extremely resource-intensive. CloudLinux achieves 90% of the security benefit with far less overhead. Premium managed hosts (Kinsta, WP Engine, Cloudways) use actual containers because they have a smaller account density and can afford the overhead. Budget and mid-tier shared hosts use CloudLinux because it scales to hundreds of accounts per server.