CloudLinux gratis non esiste. Ecco cosa puoi avere senza pagarlo.
Sette dollari al mese per un account, diciotto per illimitati, e nessuna edizione gratuita. Ma metà di quello che fa CloudLinux si costruisce con systemd — e un pannello ora ce l'ha dentro.
Daniele Bambagioni · 29 settembre 2026 · 4 minuti di lettura
Se cerchi «CloudLinux gratis» la risposta breve è: non esiste. CloudLinux OS si paga per server, e i prezzi di listino oggi sono questi:
| Edizione | Account ospitati | 1 server | 50 server o più |
|---|---|---|---|
| Solo | 1 | 7 $ al mese | 4 $ al mese |
| Admin | fino a 5 | 12 $ al mese | 7 $ al mese |
| Shared Pro | illimitati | 18 $ al mese | 13 $ al mese |
L'unica cosa gratuita è la prova di 30 giorni, con tutte le funzioni. Dopo, si paga.
La domanda vera però non è «come ottengo CloudLinux senza pagarlo» — quella strada porta solo a licenze pirata e server compromessi. La domanda è: delle cose che fa CloudLinux, quali mi servono davvero, e quali posso avere senza licenza?
Cosa fa CloudLinux, pezzo per pezzo
LVE — limita CPU, memoria, processi e I/O di ogni account. È il motivo per cui un cliente che manda in loop un plugin WordPress rallenta solo se stesso.
CageFS — ogni utente vede un sistema suo: non elenca gli altri siti, non legge /etc per intero, non vede i processi degli altri.
MySQL Governor — limita il lavoro che un account può chiedere al database, e uccide le query infinite.
SecureLinks — impedisce che un sito pubblichi i file di un altro con un link simbolico.
Selettori di versione per PHP, Python, Ruby e Node: ogni cliente sceglie il suo interprete.
Imunify360 — antimalware e firewall applicativo, venduto a parte.
Quello che puoi avere gratis, e come
I limiti per account: sì, con systemd. Su un kernel Linux moderno i cgroup v2 fanno quello che fa LVE. Una slice per account e un servizio PHP-FPM dentro quella slice:
# /etc/systemd/system/cliente-mario.slice
[Slice]
CPUQuota=50%
MemoryMax=512M
TasksMax=100
IOReadBandwidthMax=/dev/sda 50M
poi il pool PHP del cliente va messo dentro quella slice con Slice=cliente-mario.slice nel suo servizio. Funziona, non costa niente, e il kernel è quello standard. Il lavoro sei tu: scrivere le unità, tenerle allineate quando cambi pacchetto a un cliente, e accorgerti quando qualcuno tocca i limiti.
L'isolamento tipo CageFS: sì, con i namespace. Le direttive systemd ProtectSystem=strict, ProtectHome, PrivateTmp, ReadWritePaths e InaccessiblePaths costruiscono una sandbox molto simile. Con PrivateMounts e un po' di attenzione si arriva a nascondere i processi altrui.
Il limitatore del database: in parte. MariaDB ha MAX_USER_CONNECTIONS e max_statement_time, che coprono il caso più comune (il cliente che apre cento connessioni e le query che non finiscono mai). La contabilità della CPU per utente del database, quella no: quella è il Governor.
I selettori di versione per Python e Ruby: no. È il pezzo che non si replica con qualche riga di configurazione, ed è il motivo migliore per pagare CloudLinux se i tuoi clienti li usano.
L'antimalware: alternative sì, ClamAV e le regole di ModSecurity, ma non è Imunify360.
Quanto tempo ti costa il fai-da-te
È la voce che nessuno mette nel conto. Scrivere le unità systemd per venti clienti è un pomeriggio. Tenerle allineate ai pacchetti venduti, accorgersi che un account sta sbattendo sui limiti, ricostruire tutto quando aggiungi un server: quello è il lavoro vero, e non finisce mai. Diciotto dollari al mese per Shared Pro sono meno di mezz'ora del tuo tempo.
Quindi la scelta onesta è fra tre strade: pagare CloudLinux se vendi hosting condiviso serio su cPanel e i tuoi clienti usano Python e Ruby; farlo a mano se hai pochi account, sai scrivere unità systemd e ti diverte; oppure usare un pannello che lo include.
La terza strada: un pannello che ce l'ha dentro
Da qualche giorno esiste una quarta possibilità che vale la pena conoscere: Koapanel, un pannello di controllo per Ubuntu 24.04, ha un modulo di isolamento e limiti incluso nel prezzo, senza kernel modificati e senza licenze a parte.
L'abbiamo misurato noi. Due account su un VPS con un solo core, uno satura la CPU, misuriamo il sito dell'altro:
| vicino a riposo | mentre l'altro satura | |
|---|---|---|
| Senza il modulo | 5 ms | 24 ms |
| Con il modulo | 5 ms | 10 ms |
Con il limite al 50% l'account colpevole ha preso esattamente il 50% della CPU. E la sandbox regge: il PHP di un sito non elenca /var/www, non legge la home degli altri account, non scrive in /etc né in /run, e vede zero processi su 213.
Sulla carta la corrispondenza con CloudLinux è quasi voce per voce: limiti per account come LVE, sandbox come CageFS, limitatore del database come il MySQL Governor, protezione dei link simbolici come SecureLinks. Mancano i selettori di Python e Ruby (Node e Python ci sono, ma come applicazioni del sito) e manca l'equivalente di Imunify360.
Il conto, per un server con trenta siti: CloudLinux Shared Pro 18 $ al mese più la licenza del pannello, contro 14,90 € al mese di Koapanel con l'isolamento dentro. E fino a tre siti per uso personale, gratis.
La recensione completa, con tutte le misure · Quale pannello per un sito solo
In due righe
CloudLinux gratis non esiste, e cercarlo è un buon modo per farsi male. I limiti per account e la sandbox si costruiscono a mano con systemd, senza pagare niente ma pagando in tempo. Se il tempo ti serve per altro, o paghi CloudLinux, o scegli un pannello che quella roba ce l'ha già dentro.
Koapanel è un prodotto Prime Software. Test e misure sono nostri e rifacibili con i comandi indicati nella recensione.
Testo redatto con il supporto dell'intelligenza artificiale e verificato dalla redazione (AI Act, art. 50).