Tenant isolation is the single most important security property of any shared or multi-tenant hosting platform. If one customer can read another customer's files, see their processes, or starve the server of CPU and memory, the entire platform fails. For over a decade the reference answer in the cPanel world has been CloudLinux CageFS. Today, a newer model built directly on the Linux kernel - namespaces plus cgroup v2 - has become the foundation that Docker, Podman, and modern control panels rely on. This article compares the two with detailed diagrams, corrects outdated assumptions, and explains which fits a modern platform.
Key takeaways
- CageFS gives each user a filtered, private view of a shared system - excellent file and process-visibility isolation, but coupled to the CloudLinux kernel and LVE.
- Namespaces + cgroup v2 give each user a genuinely independent mini-system (own process tree, mounts, network) on any modern stock kernel - the same model Docker and Podman use.
- For a platform built today, the native kernel stack is broader and more future-proof. Panelica is built on it.
The core difference in one picture
CageFS filters a shared environment so users do not see each other. Full namespacing gives each user a separate environment so the other user effectively does not exist. The diagrams below make this concrete.
What CageFS actually does
CageFS is a virtualized filesystem and a set of tools that lock each user into their own cage. A common misconception is that CageFS is just an advanced chroot. That was closer to the truth years ago, but modern CageFS is more. Under the hood it uses Linux bind mounts and mount namespaces to build a private filesystem view for every user, and it provides each user with a private /proc, so a user only sees their own processes.
In practice, a caged user sees only themselves and system accounts in /etc/passwd, cannot read another customer's home directory, cannot read sensitive server configuration, and only sees their own processes. This is genuinely strong file and process-visibility isolation, and it is mature, battle-tested, and easy to operate. Its limits are two: it is tightly coupled to the CloudLinux kernel and LVE for resource limits, and by design its goal is "users should not see each other" rather than "each user gets a full, independent system" - so there is no separate network stack or independent PID 1 process tree per user.
What Linux namespaces and cgroup v2 do
Namespaces are a native Linux kernel feature. Instead of filtering what a user can see, the kernel gives each workload its own independent instance of a global resource: its own process tree (PID), mount table (Mount), network interfaces and firewall (Network), IPC objects, hostname (UTS), UID/GID mapping (User), and cgroup view. This is the exact model Docker and Podman use, which is why billions of containers run on it in production.
Resource control is handled natively by cgroup v2: CPU shares and quotas, memory and swap limits, block I/O throttling, and process/thread caps. cgroup v2 is no longer the future - it is the default on RHEL 9 and 10, AlmaLinux and Rocky 9 and 10, Ubuntu 22.04 and later, and Debian 12 and later. Even CloudLinux itself now supports cgroup v2 across CloudLinux 8, 9, and 10, defaulting to it on new CloudLinux 10 installs. The industry has converged on this stack.
Correcting the outdated comparison
Several claims about this topic are repeated often but are no longer accurate:
- "CageFS has no PID isolation." Outdated - modern CageFS provides a private /proc, so users do not see each other's processes.
- "CageFS is just chroot." Outdated - it uses mount namespaces and bind mounts, not a plain chroot.
- "CloudLinux only does cgroup v1 / LVE." Outdated - CloudLinux now supports cgroup v2 and defaults to it on CloudLinux 10.
The honest, current distinction is narrower: CageFS gives excellent file and process-visibility isolation but is coupled to the CloudLinux kernel and LVE, and by design does not give each user full network isolation or an independent process tree from PID 1. The native namespace approach does, and it runs on any modern stock kernel.
The foundation question: who builds and controls it?
Beneath the feature checklist lies a deeper question: who actually owns, builds and maintains the isolation technology your platform depends on?
A vendor-locked cage is created and controlled by a single company and a single team, and it only runs on that vendor's own kernel build. Your platform's security roadmap, compatibility, long-term support and pricing all follow the decisions of that one organization.
cgroup and namespaces are different in kind. They are not a product from one vendor - they are part of the Linux kernel itself, designed, reviewed and maintained by the worldwide community of Linux kernel developers, and shipped by default in every Linux distribution. They are the very same primitives the largest cloud platforms and the entire container ecosystem run on, every day, at massive scale. Building on them means building on the most scrutinized and most widely deployed isolation technology in existence - owned by no single vendor, and going wherever Linux goes. That is the strategic reason this foundation is more durable: you are not betting on one company's roadmap, you are betting on Linux.
Feature-by-feature comparison
| Capability | CageFS (+ LVE) | Namespaces + cgroup v2 |
|---|---|---|
| Filesystem isolation | Strong (bind mounts + mount ns) | Strong (mount namespace) |
| Process visibility | Private /proc (own processes) | Full PID namespace, own PID 1 |
| Network isolation | No - shared network stack | Yes - per-user network ns |
| Root isolation | Limited | Strong via user namespace |
| Resource limits | LVE (cgroup v2 on CL10) | Native cgroup v2 |
| Kernel dependency | CloudLinux kernel required | Any modern stock kernel |
| Container model | Partial | Same base as Docker/Podman |
| Performance overhead | Under 1% typical | Under 1% typical |
Performance
Both approaches are fast. Neither is a virtual machine and neither emulates hardware - they share the host kernel directly, so overhead is typically well under one percent for most workloads. Isolation strength here does not come at the cost of meaningful performance, which is why containers replaced heavier virtualization for so many use cases.
Isolation strength ranking
How Panelica approaches isolation
Panelica is engineered directly on these Linux kernel primitives - the same foundation the entire cloud industry trusts - rather than on a vendor-locked filesystem cage tied to one company's kernel. That deliberate choice is why its isolation is both strong today and durable for the long term: it inherits every security improvement the Linux kernel ships, and it depends on no single vendor's roadmap. Its architecture combines five defense-in-depth layers, illustrated below.
Which is better for a modern hosting platform
If you operate inside the existing CloudLinux and cPanel ecosystem, CageFS plus LVE is a pragmatic, mature, well-supported choice, and CloudLinux continues to invest in it - including per-site isolation that separates websites within a single account. If you are building a new hosting platform from the ground up, the stronger and more future-proof foundation is the kernel's own namespaces and cgroup v2, hardened with seccomp and mandatory access control. It delivers independent process, mount, network, user and resource isolation on a stock kernel, with no dependency on a vendor-specific kernel build.
Frequently asked questions
Is CageFS the same as a Docker container?
No. Both use Linux namespaces, but CageFS focuses on filesystem and process-visibility isolation on a shared CloudLinux kernel, while a Docker container adds full network, PID and user namespace isolation plus seccomp and capability restrictions. The container model isolates more dimensions.
Does CageFS isolate network traffic between users?
No. CageFS users share one network stack. Per-user network isolation requires a network namespace, which is part of the namespaces plus cgroup v2 model.
Do namespaces and cgroup v2 require CloudLinux?
No. They are built into the standard Linux kernel and work on AlmaLinux, Rocky, Ubuntu and Debian without any vendor-specific kernel. CageFS, by contrast, requires the CloudLinux kernel.
Is there a performance penalty for namespace isolation?
No meaningful penalty. Namespaces and cgroups share the host kernel directly with no emulation, so overhead is typically well under one percent.
Which approach does Panelica use?
Panelica uses native Linux namespaces and cgroup v2 as the core of a five-layer isolation architecture, hardened with SSH chroot jails, per-user PHP-FPM pools and strict Unix permissions, on the standard kernel.
Conclusion
A vendor-locked cage is mature and effective within its own ecosystem, and it has improved over the years. But it remains the product of a single vendor, tied to that vendor's kernel. Native Linux namespaces and cgroup v2 are part of Linux itself - the most scrutinized and most widely deployed isolation technology in the world - hardened further with seccomp and mandatory access control. That is the foundation Panelica is deliberately built on: as solid, as trusted and as future-proof as Linux itself, and the same foundation that runs the world's container workloads.