Guide

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).