Guides

Free CloudLinux does not exist. Here is what you can have without paying.

Seven dollars a month for one account, eighteen for unlimited, and no free edition. But half of what CloudLinux does can be built with systemd — and one panel now has it built in.

Daniele Bambagioni · 29 September 2026 · 4 min read

If you are searching for "CloudLinux free", the short answer is: it does not exist. CloudLinux OS is licensed per server, and today's list prices are these:

Edition Hosting accounts 1 server 50+ servers
Solo 1 $7 a month $4 a month
Admin up to 5 $12 a month $7 a month
Shared Pro unlimited $18 a month $13 a month

The only free thing is the 30-day trial, with every feature. After that, you pay.

But the real question is not "how do I get CloudLinux without paying" — that road leads only to pirated licences and compromised servers. The question is: of the things CloudLinux does, which do I actually need, and which can I have without a licence?

What CloudLinux does, piece by piece

LVE — caps each account's CPU, memory, processes and I/O. It is why a customer who loops a WordPress plugin only slows themselves down.

CageFS — every user sees their own system: they cannot list the other sites, read all of /etc, or see anyone else's processes.

MySQL Governor — caps the work an account can ask of the database, and kills runaway queries.

SecureLinks — stops one site publishing another's files through a symbolic link.

Version selectors for PHP, Python, Ruby and Node: each customer picks their interpreter.

Imunify360 — antimalware and application firewall, sold separately.

What you can have for free, and how

Per-account limits: yes, with systemd. On a modern Linux kernel, cgroup v2 does what LVE does. One slice per account and a PHP-FPM service inside it:

# /etc/systemd/system/customer-mario.slice
[Slice]
CPUQuota=50%
MemoryMax=512M
TasksMax=100
IOReadBandwidthMax=/dev/sda 50M

then the customer's PHP pool goes inside that slice with Slice=customer-mario.slice in its service. It works, it costs nothing, and the kernel is the standard one. You are the work: writing the units, keeping them in step when a customer changes package, and noticing when somebody hits their limits.

CageFS-style isolation: yes, with namespaces. The systemd directives ProtectSystem=strict, ProtectHome, PrivateTmp, ReadWritePaths and InaccessiblePaths build a very similar sandbox. With PrivateMounts and some care you can hide other people's processes too.

The database governor: partly. MariaDB has MAX_USER_CONNECTIONS and max_statement_time, which cover the common case (the customer who opens a hundred connections, and queries that never end). Per-user database CPU accounting, no: that is the Governor.

Python and Ruby version selectors: no. This is the piece you cannot replicate with a few lines of configuration, and it is the best reason to pay for CloudLinux if your customers use them.

Antimalware: alternatives yes, ClamAV and ModSecurity rules, but it is not Imunify360.

What do-it-yourself costs you in time

This is the line nobody puts in the budget. Writing systemd units for twenty customers is an afternoon. Keeping them in step with the packages you sell, noticing that an account is banging against its limits, rebuilding it all when you add a server: that is the real work, and it never ends. Eighteen dollars a month for Shared Pro is less than half an hour of your time.

So the honest choice is between three roads: pay for CloudLinux if you sell serious shared hosting on cPanel and your customers use Python and Ruby; do it by hand if you have few accounts, can write systemd units and enjoy it; or use a panel that includes it.

The third road: a panel that has it built in

For a few days now there has been a fourth possibility worth knowing about: Koapanel, a control panel for Ubuntu 24.04, has an isolation and limits module included in the price, with no modified kernel and no separate licence.

We measured it ourselves. Two accounts on a single-core VPS, one saturates the CPU, we measure the other one's site:

neighbour idle while the other saturates
Without the module 5 ms 24 ms
With the module 5 ms 10 ms

With a 50% cap the offending account took exactly 50% of the CPU. And the sandbox holds: a site's PHP cannot list /var/www, cannot read the other accounts' homes, cannot write to /etc or /run, and sees zero processes out of 213.

On paper the match with CloudLinux is almost item for item: per-account limits like LVE, a sandbox like CageFS, a database limiter like MySQL Governor, symbolic-link protection like SecureLinks. What is missing are the Python and Ruby selectors (Node and Python are there, but as site applications) and an equivalent of Imunify360.

The arithmetic, for a server with thirty sites: CloudLinux Shared Pro at $18 a month plus the panel's own licence, against €14.90 a month for Koapanel with the isolation inside. And up to three sites for personal use, free.

The full review, with every measurement · Which panel for a single site

In two lines

Free CloudLinux does not exist, and looking for it is a good way to get hurt. Per-account limits and the sandbox can be built by hand with systemd, paying nothing but paying in time. If you need that time for something else, either you pay for CloudLinux, or you pick a panel that already has it.


Koapanel is a Prime Software product. The tests and measurements are ours and can be reproduced with the commands given in the review.

Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).