Webhosting verkopen met CloudPanel

CloudPanel is het paneel dat mensen installeren als ze een site snel willen laten draaien en verder niets in de weg willen hebben. Het is gratis, het staat binnen enkele minuten op een verse cloudinstance, en wat je krijgt is een kale NGINX- en PHP-FPM-stack met Let's Encrypt, een database en een Cloudflare-koppeling. Geen mailserver. Geen lagen waar je niet om vroeg.

Precies die focus is waarom mensen het fijn vinden, en het is ook waarom hosting verkopen erop een andere oefening is dan op DirectAdmin of cPanel. CloudPanel beheert sites op één server. Het beheert geen klanten die jou betalen. Dat zijn niet dezelfde problemen, en de afstand ertussen is waar deze pagina over gaat.

Waar CloudPanel echt omheen gebouwd is

Eén server, en de sites erop.

Je maakt een site aan (PHP, statisch, Node.js, Python of een reverse proxy) en CloudPanel schrijft een NGINX-vhost, een PHP-FPM-pool, een Linux-sitegebruiker en een homedirectory. Je zet er een database naast. Je wijst er een certificaat op aan. Dat is de lus, en het is een goede: een ontwikkelaar of een bureau met twintig sites op één bak krijgt een nette interface over precies de dingen die ze aanraken.

Wat het niet heeft is de laag daarboven: een klant die een verzameling sites bezit, met een plan, een quotum en een schakelaar. CloudPanel heeft panelgebruikers met rollen (beheerder, sitebeheerder, gebruiker) en die gebruikers kunnen tot bepaalde sites beperkt worden. Maar dat is toegangsbeheer voor mensen die inloggen, geen commercieel account dat je kunt factureren en uitzetten.

Dat onderscheid klinkt theoretisch tot de eerste klant stopt met betalen.

Het hele bedienoppervlak is één commandoregeltool

CloudPanel heeft geen REST-API. Alles wat automatisering kan doen, doet het via clpctl, de eigen commandoregeltool van het paneel, die als root op de host draait. Hij is goed scriptbaar (niet-interactief, vlaggen in plaats van vragen) en dekt de onderdelen die je zou verwachten:

Twee dingen in die tabel zijn de moeite waard om op te merken voordat je er iets omheen plant.

Het eerste is dat de identiteit van een site zijn domeinnaam is. Geen numeriek id, geen accountnaam: het domein. Alles wat je bouwt hangt daaraan, en het moet een klant overleven die een domein naar een ander plan wil verhuizen.

Het tweede weegt zwaarder, en daar gaat de volgende paragraaf over: er staat in die tabel geen werkwoord om een site uit te zetten.

De drie gaten die tellen zodra je verkoopt

Er is geen opschorting

clpctl heeft site:add:* en het heeft site:delete. Daartussen heeft het niets. Er is geen site:suspend, geen site:disable, geen onderhoudsschakelaar, en de panelinterface heeft er ook geen equivalent voor.

Voor een hostingbedrijf is dat geen cosmetisch gat, want "de factuur is dertig dagen te laat" is verreweg het vaakst voorkomende waar je op moet handelen, en de site verwijderen is niet het antwoord. Verwijderen is onomkeerbaar en neemt de data van de klant mee; een klant die op dag eenendertig betaalt verwacht zijn website terug te vinden waar hij hem achterliet.

Alles wat CloudPanel-hosting verkoopt moet opschorting dus zelf uitvinden. De gebruikelijke kandidaten zijn de PHP-FPM-pool van de site stoppen, of de vhost bewerken zodat de site niet meer antwoordt. Allebei werken ze, en de tweede is de betere van de twee: een gestopte pool levert een 502 op, en dat ziet er voor je klant uit alsof jouw server stuk is in plaats van alsof zijn factuur te laat is.

Een vhost goed bewerken is een kortere lijst dan het klinkt. Zet wat je invoegt tussen een begin- en een eindcommentaar, zodat hervatten betekent dat je precies die regels weghaalt en niets anders. Doe het in elk publiek server-blok, want een vhost heeft er meestal één voor poort 80 en één voor 443. En een site die over HTTP opgeschort is en over HTTPS kerngezond, is erger dan een site die niet opgeschort is: het ziet eruit alsof het werkte. Draai nginx -t vóór je herlaadt, want dit is een gedeelde webserver en een kapotte configuratie neemt elke site erop met je mee. Doe die drie en opschorting wordt een gewone, directe, volledig omkeerbare handeling. Provibr doet precies dit: een gemarkeerde return 403;, elk publiek blok, getest vóór het herladen.

Wat geen enkele opzet oplost is dat het paneel het niet weet. CloudPanel kent geen opgeschorte site, dus het toont er een als gewoon, en iedereen met paneel- of hosttoegang kan het bestand openen en de regel weghalen, inclusief de klant die je net opschortte. Je kunt de toestand afleesbaar maken (de markering is één grep ver, en zo merkt Provibr een handmatige bewerking) maar je kunt CloudPanel er geen eigenaar van maken.

Beslis wat "uit" betekent vóór de eerste klant, niet na de eerste wanbetaler.

Er zijn geen pakketten

CloudPanel heeft geen plannen, geen quota en geen limieten per site. Geen schijfquotum, geen bandbreedtelimiet, geen "deze site mag drie databases hebben". Het dichtst bij een pakket komt een vhost-template, en dat is een NGINX-configuratie: nuttig, maar het is geen limiet, en het houdt niemand tegen die 400 GB gebruikt.

Dat betekent dat je productcatalogus niet in het paneel kan leven. Wat je plan van € 5 onderscheidt van je plan van € 15 moet ergens boven CloudPanel gedefinieerd, afgedwongen en gemeten worden. Wordt het nergens afgedwongen, dan is het geen plan. Dan is het een suggestie.

Er is geen lijst met sites

Er is user:list voor paneel-logins. Er is geen site:list. De sites zelf leven in de eigen SQLite-database van het paneel op de host.

1

De uitweg is die database rechtstreeks lezen: /home/clp/htdocs/app/data/db.sq3, één select over de tabel site, en je hebt elk domein met zijn gebruiker, sjabloon en PHP-versie. Dat is wat Provibr doet, en wat alles wat serieus is uiteindelijk gaat doen. Weet alleen dat je een intern schema leest en geen interface: het kan in een release veranderen zonder dat dat een gebroken belofte is, dus het gaat op het lijstje van dingen om na een panelupgrade opnieuw te controleren.

En één ontwerpbeperking onder dit alles

clpctl draait als root op de host. Dat is geen implementatiedetail waar je omheen kunt: het schrijft NGINX-configuratie, maakt Linux-gebruikers aan en beheert systeemdiensten, en daar zijn die rechten voor nodig.

Het gevolg is dat CloudPanel automatiseren eerder een rechtenvraag is dan een integratievraag. Alles wat clpctl aanstuurt (je eigen script, een cronjob, een deploytool) draait als root op een productiewebserver die de sites van andere mensen draagt. Wat je ook bouwt, bouw het in de wetenschap dat het credential geen afgebakend API-token is; het is administratieve toegang tot de machine. Houd het smal, houd het controleerbaar, en houd het ver weg van alles wat een klant kan bereiken.

Wat er boven het paneel moet bestaan

Haal het panelspecifieke eruit en de lijst is voor elk controlepaneel gelijk, en dat is het nuttige deel: hij verandert niet als je later van paneel wisselt:

• Een bestelformulier en een catalogus, met plannen die iets afdwingbaars betekenen.
• Een betaling die provisioning aanzet binnen seconden, niet binnen een werkdag.
• Een aanmaningspad (te laat, gewaarschuwd, opgeschort, hersteld) met een vastgelegde actie bij elke stap.
• Capaciteit die je kunt zien, zodat je weet hoeveel accounts je draagt en wat ze je kosten voordat de factuur het je vertelt.
• Een activiteitenlog, zodat "wie heeft die site verwijderd" een antwoord heeft.
• Een rechtenmodel voor de mensen die voor je werken, zodat support iets kan herstarten zonder alles te kunnen verwijderen.

Niets daarvan komt met CloudPanel mee, en niets daarvan is wat CloudPanel probeert te zijn.

Waar Provibr past

Ondersteuning voor CloudPanel is live. Een agent in je eigen netwerk verbindt over SSH met de host en draait clpctl zoals een beheerder dat met de hand zou doen, dus er wordt niets op het paneel geïnstalleerd en geen enkele poort hoeft aan het internet te hangen. Een site aanmaken, opschorten, hervatten en verwijderen werkt, en sites die er al stonden worden alleen geïmporteerd als je ze aanvinkt. Daaromheen zit de laag hierboven: plannen en capaciteit, een staffelprijs, een rechtenmodel, een activiteitenlog, en een REST-API en WHMCS-module om het aan te sturen vanuit waar je nu al mee factureert.

Wat de integratie niet kan, is de gaten hierboven wegtoveren, want het zijn eigenschappen van het paneel. Opschorten is het verzonnen deel: een gemarkeerde NGINX-regel die 403 teruggeeft, in elk publiek serverblok gezet en getoetst vóór het herladen, en hervatten haalt hem er weer uit zodat de site byte voor byte terug is. De vhost-template ligt vast zodra een site bestaat, dus er is geen pakketwissel: naar een andere template of PHP-versie gaan betekent opnieuw aanmaken, en Provibr zegt dat in plaats van te doen alsof er iets veranderde. Er is ook geen console en geen verbruiksgrafiek, omdat CloudPanel geen van beide meet.

Wat het niet zal doen

De moeite waard om nu te zeggen in plaats van later: accounts beheren is niet het paneel beheren. CloudPanel installeren, bijwerken, serverinstellingen wijzigen, NGINX afstemmen en de databases en certificaten verzorgen die je klanten aanmaken: dat blijft aan jouw kant, in het paneel, waar het hoort.

Je hoeft je bedrijf niet op één paneel in te zetten. Provibr draait zijn controlepanelen, hypervisors en gamepanelen naast elkaar, met één inventaris, één rechtenmodel en één activiteitenlog. Een licht NGINX-paneel voor de klanten die snelheid op één bak willen, iets met een resellerboom voor wie om cPanel vraagt, en één plek waar je ze allebei ziet.