De CyberPanel-WHMCS-module, en het alternatief

Draai je WHMCS en wil je OpenLiteSpeed-hosting verkopen, dan ga je op zoek naar een CyberPanel-provisioningmodule. Gemeten op 21 augustus 2026 leveren de resultaten voor die zoekterm een GitHub-repository op die door één persoon onderhouden wordt, plus een communityforumdraad.

Dat is geen kritiek op andermans werk. Het is de beschrijving van een gat: een stuk software dat tussen je facturen en de websites van je klanten in staat, en dat de meeste hosters aantreffen als een nevenproject in plaats van als een product.

Deze pagina gaat over wat zo'n module kan, wat hij structureel niet kan, en hoe een andere vorm van oplossing eruitziet. Het eerste deel telt het zwaarst, want het plafond is niet de module: het is de API van CyberPanel.

Het plafond: wat de API van CyberPanel toelaat

Gemeten tegen CyberPanel 3.0, niet uit documentatie overgenomen. Elke module (die op GitHub, een die je zelf schrijft, of degene die verderop beschreven staat) wordt door al deze grenzen begrensd.

Een site aanmaken antwoordt vóór het de uitkomst kent

createWebsite keert in ongeveer drie seconden terug met createWebSiteStatus: 1. Dat is geen oordeel; het betekent dat het werk begonnen is. Het endpoint start een achtergrondcommando en keert meteen terug. De echte voortgang staat in een statusbestand dat apart gepollt moet worden.

Gemeten met opzettelijk foute invoer:

Alleen de vorm van het domein en het e-mailadres wordt vooraf gevalideerd. Een module die het eerste antwoord vertrouwt zet een WHMCS-bestelling op actief voor een site die nooit is aangemaakt, en de klant krijgt welkomstgegevens voor iets wat niet bestaat.

Dat statusbestand pollen heeft nog twee haken. Het lezen van een voltooide status verwijdert hem, dus één poll te veel maakt van een afgeronde aanmaak een permanent "nog bezig". En de statusaanroep zit op het deel van de API van CyberPanel dat elke beheerder weigert die niet letterlijk admin heet.

De hele aanmaak duurt zo'n vijftig seconden, waarvan ongeveer achtentwintig een SSL-poging die CyberPanel onvoorwaardelijk doet: de API overschrijft die vlag wat je ook stuurt. Elke module heeft een timeout nodig die daarop past.

Van pakket wisselen wijzigt een databaseveld

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

Er werd niets toegepast. Een WHMCS-upgradebestelling kan dus afgerond worden, gefactureerd worden en de naam in het paneel wijzigen, terwijl de werkelijke limieten van de klant precies zijn wat ze waren. Geen module kan dit repareren: de hele implementatie van dat endpoint is een veldwijziging.

Opschorten blokkeert het account niet

CyberPanel schort een site op door de vhost om te schrijven naar een opschortingspagina en de webserver te herstarten. De unix-gebruiker wordt niet geblokkeerd; FTP, mail en databases blijven werken. Schort je op wegens niet betalen, dan heeft je klant nog steeds zijn mail en zijn database. Dat kan precies zijn wat je wilt, maar het hoort een besluit te zijn en geen verrassing.

Er zit ook een scherpere rand aan: de implementatie is if state == "Suspend": … else: <hervatten>, zonder validatie. Gemeten: "suspend" met een kleine letter sturen heeft een opgeschorte site hervat en succes gemeld. Elke module hoort die twee waarden als constante te houden en ze nooit uit een variabele samen te stellen.

Er is geen verbruiksinformatie

Bandbreedte wordt door CyberPanel berekend en daarna weggegooid voordat het enige lijst bereikt. Schijfverbruik komt uit een cache op de websiterij die op een nieuwe site leeg is, dus de waarde valt terug op nul, en een nul uit een lege cache is niet te onderscheiden van een site die niets gebruikt.

WHMCS heeft een hook voor verbruiksverzameling die schijf- en bandbreedtecijfers verwacht. Op CyberPanel is er niets eerlijks om daarin te zetten: een module die het toch invult rapporteert een standaardwaarde, geen meting.

API-toegang staat uit, en de controlevolgorde verbergt waarom

Op een verse CyberPanel staat de API uit, ook voor de hoofdbeheerder, en de schakelaar wordt vóór het wachtwoord gecontroleerd, dus met hem uit geven een juist en een fout wachtwoord dezelfde API Access Disabled. De eerste storing van elke module voor dit paneel ziet eruit als een inloggegevensprobleem en is dat niet.

Wat dat voor een module betekent

Niets hiervan is binnen een WHMCS-module te repareren, want niets ervan is een moduleprobleem. Wat wél per module verschilt is hoe eerlijk ermee omgegaan wordt:

• Pollt hij de aanmaakstatus, of vertrouwt hij het eerste antwoord?
• Leest hij de status één keer en legt hij de uitkomst vast, of pollt hij door tot hij het resultaat per ongeluk wist?
• Vertelt hij je dat een pakketwissel niets heeft toegepast?
• Laat hij de verbruikshook leeg, of vult hij hem met nullen die op data lijken?
• Zegt hij "API-toegang staat uit" in plaats van "ongeldige inloggegevens"?

Dat zijn de vragen die je aan elke module hoort te stellen die je overweegt. Ze zijn te beantwoorden door de code te lezen, en ze tellen zwaarder dan de functielijst. Er is er nog één, over jou en niet over de code: wie onderhoudt hem over achttien maanden? Een provisioningmodule staat op het kritieke pad van elke bestelling die je aanneemt.

Het alternatief: een provisioninglaag, geen paneelmodule

Provibr staat tussen je facturatiesysteem en je infrastructuur. Het is geen WHMCS-module voor CyberPanel; het is een provisioningplatform dat mét CyberPanel praat, en waar WHMCS via één module mee praat ongeacht wat eronder zit.

Het praktische verschil:

Twee regels verdienen toelichting, want dat zijn de eerlijke.

Kosten. De module is gratis en Provibr niet. Provibr rekent voor de capaciteit die je reserveert (hoeveel hostingaccounts je tegelijk mag draaien) tegen een staffelprijs die zakt naarmate het aantal stijgt. Wat je je eigen klanten rekent blijft volledig van jou. Heb je twaalf CyberPanel-sites en geen groeiplannen, dan is een gratis module het juiste antwoord.

Dezelfde grenzen, andere eerlijkheid. Provibr repareert de pakketwissel van CyberPanel niet, verzint geen verbruikscijfers, en blokkeert een opgeschort account niet. Dat kan het ook niet: dat zijn eigenschappen van het paneel. Wat het wél doet is weigeren om anders te doen voorkomen.

Hoe het in WHMCS past

Eén module, geïnstalleerd als gewone zip in modules/servers/. In WHMCS voeg je een server toe die naar Provibr wijst met een API-sleutel, en laat je vervolgens één WHMCS-product naar één Provibr-webhostingplan wijzen. Een betaalde bestelling maakt het account, een opschorting schort het op, een beëindiging verwijdert het. Je klant houdt één account, één factuur en één login.

De API-sleutel draagt scopes, en wat hij werkelijk mag is de doorsnede van die scopes en de rechten van het lid waar hij bij hoort. Een sleutel kan toegang dus alleen versmallen, nooit verbreden. Neem je een collega een recht af, dan wordt elke sleutel van die persoon bij het volgende verzoek smaller, zonder dat iemand iets hoeft in te trekken.

Draai je geen WHMCS, dan zijn dezelfde handelingen beschikbaar via de REST-API: één sleutel, één basis-URL. Alles wat een machine raakt antwoordt "aangenomen" met een commando om te volgen, want je infrastructuur is alleen bereikbaar via de agent in je eigen netwerk. Leesacties antwoorden meteen.

Wanneer de module de betere keuze is

Eerlijk daarover: is CyberPanel het enige paneel dat je draait, heb je WHMCS al, is je volume klein en lees je zonder morren PHP wanneer er iets stukgaat, dan is een module minder machinerie en geen maandelijkse kosten. De grenzen bovenaan deze pagina gelden voor beide opties even hard.

Het argument voor een laag erboven begint zodra je meer dan één paneel draait, zodra je de inloggegevens van je WHMCS-host af wilt hebben, zodra iets anders dan WHMCS bestellingen moet plaatsen, of zodra je wilt dat het provisioningpad iemands product is in plaats van iemands weekend.

Provibr draait vandaag zijn controlepanelen, hypervisors en gamepanelen naast elkaar, in één inventaris, onder één rechtenmodel, met één activiteitenlog. Je hoeft niet te kiezen tussen CyberPanel en al het andere.