tenantd vs CloudLinux - honest comparison
For prospects evaluating tenantd as a CloudLinux replacement. This page covers what tenantd does well, what tenantd intentionally does NOT do, and the migration path. It is written by tenantd's own engineers; we have an obvious incentive to make tenantd sound good. We keep it honest because the moment a customer feels misled, the support load triples.
Stock kernel, free - and that is the entire pitch
tenantd runs on stock RHEL / AlmaLinux 9 (and 10 as it ships) with the in-tree kernel, at no license cost. CloudLinux ships a forked CentOS/Alma kernel with the LVE module patched in, and licenses it at $7 to $18 per server per month. The forked kernel is why CloudLinux can do per-thread IO accounting on a shared mysqld; it is also why CloudLinux locks you to their kernel update cadence and why your dnf upgrade story differs from every other RHEL-rebuild host you run.
If your fleet already runs stock AlmaLinux 9 and you want CageFS-equivalent isolation without taking the CL kernel and paying the CL license, tenantd is for you. If you specifically need the LVE-Governor's per-thread MySQL IO throttle on a shared mysqld and you cannot promote individual abusers onto dedicated MariaDB instances, tenantd cannot help and CloudLinux is the right choice. That is a technical limit, not a price difference.
Feature matrix
| Capability | CloudLinux | tenantd | Notes |
|---|---|---|---|
| Per-tenant cgroup CPU cap | Yes (LVE) | Yes (cgroup v2 slice) | Identical at the kernel API level. |
| Per-tenant cgroup memory cap | Yes (LVE PMEM) | Yes (MemoryMax) | Same primitive, different name. |
| Per-tenant process count cap | Yes (LVE NPROC) | Yes (TasksMax) | Same. |
| Per-tenant entry-process (FPM children) cap | Yes (LVE EP) | Yes (ENTRY_PROCESSES) | Mapped 1:1 from EP during migration. |
| Per-tenant filesystem view (CageFS) | Yes | Yes (mount-namespace) | |
| Per-tenant shell (SSH) | Yes | Yes (ssh-entry + Match Group) | |
| Per-tenant cron | Yes | Yes (pam_exec + pam-ns-enter) | See the cron note in the FAQ. |
| Multi-PHP (alt-php) | Yes (paid in CL) | Yes (free) | |
| Shared-mysqld per-tenant rate cap | Yes (mysql-governor) | Yes (tenantd governor) | Same SQL surface, cleanroom design. |
| Shared-mysqld per-thread block-IO enforcement | Yes (LVE-Governor) | No - gap by design | cgroup v2 io is domain-only; can't throttle threads. The honest gap. |
| Per-tenant block-IO observability on shared mysqld | Yes | Yes (eBPF) | Read-only. Same numbers, different mechanism. |
| Per-tenant block-IO enforcement via dedicated mysqld | (not the LVE path) | Yes (mysql-promote) |
Promote abusers; the dedicated instance lands under the tenant's slice and full cgroup io works. |
| Per-tenant ProxySQL routing/delay | No | Yes (optional) | For IO-contract tiers. |
| Forked kernel required | Yes | No | Stock kernel - the whole pitch. |
| License fee | $7-18/server/mo | $0 | All features, every server, free. |
The IO-isolation gap - read this before switching
CloudLinux's LVE-Governor enforces per-tenant block-IO caps on a shared mysqld by patching the kernel to attribute IO at thread level. tenantd refuses to patch the kernel, and refuses to read the GPL LVE-Governor source. cgroup v2 io is a domain-only controller: every thread inside one mysqld process shares one io.* bucket. No upstream mechanism lets us split that. MariaDB Resource Groups are nice(2) CPU-ordering only - they do nothing for block IO (MariaDB WL#9467 confirms).
What tenantd does instead:
- The governor catches CPU-burner, connection-exhausting, and lock-storm patterns via
performance_schemapolling plusKILL QUERY/GRANTactions. This handles the noisy-neighbor symptoms even though the underlying IO accounting is shared. Detection-to-termination is sub-2s at p99. mysql-promotemigrates a long-tail abuser onto a dedicatedmariadb@<tenant>.serviceunder their slice. cgroup v2iothen works as expected - full per-tenant attribution and enforcement, because there is exactly one tenant in the mysqld process. Operator-triggered; recommended for tenants who sustain over 70% of their query cap for 7+ days.tenantd-mysql-ebpfattributes block-IO bytes per tenant on the shared mysqld via eBPF - a USDT connection marker (mysql:connection__start) for tenant identity plus theblock_rq_issuekprobe for IO bytes. Read-only observability, so the operator can SEE the noisy neighbor before the customer complains. Numbers, not enforcement.- ProxySQL secondary front door (optional) for tenants on per-query latency contracts.
If your fleet has a substantial population of mid-tier shared-mysqld users who DO need hard per-thread IO caps and you cannot promote them onto dedicated mysqld instances, CloudLinux's LVE-Governor remains the right tool. We say this because it is true, because it builds trust with the prospects who DO have a better tenantd fit, and because the alternative is a furious user three months in.
Honest framing: tenantd delivers roughly 80% of the LVE-Governor outcome - sub-2s noisy-neighbor detection and termination, hard per-user query/connection caps enforced inside MariaDB itself, observability for the rest - without forking mysqld, without a custom kernel, and without a license fee. The remaining 20% (per-tenant IO accounting on the shared mysqld process) is the deliberate cleanroom tradeoff, mitigated by relative throttling on the shared slice and escalation to a dedicated mariadb@<tenant>.service for the long-tail heavy abuser.
Migration path
tenantctl-migrate apply is a single command that reads lvectl list plus cagefsctl --list-enabled, generates tenantd packages from your existing LVE caps, enrolls every caged user, swaps the FPM master, and unmounts CageFS. End-to-end target: under 2 minutes on a host with ~100 users. Roll-back (--rollback) reverses the conversion if anything looks wrong. When it is done, cancel your CloudLinux license.
When NOT to switch to tenantd
- You need shared-mysqld per-thread IO enforcement and cannot promote any long-tail users to dedicated mysqlds. (Gap, by design.)
- You are running CentOS 7 / RHEL 7 era kernels. (tenantd is cgroup-v2-only.)
- You want a single-vendor "kernel + userspace + license" bundle with one support throat to choke for all of it. (tenantd is closed-core userspace on a stock kernel; CloudLinux bundles everything.)
When tenantd is the better fit
- You run AlmaLinux 9 (or 10) on the host kernel and want CageFS-equivalent isolation without giving up your kernel or paying per server.
- You operate up to ~500 cPanel users per host and your worst noisy neighbor is detected via the governor (CPU-burner, conn-exhaust, lock-storm) rather than via raw IOPS contention.
- You have a few mid-tier premium customers who need IO enforcement and you can promote them onto dedicated mysqlds.
Honest answer: most cPanel hosts in 2026 fit the second pattern. That is who tenantd is for, and it costs them nothing. See pricing and support, or head back to the tenantd overview to install.