Blog ·
HestiaCP vs CyberPanel: op welk gratis controlepaneel verkoop je hosting?
HestiaCP of CyberPanel voor je hostingbedrijf? Bijdragers, releasetempo, opschorten en verbruiksmeting, gemeten op 21 augustus 2026.
Door Provibr
Allebei opensource. Allebei zonder licentiekosten. Allebei gekozen door hosters die naar het cPanel-tarief keken en besloten dat geld te houden. En allebei live ondersteund door Provibr, wat betekent dat wij precies hetzelfde verdienen welke je ook draait. Deze vergelijking heeft je dus niets te verkopen.
De twee lijken minder op elkaar dan het gedeelde etiket "gratis controlepaneel" doet vermoeden. HestiaCP is een accountgericht paneel op een gewone nginx/Apache-stack. CyberPanel is een websitegericht paneel rond OpenLiteSpeed. Dat verschil reikt tot in de manier waarop je een niet-betalende klant opschort, en daar zoekt bijna niemand het.
De cijfers over de projectgezondheid
Via de GitHub-API gemeten op 21 augustus 2026. Over een jaar kloppen ze niet meer, en daarom staat de datum hier en niet in een voetnoot.
| HestiaCP | CyberPanel | |
|---|---|---|
| Publiek sinds | 2018 | 2017 |
| Sterren | 4.481 | 2.007 |
| Forks | 924 | 723 |
| Bijdragers | 345 | 83 |
| Openstaande issues | niet gemeten | 362 |
| Releasetempo op het meetmoment | drie releases in één week | duidelijk trager |
HestiaCP is het jongere project met ruwweg vier keer zoveel bijdragers en een zichtbaar sneller releaseritme. CyberPanel heeft een vergelijkbaar aantal forks (er wordt wel degelijk op gebouwd), maar een veel kleinere groep mensen die wijzigingen uitbrengt, en een grote stapel openstaande issues.
Dat zijn tellingen, geen oordelen. Een grote stapel kan een betrokken gebruikersgroep betekenen die netjes meldt; een hoog releasetempo kan ook onrust betekenen. Wat ze wél zeggen is hoe snel een bug die jou raakt waarschijnlijk bekeken wordt, en dat is een eerlijke afweging voor een hoster.
Waar ze in het dagelijks gebruik verschillen
Alles in deze tabel hebben we gemeten tijdens het bouwen en uitrollen van de twee Provibr-integraties, tegen draaiende panelen.
| Onderwerp | HestiaCP | CyberPanel |
|---|---|---|
| Webstack | nginx / Apache | OpenLiteSpeed |
| Een resource wordt aangeduid met | de gebruikersnaam | het domein |
| API-poort | 8083, alleen TLS | 8090, alleen TLS |
| API standaard aan | Ja, sinds versie 1.10 | Nee: per gebruiker uit, moet aangezet |
| Inloggegeven | een intrekbare access key | het wachtwoord van de hoofdbeheerder |
| Naam van de beheerder | vrij | moet letterlijk admin zijn voor een deel van de API |
| Duur van een account aanmaken | snel, twee aanroepen | ±50 seconden, waarvan ±28 een SSL-poging |
| Opschorten | blokkeert het account | blokkeert alleen de website |
| Schijf- en verkeersverbruik | bij elke poll meegeleverd | door het paneel niet gemeten |
Een paar daarvan bepalen echte dingen.
Opschorten is degene die je gaat verrassen. Op HestiaCP schort opschorten het account op. Op CyberPanel is het een webservertruc: de site wordt onbereikbaar, maar FTP, mail en databases blijven werken en de unix-gebruiker wordt niet geblokkeerd. Gebruik je opschorten als handhavingsmiddel bij wanbetaling, dan is dat op de twee panelen een wezenlijk ander gereedschap.
CyberPanel meet geen verbruik. Dat is niets wat een integratie erbij kan bouwen. Bandbreedte wordt berekend en daarna weggegooid, en schijfgebruik komt uit een cache die op een nieuwe website leeg bleef. Een gerapporteerde nul is dus niet te onderscheiden van helemaal geen meting. Provibr toont voor CyberPanel daarom bewust geen verbruiksgrafiek: een lijn die eeuwig op nul staat ziet eruit als een meting. HestiaCP draagt de limiet en het verbruik van elk account bij elke poll mee, in megabytes, zonder extra aanroep. Verkoop je op schijf of op verkeer, dan is dat verschil je facturatie.
Van pakket wisselen op CyberPanel verandert de boekhouding en verder weinig. Van binnenuit een server gemeten, na verplaatsing naar een pakket met andere limieten: het schijfquotum bleef zoals het was en de webserverconfiguratie hield de oude waarden. Het paneel toont de nieuwe naam. Lees die naam als administratie, niet als een limiet die meeverhuisd is.
De aanmaakaanroep van CyberPanel vertelt niet wat er gebeurd is. Het eerste antwoord komt na ongeveer drie seconden en zegt niets, zelfs niet of het domein nog vrij was. De echte uitkomst landt zo'n vijftig seconden later. Alles wat dit automatiseert moet op dat tweede antwoord wachten in plaats van het eerste te geloven.
Twee voorwaarden van CyberPanel struikelen mensen vóór hun eerste bestelling. API-toegang staat standaard uit, per gebruiker, en het paneel controleert die schakelaar vóór het wachtwoord. Een goed wachtwoord geeft dus precies hetzelfde API Access Disabled als een verkeerd, en alles wijst naar je inloggegevens terwijl het probleem één vinkje verderop zit. En een deel van de API weigert elke beheerdersnaam behalve admin; een hernoemde beheerder is helemaal niet bruikbaar. Geen van beide is een instelling waar je omheen praat.
HestiaCP heeft zijn eigen scherpe randen, en één ervan bijt hard. Het paneel bant een adres na vijf geweigerde aanmeldpogingen, en een commando buiten de rechten van een sleutel telt als zo'n poging; daarna antwoordt het paneel helemaal niet meer, met een time-out in plaats van een foutmelding. Niets mag HestiaCP-aanroepen ooit automatisch herhalen. Zijn API houdt daarnaast een lijst met toegestane adressen bij, leeg op een verse installatie, en leeg betekent niemand in plaats van iedereen: tot het adres van je agent erop staat wordt een volstrekt goede sleutel bij elke aanroep geweigerd. Let ook op: bij HestiaCP is de HTTP-statuscode niet het contract, maar de kop Hestia-Exit-Code. Een geslaagde wijziging komt terug als 204, en "al opgeschort" komt binnen als een 401.
Nog één operationeel punt, en dat valt in het nadeel van CyberPanel: bij HestiaCP maak je een access key die je los kunt intrekken, zonder je paneelwachtwoord aan te raken. CyberPanel heeft geen API-token dat de vier commando's dekt die een website aanmaken, opschorten, van pakket wisselen en verwijderen; die vragen allemaal om het wachtwoord. Wat je je automatisering meegeeft is dus het volledige beheerderswachtwoord.
Welke moet je kiezen?
Kies HestiaCP als je op schijf of verkeer factureert, als opschorten je manier van handhaven is, als je een inloggegeven wilt dat je los kunt intrekken, of als het tempo waarin bugs opgelost worden voor je telt. Voor een hostingbedrijf is dit de veiligere standaardkeuze.
Kies CyberPanel als je specifiek OpenLiteSpeed wilt. Dat is een echte reden, en het is waar CyberPanel om gekozen wordt. Ga er dan in met de wetenschap dat je je verbruiksmeting zelf doet, dat opschorten minder doet dan het klinkt, en dat een pakketwissel een etiket is.
Kies voorlopig geen van beide als je nog niet bepaald hebt hoe je wanbetaling afdwingt. Dat antwoord verschilt tussen deze twee panelen, en het is makkelijker het paneel om je proces heen te kiezen dan je proces om het paneel.
Je kunt ze ook allebei draaien
De meeste hosters die deze vraag stellen hebben al één paneel en denken over het andere. Die overgang is het dure deel, niet de software: twee logins, twee manieren om te tellen wat je verkocht hebt, twee plekken om te kijken als een klant belt.
Provibr koppelt ze allebei, in hetzelfde account. Een HestiaCP-account en een CyberPanel-website staan in dezelfde serverlijst, tellen mee voor dezelfde capaciteit en komen op dezelfde maandfactuur. De agent belt uitgaand vanuit je eigen netwerk, dus geen van beide panelen hoeft een poort open te zetten en er wordt op geen van beide iets geïnstalleerd. Accounts en websites die je niet via Provibr hebt aangemaakt blijven onaangeroerd tot je ze importeert, en zo zet je een bestaand paneel over zonder er iets op te herbouwen.
Verder lezen
- HestiaCP instellen: de access key, de adreslijst, pakketten en accounts importeren.
- CyberPanel instellen: API-toegang aanzetten, de
admin-eis, en wat in het paneel blijft. - De CyberPanel-WHMCS-module: wat een module wel en niet kan, want de CyberPanel-API bepaalt het plafond.
Sterren, forks, bijdragers, issues en releasetempo zijn op 21 augustus 2026 via de GitHub-API gemeten. Alles wat hier over de twee API's staat, is tegen draaiende panelen gemeten tijdens het bouwen van de Provibr-integraties.