Vendere hosting web con HestiaCP

HestiaCP è il pannello di controllo aperto più in salute in circolazione. Rilevato su GitHub il 21 agosto 2026: 4.481 stelle, 345 contributori e tre release in una sola settimana. Offre account, pacchetti, DNS, posta, database e un’interfaccia pulita, e non costa nulla.

Ciò che non offre è un modo per vendere tutto questo. Non c’è un modulo d’ordine, non c’è una fattura, non ci sono solleciti, non c’è un «questo cliente ha smesso di pagare, disattivalo». Cerchi hestiacp billing e, rilevato lo stesso giorno, i primi risultati sono discussioni di forum: persone che chiedono come vendere account HestiaCP, e altre che rispondono con mezzo script.

Questa pagina riguarda lo strato al di sopra: cosa restituisce davvero l’API di HestiaCP, dove La morderà, e cosa deve essere a posto prima di poter mettere un pulsante Acquista davanti a uno sconosciuto.

Cosa offre già HestiaCP

Due cose, e sono le due giuste.

Pacchetti. Un pacchetto HestiaCP descrive ciò che un account può usare: spazio su disco, banda e quanti domini, database e caselle di posta. È il suo catalogo prodotti, definito una volta e richiamato per nome da ogni altra parte.

Un ciclo di vita dell’account che corrisponde a un abbonamento. Creare, sospendere, riattivare, spostare su un altro pacchetto, eliminare; esattamente gli stati che un account di hosting a pagamento attraversa, e per ciascuno c’è un comando:

Il resto di questa pagina riguarda la distanza tra quella tabella e qualcosa su cui poter contare alle tre di notte.

L’API ha due porte, e una delle due mente

POST https://host:8083/api/ accetta due tipi di credenziali, e quale delle due si invia decide quale percorso di codice gestisce la richiesta. Il percorso vecchio prende un nome utente e una password. Il percorso più recente, disponibile da HestiaCP 1.6, prende una chiave di accesso: un id di 20 caratteri e un segreto di 40 caratteri.

Non si comportano allo stesso modo. Inviando un comando che non esiste:

Il percorso legacy segnala successo per un comando che non è mai stato eseguito. La causa è nel codice sorgente di HestiaCP stesso: restituisce OK quando l’autenticazione ha dato zero e il comando non ha prodotto output su stdout. Non guarda mai il codice di uscita del comando stesso, e non imposta mai uno stato HTTP né l’header con il codice di uscita per il risultato. Qualsiasi comando che fallisce in silenzio torna come OK.

Quindi: usi le chiavi di accesso. Non solo perché il percorso legacy può mentire, ma perché una chiave si può revocare da sola, è elencata nel pannello per nome e non mette la password di amministratore del suo pannello nella cassaforte di qualcun altro. E non costruisca nemmeno un ripiego dall’una all’altra: due porte significano due superfici di guasto, e qui la porta di ripiego è quella inaffidabile.

Lo stato HTTP non è la risposta: lo è il codice di uscita

HestiaCP riduce una ventina di codici di uscita interni a quattro stati HTTP. Due conseguenze, entrambe rilevate:

Una mutazione riuscita restituisce 204, non 200. Ogni v-add-user, v-suspend-user, v-delete-user, v-add-web-domain e v-change-user-package torna come HTTP 204 con un corpo vuoto. Un client che accetta solo il 200 rifiuta ogni chiamata che ha funzionato.

L’HTTP 401 significa quattro cose diverse: segreto errato (exit 9), chiave fuori dai suoi permessi (10), indirizzo non consentito (10) e «questo utente è già sospeso» (5). Un client che legge il 401 come «le credenziali sono errate» Le dirà che la chiave è scaduta quando tutto ciò che ha fatto è stato sospendere un account due volte.

Legga Hestia-Exit-Code. Lo stato è una derivata.

Quella che La metterà davvero fuori gioco

Cinque chiamate rifiutate e HestiaCP mette al bando il suo indirizzo. Non è un limite di frequenza da cui si può rallentare: è fail2ban, configurato per impostazione predefinita con maxretry = 5 su /var/log/hestia/auth.log, e finisce in un DROP di iptables. Da lì il pannello non rifiuta le sue chiamate, smette di rispondervi: il suo monitoraggio mostra timeout e sembra un problema di rete.

La parte che coglie di sorpresa è cosa conta come login fallito. Non solo un segreto errato: il controllo delle chiavi di HestiaCP scrive la stessa riga failed to login quando una chiave viene usata per un comando fuori dal suo insieme di permessi. Rilevato, nel registro di autenticazione del pannello stesso:

12:57:52 <key> 84.85.173.142 v-list-users successfully launched
12:57:52 <key> 84.85.173.142 failed to login      ← un comando fuori dall’ambito della chiave

Ne seguono tre regole, e non sono facoltative:

1. 01Non ritentare mai automaticamente dopo un errore di autenticazione o di permessi. Un ciclo di ripetizione su una chiave errata La blocca fuori nel giro di un minuto, e a quel punto il messaggio che il suo cliente vede è «pannello irraggiungibile» anziché «chiave errata», il segnale peggiore possibile, perché punta al problema sbagliato.
2. 02La chiave dev’essere senza ambito, e quindi quella dell’amministratore. Permessi vuoti significano ogni comando, e HestiaCP lo accetta solo per l’utente root. L’insieme di permessi billing incluso ci va vicino ma tralascia v-list-user-packages e v-list-web-domains, i due comandi che leggono il suo catalogo di pacchetti e i domini di un account. Con quell’insieme entrambi tornano vuoti, e una chiave con ambito che li interroga una volta per ciclo di polling La mette al bando puntualmente.
3. 03Il suo testo di errore deve menzionarlo, perché per rimuoverlo serve una shell sul pannello: v-delete-firewall-ban <address> HESTIA.

Vuoto significa nessuno

Un’altra trappola alla prima esecuzione. HestiaCP tiene un elenco di indirizzi autorizzati a usare l’API, in API_ALLOWED_IP. In un’installazione nuova quell’elenco è vuoto, e qui vuoto significa nessuno, non tutti. Ogni chiamata torna 401 con IP is not allowed to connect with API mentre la sua chiave è perfettamente a posto. È il fallimento più probabile all’inizio dell’intera integrazione, e merita un messaggio di errore proprio anziché un generico «autenticazione fallita».

Creare un account richiede due chiamate, e quel divario è reale

DirectAdmin, cPanel e Virtualmin creano un account insieme al suo dominio in una sola chiamata. HestiaCP no:

v-add-user        USER PASSWORD EMAIL [PACKAGE] [NAME]   → crea l’utente
v-add-web-domain  USER DOMAIN [IP] [RESTART] [ALIASES]   → collega il dominio

Se la seconda chiamata fallisce (il dominio appartiene già a qualcuno, oppure il suo formato viene rifiutato), resta un vero utente unix, con una home directory, nessun sito e una riga in ogni conteggio che si esegue. Rilevato con un dominio volutamente non valido: dopo, l’utente esisteva con U_WEB_DOMAINS = 0. Qualsiasi cosa si costruisca deve compensare: se il secondo passaggio fallisce, elimini l’utente e segnali l’errore originale.

Cosa fa Provibr con tutto questo

Provibr si collega a HestiaCP tramite un agente che gira all’interno della sua rete e si connette verso l’esterno, così che nulla sul pannello debba essere esposto. Gli fornisce quattro cose: l’indirizzo del pannello inclusa la porta 8083, l’id della chiave di accesso, il segreto e (finché il pannello usa ancora il suo certificato autofirmato) l’impronta digitale SHA-256 da fissare. L’agente le conserva nella propria cassaforte sul suo host; la piattaforma non può rileggerle.

Da lì:

• I pacchetti diventano vendibili. Un piano di hosting web punta a un pacchetto su un’integrazione, sotto un nome suo, a un prezzo suo.
• Cinque azioni, indirizzate per nome utente: creare con un dominio e un pacchetto, sospendere, riattivare, cambiare pacchetto, eliminare. La creazione in due chiamate è compensata come descritto sopra.
• Il consumo arriva gratis con l’interrogazione. Ogni lettura di v-list-users porta DISK_QUOTA, U_DISK, BANDWIDTH e U_BANDWIDTH per ogni account, tutti in megabyte, così limiti e consumo arrivano sulla pagina del server e nei grafici senza una seconda chiamata che potrebbe restare indietro rispetto alla prima.
• Gli account che esistono già si possono importare. L’agente elenca ciò che è sul pannello e Lei spunta quali di essi diventano server in Provibr.

Cosa non fa

Provibr gestisce gli account, non il pannello. Non installa HestiaCP, non lo aggiorna, non modifica le impostazioni del server e non tocca DNS, caselle di posta o database: quelli restano in HestiaCP, dove Lei e i suoi clienti continuate a usarli. Non c’è console per un account di hosting, perché non c’è nulla a cui collegarla.

E una nota onesta sulle prestazioni: leggere un pannello con molti account costa una chiamata in più per account, perché HestiaCP non ha un comando che elenchi in una volta i domini di ogni account. Rilevato su 26 account, in serie sono circa 8,5 secondi; in parallelo torna sotto i due. Se lo scrive Lei, non lo faccia in serie: attorno ai 60 account un’interrogazione seriale comincia a scontrarsi con il proprio giro successivo.

Non deve scegliere un solo pannello e conviverci. 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à. HestiaCP per i clienti che vogliono un pannello aperto, qualcos’altro per chi chiede cPanel per nome, e un unico posto da cui vedere entrambi.