Vendere hosting web con CyberPanel

CyberPanel è il pannello che i provider di hosting con OpenLiteSpeed citano più spesso accanto a DirectAdmin. Misurato su GitHub il 21 agosto 2026: 2.007 stelle, 723 fork e 362 issue aperte, a fronte di un ritmo di rilascio più lento della maggior parte dei suoi pari.

Dispone di un’API REST, e tutto ciò che serve per venderci hosting (creare un sito, sospenderlo, cambiarne il pacchetto, eliminarlo) fa parte di quell’API. Ciò che non ha è qualcosa che decida quando fare queste cose, e ciò che invece ha è un insieme di risposte facili da leggere male.

Prima di tutto: l’accesso all’API è disattivato

Su un CyberPanel nuovo l’API è disattivata, e questo vale anche per il suo amministratore principale. La attivi in Users → API Access, per l’utente admin. Non serve altro; si accede con le credenziali che ha già.

La lasci disattivata e ogni chiamata torna come API Access Disabled. qualunque cosa invii. La parte che costa un pomeriggio è l’ordine: CyberPanel controlla questo flag prima di controllare la password, quindi con esso disattivato una password corretta e una errata restituiscono lo stesso identico 403. Tutto punta alle sue credenziali mentre il problema è una casella più in là.

Una volta attivato il flag, il contratto sottostante è pulito e davvero utile:

password corretta   → HTTP 200  {"verifyConn": 1}
password errata     → HTTP 401  {"verifyConn": 0, "error_message": "Invalid password."}
utente sconosciuto  → HTTP 404  {"error_message": "Administrator not found."}

Tre situazioni, tre azioni diverse per il cliente, tutte distinguibili.

L’amministratore deve chiamarsi admin

Non un’impostazione: una condizione, e viene da CyberPanel e non da qualcosa costruito al di sopra. Parte della sua API è protetta da un controllo letterale sul nome che rifiuta ogni utente diverso da admin, e quella parte è precisamente quella che elenca i siti web del pannello e segnala a che punto è arrivato un sito in fase di creazione.

Entrambe sono inevitabili se vuole venderci hosting: serve l’elenco per sapere cosa esiste, e serve la segnalazione dei progressi per il motivo esposto nella sezione successiva. Un amministratore rinominato non è utilizzabile, e qualsiasi cosa costruisca dovrebbe dirlo durante il test di connessione, prima che il suo primo ordine lo scopra per Lei.

Un account è un dominio, non un nome utente

Questa è la differenza strutturale rispetto a DirectAdmin, cPanel e Virtualmin, e cambia il modo di modellare il prodotto.

Il record di sito web di CyberPanel ha un campo domain univoco, e ogni comando lo prende di mira: l’eliminazione prende domainName, la sospensione e il cambio di pacchetto prendono websiteName, e tutti e tre cercano il sito per dominio. Non c’è alcun nome utente da indirizzare. L’utente unix è generato, non scelto: cinque lettere estratte dal dominio più quattro cifre casuali. Misurato per provibr-test-1.example.com: provi7346, con la home directory che prende il nome dal dominio, non dall’utente. Non può scegliere quel nome, non può prevederlo, e compare in esattamente una risposta dell’API e in nessun elenco.

Una conseguenza che vale la pena conoscere prima del suo centesimo account: creare un sito web crea anche, al di sotto, un login del pannello con l’accesso all’API abilitato, e questo login sopravvive all’eliminazione del sito. Misurato dopo un’eliminazione: utente unix sparito, home directory sparita, vhost sparito, riga del database sparita; il login del proprietario ancora presente. Il percorso di pulizia di CyberPanel è protetto da un controllo che non può riuscire nel momento in cui viene eseguito, e l’errore che ne deriva viene inghiottito. Se nulla al di sopra del pannello lo rimuove, ogni cliente disdetto lascia dietro di sé un login.

Creare un sito web annuncia il successo prima di sapere

Questa è la cosa più importante da capire dell’API di CyberPanel.

createWebsite risponde in circa tre secondi con:

{"status": 1, "createWebSiteStatus": 1, "error_message": "None",
 "tempStatusPath": "/home/cyberpanel/2424", "LinuxUser": "provi7346"}

Questo arriva prima che gran parte del lavoro sia avvenuta: l’endpoint costruisce una riga di comando, la avvia senza attendere e restituisce il controllo. Il progresso reale vive in un file di stato, leggibile tramite una chiamata separata. Misurato, una creazione reale:

+ 2,8s   10%  Creating DNS records..
+ 4,8s   25%  Setting up directories..
+ 6,9s   70%  Setting up SSL..        ← resta qui per 28 secondi
+35,3s   80%  Creating mail child domain..
+49,5s  100%  Website successfully created. [200]

Circa cinquanta secondi, di cui circa ventotto sono un tentativo SSL che il pannello compie in ogni caso: l’API sovrascrive quel flag senza condizioni, quindi non c’è modo di creare un sito senza SSL. Su un dominio che non risolve ancora pubblicamente, sono ventotto secondi di attesa per un certificato che non arriverà.

E la prima risposta non è un verdetto. Misurato con dati volutamente errati:

Solo la forma del dominio e dell’email viene controllata subito. Se il dominio è libero, e se il pacchetto esiste, si vede soltanto nel file di stato. Un’integrazione che si fida della prima risposta annuncerà un ordine riuscito per un dominio già occupato.

Altri due dettagli rendono il sondaggio più difficile di quanto sembri. Leggere uno stato completato elimina il file, quindi un secondo sondaggio restituisce «file inesistente» con un flag «non ancora finito»: un client che sonda una volta di troppo vede per sempre «ancora in corso», per una creazione che è riuscita. E la chiamata di stato vive soltanto sulla superficie riservata all’amministratore, motivo per cui il requisito del nome admin visto sopra non è facoltativo.

La sospensione è un trucco del server web, non un blocco dell’account

Sospendere e riattivare sono la parte ben educata di quest’API: entrambe hanno effetto immediato, e l’elenco stesso del pannello mostra subito il nuovo stato.

Ma sappia cosa fa. CyberPanel riscrive la configurazione vhost del sito su una pagina di sospensione e riavvia il server web. L’utente unix non viene bloccato; FTP, posta e database continuano a funzionare. Il sito web diventa irraggiungibile e nient’altro. Questo differisce da DirectAdmin, e conta nel momento in cui usa la sospensione per far rispettare un pagamento.

Ancora una cosa, che merita una costante nel suo codice anziché una variabile: l’implementazione è if state == "Suspend": … else: <riattivare>, senza alcuna validazione del valore. Misurato su un sito reale:

1. state:"Suspend"  → elenco: Suspended
2. state:"suspend"  → {"websiteStatus": 1, "error_message": "None"}
3. elenco:          → Active     ← una lettera minuscola ha riattivato il sito

Un errore di battitura riattiva in silenzio un cliente sospeso e annuncia un successo.

Cambiare pacchetto cambia la contabilità, e nient’altro

changePackageAPI restituisce in circa 270 millisecondi e il pannello mostra il nuovo nome del pacchetto. Misurato poi dall’interno del server, con un pacchetto con limiti volutamente diversi: la quota di disco era invariata (soft 0, hard 0) e la configurazione vhost portava ancora i limiti di memoria e di processo del vecchio pacchetto.

Non è stato applicato nulla. L’intera operazione è un aggiornamento di un campo del database. Legga il nome del pacchetto in CyberPanel come amministrazione, non come un limite che l’ha seguito, e qualsiasi cosa al di sopra del pannello dovrebbe dirlo anziché lasciar intendere che un upgrade abbia avuto effetto.

Non ci sono dati di consumo

CyberPanel è l’unico pannello di controllo in Provibr senza grafici di consumo, e non è un’omissione dell’integrazione: il pannello non lo misura.

Il traffico è calcolato e poi scartato: non raggiunge mai l’elenco. Il consumo di disco proviene da una cache memorizzata sul record del sito, e su un sito appena creato quel campo è vuoto, quindi il valore riportato ricade a zero. Uno zero proveniente da una cache vuota non si distingue da un sito che davvero non consuma nulla. Un grafico che resta a zero per sempre sembra una misurazione; ecco perché non ce n’è nessuno.

Cosa ne fa Provibr

Provibr si collega tramite un agente all’interno della sua rete che si connette verso l’esterno, così il pannello non deve esporre nulla. Chiede quattro cose: l’indirizzo del pannello inclusa la porta 8090, il nome utente admin, la password di quell’amministratore e (finché il pannello usa ancora il certificato con cui è stato fornito) l’impronta digitale SHA-256 da fissare.

Quest’ultima non è facoltativa in pratica. Ogni CyberPanel nuovo presenta lo stesso certificato autofirmato, rilasciato a www.example.com e firmato da CyberPanel stesso. Un browser lo definisce quindi errato anziché autofirmato, e la catena non viene mai validata. Fissare l’impronta significa fidarsi di quel solo certificato anziché disattivare la verifica. Metta il proprio certificato sul nome host del pannello e la catena si valida da sola; a quel punto lasci il campo vuoto.

Sia consapevole di cosa sia questa password. CyberPanel non ha alcun token API che copra questi comandi: all’interno della sua stessa API la via del token è abilitata o disabilitata per endpoint, e le quattro che creano, sospendono, cambiano pacchetto e rimuovono un sito richiedono tutte la password. Quindi è la password completa del suo amministratore principale.

Una volta sistemato tutto ciò: i pacchetti diventano vendibili come piani web sotto un nome e un prezzo suoi, gli ordini creano i siti e attendono il risultato reale anziché la prima risposta, sospendere e riattivare funzionano su richiesta e quando supera la capacità, e i siti web già esistenti possono essere importati.

Cosa non fa

Provibr gestisce i siti web, non il pannello: non installa CyberPanel, non lo aggiorna e non modifica alcuna impostazione del server. Non c’è console. DNS, caselle di posta e database restano intatti: CyberPanel fa tutto questo da solo e nulla al di sopra li pilota. E non ci sono grafici di consumo, perché non c’è nulla di onesto da tracciare.

Non deve puntare tutto su un solo pannello. Provibr fa girare oggi i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco fianco a fianco, in un solo inventario, con un solo modello di permessi e un solo registro delle attività.