Webhosting verkopen met HestiaCP

HestiaCP is het gezondste open controlepaneel dat er is. Gemeten op GitHub op 21 augustus 2026: 4.481 sterren, 345 bijdragers en drie releases binnen één week. Het geeft je accounts, pakketten, DNS, mail, databases en een nette interface, en het kost niets.

Wat het je niet geeft is een manier om dat allemaal te verkópen. Er is geen bestelformulier, geen factuur, geen aanmaning, geen "deze klant betaalt niet meer, zet hem uit". Zoek op hestiacp billing en dan zijn de bovenste resultaten, gemeten op dezelfde dag, forumdraadjes: mensen die vragen hoe je HestiaCP-accounts verkoopt, en andere mensen die antwoorden met een half script.

Deze pagina gaat over de laag erboven: wat de API van HestiaCP werkelijk teruggeeft, waar hij je zal bijten, en wat er goed moet staan voordat je een Bestellen-knop voor een vreemde neerzet.

Wat HestiaCP je al geeft

Twee dingen, en het zijn de juiste twee.

Pakketten. Een HestiaCP-pakket beschrijft wat een account mag gebruiken: schijfruimte, bandbreedte, en hoeveel domeinen, databases en mailboxen. Dat is je productcatalogus, één keer gedefinieerd en overal verder alleen bij naam genoemd.

Een accountlevenscyclus die op een abonnement past. Aanmaken, opschorten, hervatten, naar een ander pakket verplaatsen, verwijderen: precies de toestanden die een betaald hostingaccount doorloopt, en er is voor elk een commando:

De rest van deze pagina gaat over het gat tussen die tabel en iets waar je om drie uur 's nachts op kunt vertrouwen.

De API heeft twee deuren, en één ervan liegt

POST https://host:8083/api/ accepteert twee soorten inloggegevens, en welke je stuurt bepaalt welke code je verzoek afhandelt. Het oude pad neemt een gebruikersnaam en wachtwoord. Het nieuwere pad, beschikbaar sinds HestiaCP 1.6, neemt een access key: een id van 20 tekens en een geheim van 40 tekens.

Ze gedragen zich niet hetzelfde. Een commando sturen dat niet bestaat:

Het legacy-pad meldt succes voor een commando dat nooit gedraaid heeft. De oorzaak staat in de bron van HestiaCP zelf: het echoot OK zodra de authenticatie nul teruggaf en het commando niets op stdout zette. Het kijkt nooit naar de exitcode van het commando zelf, en zet nooit een HTTP-status of de exitcode-kop voor het resultaat. Elk commando dat stil faalt komt terug als OK.

Dus: gebruik access keys. Niet alleen omdat het legacy-pad kan liegen, maar omdat een sleutel los in te trekken is, in het paneel bij naam staat, en het beheerderswachtwoord van je paneel niet in de vault van iemand anders zet. Bouw ook geen terugval van het ene naar het andere: twee deuren betekent twee foutoppervlakken, en hier is de terugvaldeur de onbetrouwbare.

De HTTP-status is niet het antwoord, de exitcode wel

HestiaCP vouwt zo'n twintig interne exitcodes op vier HTTP-statussen. Twee gevolgen, allebei gemeten:

Een geslaagde mutatie geeft 204, niet 200. Elke v-add-user, v-suspend-user, v-delete-user, v-add-web-domain en v-change-user-package komt terug als HTTP 204 met een lege body. Een client die alleen 200 accepteert weigert élke aanroep die werkte.

HTTP 401 betekent vier verschillende dingen: verkeerd geheim (exit 9), sleutel buiten zijn permissies (10), adres niet toegestaan (10), én "deze gebruiker is al opgeschort" (5). Een client die 401 als "inloggegevens fout" leest, meldt dat je sleutel verlopen is terwijl je alleen een account twee keer opschortte.

Lees Hestia-Exit-Code. De status is een afgeleide.

Degene die je écht plat legt

Vijf geweigerde aanroepen en HestiaCP blokkeert je adres. Dit is geen rate limit waar je op terug kunt schakelen: het is fail2ban, standaard geconfigureerd met maxretry = 5 tegen /var/log/hestia/auth.log, en het eindigt in een iptables-DROP. Daarna weigert het paneel je aanroepen niet meer, het antwoordt helemaal niet meer: je monitoring toont timeouts en het lijkt een netwerkprobleem.

Wat mensen erin laat lopen is wat er als mislukte aanmelding telt. Niet alleen een verkeerd geheim: de sleutelcontrole van HestiaCP schrijft dezelfde failed to login-regel wanneer een sleutel gebruikt wordt voor een commando buiten zijn permissieset. Gemeten, in het auth-log van het paneel zelf:

12:57:52 <key> 84.85.173.142 v-list-users successfully launched
12:57:52 <key> 84.85.173.142 failed to login      ← een commando buiten de scope van de sleutel

Daar volgen drie regels uit, en ze zijn geen van drieën optioneel:

1. 01Nooit automatisch opnieuw proberen na een authenticatie- of permissiefout. Een retry-lus op een verkeerde sleutel sluit je binnen een minuut buiten, en dan is de melding die je klant ziet "paneel onbereikbaar" in plaats van "sleutel klopt niet", het slechtst denkbare signaal, want het wijst naar het verkeerde probleem.
2. 02De sleutel moet ongescoped zijn, en dus van de admin. Lege permissies betekent alle commando's, en dat accepteert HestiaCP alleen voor de root-gebruiker. De meegeleverde billing-permissieset komt in de buurt maar mist v-list-user-packages en v-list-web-domains, de twee commando's die je pakketcatalogus en de domeinen van een account lezen. Met die set blijven allebei leeg, en een gescopete sleutel die ze één keer per pollronde aanraakt blokkeert je volgens schema.
3. 03Je fouttekst moet dit noemen, want opheffen vergt een shell op het paneel: v-delete-firewall-ban <adres> HESTIA.

Leeg betekent niemand

Nog een valkuil bij de eerste keer. HestiaCP houdt een lijst bij van adressen die de API mogen gebruiken, in API_ALLOWED_IP. Op een verse installatie is die lijst leeg, en leeg betekent hier niemand, niet iedereen. Elke aanroep komt terug met 401 en IP is not allowed to connect with API terwijl je sleutel gewoon klopt. Dit is de meest waarschijnlijke eerste storing van de hele koppeling, en hij verdient een eigen foutmelding in plaats van een algemeen "authenticatie mislukt".

Een account aanmaken kost twee aanroepen, en dat gat is echt

DirectAdmin, cPanel en Virtualmin maken een account mét zijn domein in één aanroep. HestiaCP niet:

v-add-user        USER PASSWORD EMAIL [PACKAGE] [NAME]   → maakt de gebruiker
v-add-web-domain  USER DOMAIN [IP] [RESTART] [ALIASES]   → hangt het domein eronder

Mislukt de tweede aanroep (het domein is al van iemand anders, of de vorm wordt geweigerd), dan hou je een echte unix-gebruiker over, met een home-directory, zonder website, en met een rij in elke telling die je draait. Gemeten met een opzettelijk ongeldig domein: de gebruiker bestond daarna met U_WEB_DOMAINS = 0. Wat je ook bouwt, het moet compenseren: mislukt stap twee, verwijder dan de gebruiker en meld de oorspronkelijke fout.

Wat Provibr hiermee doet

Provibr verbindt met HestiaCP via een agent die in je eigen netwerk draait en uitgaand verbindt, dus er hoeft niets op het paneel opengezet te worden. Je geeft hem vier dingen: het adres van het paneel inclusief poort 8083, het access-key-id, het geheim, en, zolang het paneel nog zijn self-signed certificaat gebruikt, de SHA-256-fingerprint om op te pinnen. De agent bewaart die in zijn eigen vault op jouw host; het platform kan ze niet teruglezen.

Van daaraf:

• Pakketten worden verkoopbaar. Een webhostingplan wijst naar één pakket op één integratie, onder een eigen naam, tegen een eigen prijs.
• Vijf handelingen, aangewezen met de gebruikersnaam: aanmaken met een domein en een pakket, opschorten, hervatten, pakket wisselen, verwijderen. Het aanmaken in twee stappen wordt gecompenseerd zoals hierboven beschreven.
• Verbruik komt gratis mee met de poll. Elke uitlezing van v-list-users draagt DISK_QUOTA, U_DISK, BANDWIDTH en U_BANDWIDTH voor elk account, allemaal in megabytes, dus grenzen en verbruik komen op de serverpagina en in de grafieken zonder een tweede aanroep die achter de eerste aan kan lopen.
• Accounts die er al staan zijn te importeren. De agent somt op wat er op het paneel staat en jij vinkt aan welke daarvan servers in Provibr worden.

Wat het niet doet

Provibr beheert accounts, niet het paneel. Het installeert HestiaCP niet, werkt het niet bij, wijzigt geen serverinstellingen en raakt DNS, mailboxen en databases niet aan; die blijven in HestiaCP, waar jij en je klanten ze blijven gebruiken. Er is geen console voor een hostingaccount, want er is niets om er een aan te hangen.

En één eerlijke prestatienotitie: een paneel met veel accounts uitlezen kost één extra aanroep per account, want HestiaCP heeft geen commando dat de domeinen van alle accounts tegelijk opsomt. Gemeten op 26 accounts is dat serieel ruim 8,5 seconde; parallel komt het onder de twee. Schrijf je dit zelf, doe het dan niet serieel: rond de 60 accounts begint een seriële poll met zijn eigen volgende ronde te botsen.

Je hoeft niet één paneel te kiezen en het daarmee te doen. Provibr draait vandaag zijn controlepanelen, hypervisors en gamepanelen naast elkaar, onder één inventaris, één rechtenmodel en één activiteitenlog. HestiaCP voor de klanten die een open paneel willen, iets anders voor wie om cPanel vraagt, en één plek waar je allebei ziet.