When choosing shared hosting, beneath the surface it all boils down to one question. As the server keeps each account within its limits, so one site cannot slow down or compromise others on the same machine. For years, CloudLinux has been synonymous with that layer of isolation and resource limits. Our panel does the same job, but on a standard AlmaLinux 10 kernel, without a forked kernel and without a per-server license.
This comparison is intentionally honest. We show where we are at full parity, where we are stronger, and where CloudLinux continues to lead. The goal is not to claim that we are better at everything, but to clearly see what you are getting.
In short
- 15 features in full parity. The same level of protection and limits, the same modern kernel mechanisms.
- 3 items where we are stronger. SELinux mandatory access control, standard kernel without fork and no license.
- 1 item where CloudLinux leads. kernel patches without reboot.
Isolation and limits are implemented through Linux cgroups v2, mount namespace isolation and SELinux in enforcing mode. These are the same modern kernel mechanisms used by CloudLinux, with one additional layer (SELinux) and no dependency on a specially modified kernel.
Resource limits
This is the heart of shared hosting: how much CPU, memory and disk space can one account consume before the system slows it down. With us, cgroups v2 does it, with CloudLinux, LVE.
| Characteristic | Our panel | CloudLinux |
|---|---|---|
| CPU limit per order cgroups v2, cpu.max | Yes | Yes (LVE) |
| RAM limit per account cgroups v2, memory.max | Yes | Yes (LVE) |
| I/O bandwidth cgroups v2, io.max | Yes | Yes (LVE) |
| IOPS limit cgroups v2, io.max (riops/wiops) | Yes | Yes (LVE) |
| Entry Processes PHP FPM, pm.max_children per account | Yes | Yes (LVE EP) |
| Number of processes (NPROC) cgroups v2, pids.max | Yes | Yes (LVE) |
| Inode limit project quota (XFS/ext) | Yes | Yes |
Account isolation
Limits tell how much an account can spend. Isolation tells what the account is allowed to see and touch. Here we have one advantage that CloudLinux does not have.
| Characteristic | Our panel | CloudLinux |
|---|---|---|
| File isolation (fake root) mount namespace and FPM chroot | Yes | Yes (CageFS) |
| Mandatory Access Control (MAC) SELinux enforcing by command | Yes | No |
| Connection limit per IP address nginx, limit_conn | Yes | Partially (via Imunify) |
Databases
Here CloudLinux has one thing that we openly admit as their advantage.
| Characteristic | Our panel | CloudLinux |
|---|---|---|
| Limit of DB connections per account MAX_USER_CONNECTIONS and PostgreSQL CONNECTION LIMIT | Yes | Yes |
| Stopping runaway SQL queries connection limit and abuse detector | Yes | Yes (MySQL Governor) |
Runtime and applications
| Characteristic | Our panel | CloudLinux |
|---|---|---|
| Multiple PHP versions per order 7.4 and 8.0 to 8.5, selection by domain | Yes | Yes (PHP Selector) |
| Node.js and Python hosting permanent systemd services per order | Yes | Yes (selectors) |
Web server and security
| Characteristic | Our panel | CloudLinux |
|---|---|---|
| Web server nginx with HTTP/3 (QUIC), Brotli, page and object cache | Yes (nginx) | Yes (Apache or LiteSpeed) |
| Application firewall (WAF) Corazon (OWASP rules) | Yes | Yes (Immunify ModSec) |
| Malware protection Imunify360 or ClamAV and real-time scanner | Yes | Yes (Immunify) |
Kernel and license
A key philosophical difference can be seen here. CloudLinux uses its own, reworked kernel. We stay on the standard AlmaLinux 10 kernel, because all isolation and limit mechanisms are already part of the official Linux kernel today.
| Characteristic | Our panel | CloudLinux |
|---|---|---|
| Kernel standard AlmaLinux 10 (mainline) | Yes (without fork) | Partial (forked kernel) |
| Kernel patches without rebooting security updates and a planned reboot | No | Yes (KernelCare) |
| License and price built into the operating system | Yes (without license) | No (paid per server) |
Where are we stronger?
SELinux (mandatory access control). This is an additional layer that CloudLinux CageFS does not have. Even if the isolation breaks somewhere, the kernel policy still blocks unauthorized access. It's a belt and suspenders, not one for the other.
Standard kernel. All mechanisms (cgroups v2, namespaces, SELinux) are part of official Linux. There is no dependency on a specially modified kernel, so there is no risk of someone else's kernel upgrade slowing us down.
No license. Same class of isolation and limit, without additional cost per server. We put that savings back into the equipment and price for you.
Where CloudLinux is leading
KernelCare. It injects security patches into the kernel without restarting the server. We perform standard security updates with a scheduled reboot, at a time that we announce in advance.
Technical notes
Entry Processes are implemented on the PHP FPM execution layer (pm.max_children per account) and capture how many requests can simultaneously enter the PHP execution path. It covers a typical source of load on shared hosting, for example a sudden surge of visits on a WordPress site. The total number of processes covers a separate cgroup limit (pids.max), so two separate levers, not one.
Isolation and limits are implemented through Linux cgroups v2, mount namespace isolation and SELinux (mandatory access control). It's the same modern kernel mechanisms as CloudLinux, with an additional SELinux layer and no forked kernel or license.
Conclusion
We are in full parity with CloudLinux in 15 out of 19 observed features. In 3 items we are above them (SELinux, standard kernel, no license), and in 1 item they lead (patches without restart). For the vast majority of sites, this means the same or better protection and the same limits.
If you are interested in how this looks on your site in practice, contact us and we will be happy to explain the details.
Technical review. AlmaLinux 10, MariaDB 10.11, PostgreSQL 16.
