Webhosting verkopen met CyberPanel

CyberPanel is het paneel dat door hosters met OpenLiteSpeed het vaakst in één adem met DirectAdmin genoemd wordt. Gemeten op GitHub op 21 augustus 2026: 2.007 sterren, 723 forks en 362 openstaande issues, tegen een trager releasetempo dan de meeste soortgenoten.

Het heeft een REST-API, en alles wat je nodig hebt om er hosting op te verkopen (een site aanmaken, opschorten, van pakket wisselen, verwijderen) zit erin. Wat het niet heeft is iets dat beslist wanneer je die dingen doet, en wat het wél heeft is een reeks antwoorden die makkelijk verkeerd te lezen zijn.

Eerst dit: API-toegang staat uit

Op een verse CyberPanel staat de API uit, en dat geldt ook voor je hoofdbeheerder. Je zet hem aan onder Users → API Access, voor de gebruiker admin. Meer is er niet nodig; je meldt je aan met de login die je al hebt.

Laat je hem uit staan, dan komt elke aanroep terug als API Access Disabled., wat je ook stuurt. Het deel dat een middag kost is de volgorde: CyberPanel controleert die schakelaar vóórdat hij het wachtwoord controleert, dus met de schakelaar uit geven een juist en een fout wachtwoord allebei dezelfde 403. Alles wijst naar je inloggegevens terwijl het probleem een vinkje verderop zit.

Staat de schakelaar eenmaal aan, dan is het contract eronder helder en echt bruikbaar:

juist wachtwoord    → HTTP 200  {"verifyConn": 1}
fout wachtwoord     → HTTP 401  {"verifyConn": 0, "error_message": "Invalid password."}
onbekende gebruiker → HTTP 404  {"error_message": "Administrator not found."}

Drie situaties, drie verschillende handelingen voor de klant, alle drie te onderscheiden.

De beheerder moet admin heten

Geen instelling maar een voorwaarde, en hij komt van CyberPanel en niet van iets dat erbovenop gebouwd is. Een deel van die API wordt bewaakt door een letterlijke naamcontrole die elke andere gebruiker dan admin weigert, en dat deel is precies het deel dat de websites op het paneel opsomt en meldt hoe ver een nieuwe gekomen is.

Allebei zijn onvermijdelijk als je er hosting op wilt verkopen: je hebt de lijst nodig om te weten wat er bestaat, en de voortgangsmelding om de reden in de volgende sectie. Een hernoemde beheerder is niet bruikbaar, en wat je ook bouwt hoort dat tijdens de verbindingstest te zeggen, voordat je eerste bestelling het voor je ontdekt.

Een account is een domein, geen gebruikersnaam

Dit is het structurele verschil met DirectAdmin, cPanel en Virtualmin, en het verandert hoe je het product modelleert.

De websiterij van CyberPanel heeft een uniek domain-veld, en elk commando mikt daarop: verwijderen neemt domainName, opschorten en pakketwissel nemen websiteName, en alle drie zoeken de site op domein op. Er is geen gebruikersnaam om aan te wijzen. De unix-gebruiker wordt gegenereerd, niet gekozen: vijf letters uit het domein plus vier willekeurige cijfers. Gemeten voor provibr-test-1.example.com: provi7346, met de home-directory vernoemd naar het domein, niet naar de gebruiker. Je kunt die naam niet kiezen, niet voorspellen, en hij verschijnt in precies één API-antwoord en in geen enkele lijst.

Eén gevolg is goed om te weten vóór je honderdste account: bij het aanmaken van een website wordt er ook een panellogin onder gemaakt, mét API-toegang, en die login overleeft het verwijderen van de website. Gemeten na een delete: unix-gebruiker weg, home-directory weg, vhost weg, databaserij weg; de eigenaarlogin stond er nog. Het opruimpad van CyberPanel wordt bewaakt door een controle die op dat moment niet kan slagen, en de fout die daaruit volgt wordt ingeslikt. Verwijdert niets erboven hem, dan laat elke opgezegde klant een login achter.

Een site aanmaken meldt succes voordat het iets weet

Dit is het belangrijkste om te begrijpen aan de API van CyberPanel.

createWebsite antwoordt in ongeveer drie seconden met:

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

Dat komt binnen voordat het meeste werk gedaan is: het endpoint bouwt een commandoregel, start hem zonder te wachten, en keert terug. De echte voortgang staat in een statusbestand, uit te lezen met een aparte aanroep. Gemeten, één echte aanmaak:

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

Ruwweg vijftig seconden, waarvan ongeveer achtentwintig een SSL-poging die het paneel hoe dan ook doet: de API overschrijft die vlag onvoorwaardelijk, dus er is geen manier om via de API een site zónder SSL te maken. Op een domein dat nog niet publiek resolvet zijn dat achtentwintig seconden wachten op een certificaat dat niet komt.

En het eerste antwoord is geen oordeel. Gemeten met opzettelijk foute invoer:

Alleen de vorm van het domein en het e-mailadres wordt direct gecontroleerd. Of het domein vrij is, en of het pakket bestaat, is alleen in het statusbestand te zien. Een koppeling die het eerste antwoord vertrouwt meldt een geslaagde bestelling voor een domein dat al bezet was.

Twee details maken het pollen lastiger dan het lijkt. Het lezen van een voltooide status verwijdert het bestand, dus een tweede poll geeft "bestand bestaat niet" met een "nog niet klaar"-vlag: een client die één keer te vaak pollt ziet voor altijd "nog bezig" voor een aanmaak die geslaagd is. En de statusaanroep zit uitsluitend op het admin-only-oppervlak, en dáárom is de admin-naamvoorwaarde hierboven niet optioneel.

Opschorten is een webservertruc, geen accountblokkade

Opschorten en hervatten zijn het nette deel van deze API: allebei werken ze meteen, en de eigen lijst van het paneel toont de nieuwe stand direct.

Maar weet wat het doet. CyberPanel schrijft de vhost-configuratie van de site om naar een opschortingspagina en herstart de webserver. De unix-gebruiker wordt niet geblokkeerd; FTP, mail en databases blijven werken. De website wordt onbereikbaar en verder niets. Dat verschilt van DirectAdmin, en het telt zodra je opschorten gebruikt om betaling af te dwingen.

Nog één ding, een constante in je code waard en geen variabele: de implementatie is if state == "Suspend": … else: <hervatten>, zonder enige validatie op de waarde. Gemeten op een echte site:

1. state:"Suspend"  → lijst: Suspended
2. state:"suspend"  → {"websiteStatus": 1, "error_message": "None"}
3. lijst:           → Active     ← een kleine letter heeft de site hervat

Een tikfout zet een opgeschorte klant stilzwijgend weer aan en meldt succes.

Van pakket wisselen wijzigt de administratie, en verder niets

changePackageAPI keert in ongeveer 270 milliseconden terug en het paneel toont de nieuwe pakketnaam. Gemeten van binnenuit de server, met een pakket met opzettelijk andere limieten: het schijfquotum bleef ongewijzigd (soft 0, hard 0) en de vhost-configuratie droeg nog steeds de geheugen- en proceslimieten van het oude pakket.

Er werd niets toegepast. De hele operatie is een veldwijziging in de database. Lees de pakketnaam in CyberPanel als administratie, niet als een limiet die is meeverhuisd, en wat erboven staat hoort dat te zeggen in plaats van te suggereren dat een upgrade van kracht is geworden.

Er is geen verbruiksinformatie

CyberPanel is het enige controlepaneel in Provibr zonder verbruiksgrafieken, en dat is geen weglating van de koppeling: het paneel meet het niet.

Bandbreedte wordt berekend en daarna weggegooid: het bereikt de lijst nooit. Schijfverbruik komt uit een cache op de websiterij, en op een net aangemaakte site is dat veld leeg, dus de gemelde waarde valt terug op nul. Een nul uit een lege cache is niet te onderscheiden van een site die werkelijk niets gebruikt. Een grafiek die eeuwig op nul staat ziet eruit als een meting; daarom is er geen.

Wat Provibr ermee doet

Provibr verbindt via een agent in je eigen netwerk die uitgaand verbindt, dus het paneel hoeft niets open te zetten. Hij vraagt vier dingen: het adres van het paneel inclusief poort 8090, de gebruikersnaam admin, het wachtwoord van die beheerder, en, zolang het paneel nog het meegeleverde certificaat gebruikt, de SHA-256-fingerprint om op te pinnen.

Die laatste is in de praktijk niet optioneel. Elke verse CyberPanel presenteert hetzelfde self-signed certificaat, uitgegeven aan www.example.com en ondertekend door CyberPanel zelf. Een browser noemt het daarom fout in plaats van self-signed, en de keten valideert nooit. De fingerprint pinnen betekent precies dat ene certificaat vertrouwen in plaats van de controle uitzetten. Zet je een eigen certificaat op de hostnaam van het paneel, dan valideert de keten vanzelf en mag het veld leeg blijven.

Wees je bewust van wat dat wachtwoord is. CyberPanel heeft geen API-token dat deze commando's dekt: binnen zijn eigen API staat de tokenroute per endpoint aan of uit, en juist de vier die een site aanmaken, opschorten, van pakket wisselen en verwijderen eisen het wachtwoord. Dit is dus het volledige wachtwoord van je hoofdbeheerder.

Daarmee op zijn plek: pakketten worden verkoopbaar als webhostingplannen onder een eigen naam en prijs, bestellingen maken sites aan en wachten op de echte uitkomst in plaats van op het eerste antwoord, opschorten en hervatten werken op verzoek en bij overschrijding van je capaciteit, en sites die er al staan zijn te importeren.

Wat het niet doet

Provibr beheert websites, niet het paneel: het installeert CyberPanel niet, werkt het niet bij en wijzigt geen serverinstellingen. Er is geen console. DNS, mailboxen en databases blijven onaangeraakt: CyberPanel doet dat allemaal zelf en niets erboven stuurt het aan. En er zijn geen verbruiksgrafieken, want er is niets eerlijks te tekenen.

Je hoeft niet op één paneel te wedden. Provibr draait vandaag zijn controlepanelen, hypervisors en gamepanelen naast elkaar, in één inventaris, met één rechtenmodel en één activiteitenlog.