Webhosting mit CyberPanel verkaufen

CyberPanel ist das Panel, das Hoster mit OpenLiteSpeed am häufigsten in einem Atemzug mit DirectAdmin nennen. Auf GitHub gemessen am 21. August 2026: 2.007 Sterne, 723 Forks und 362 offene Issues, bei einem langsameren Release-Takt als die meisten Vergleichbaren.

Es hat eine REST-API, und alles, was Sie brauchen, um darauf Hosting zu verkaufen (eine Website anlegen, stilllegen, das Paket wechseln, löschen), ist Teil dieser API. Was es nicht hat, ist irgendetwas, das entscheidet, wann diese Dinge geschehen, und was es sehr wohl hat, ist eine Reihe von Antworten, die man leicht falsch liest.

Zuerst: Der API-Zugang ist ausgeschaltet

Bei einem frischen CyberPanel ist die API abgeschaltet, und das gilt auch für Ihren Hauptadministrator. Sie schalten sie unter Users → API Access für den Benutzer admin ein. Mehr ist nicht nötig; Sie melden sich mit dem Login an, den Sie ohnehin haben.

Lassen Sie sie aus, kommt jeder Aufruf als API Access Disabled. zurück, was Sie auch senden. Was einen Nachmittag kostet, ist die Reihenfolge: CyberPanel prüft diesen Schalter, bevor es das Passwort prüft. Bei ausgeschaltetem Schalter liefern ein richtiges und ein falsches Passwort also dieselbe 403. Alles zeigt auf Ihre Zugangsdaten, während das Problem ein Häkchen weiter liegt.

Ist der Schalter erst an, ist der Vertrag darunter sauber und wirklich brauchbar:

richtiges Passwort  → HTTP 200  {"verifyConn": 1}
falsches Passwort   → HTTP 401  {"verifyConn": 0, "error_message": "Invalid password."}
unbekannter Nutzer  → HTTP 404  {"error_message": "Administrator not found."}

Drei Situationen, drei verschiedene Handlungen für die Kundschaft, alle drei unterscheidbar.

Der Administrator muss admin heißen

Keine Einstellung, sondern eine Bedingung, und sie kommt von CyberPanel und nicht von etwas, das darauf aufsetzt. Ein Teil dieser API wird von einer wörtlichen Namensprüfung bewacht, die jeden anderen Benutzer als admin ablehnt, und genau dieser Teil ist es, der die Websites des Panels auflistet und meldet, wie weit eine neue gekommen ist.

Beides ist unvermeidlich, wenn Sie darauf Hosting verkaufen wollen: Sie brauchen die Liste, um zu wissen, was existiert, und die Fortschrittsmeldung aus dem Grund im nächsten Abschnitt. Ein umbenannter Administrator ist nicht verwendbar, und was Sie auch bauen, es sollte das beim Verbindungstest sagen, bevor Ihre erste Bestellung es für Sie herausfindet.

Ein Konto ist eine Domain, kein Benutzername

Das ist der strukturelle Unterschied zu DirectAdmin, cPanel und Virtualmin, und er ändert, wie Sie das Produkt modellieren.

Der Website-Datensatz von CyberPanel hat ein eindeutiges domain-Feld, und jeder Befehl zielt darauf: Löschen nimmt domainName, Stilllegen und Paketwechsel nehmen websiteName, und alle drei schlagen die Website über die Domain nach. Es gibt keinen Benutzernamen zum Adressieren. Der Unix-Benutzer wird erzeugt, nicht gewählt: fünf Buchstaben aus der Domain plus vier zufällige Ziffern. Gemessen für provibr-test-1.example.com: provi7346, mit dem Home-Verzeichnis nach der Domain benannt, nicht nach dem Benutzer. Sie können diesen Namen nicht wählen, nicht vorhersagen, und er erscheint in genau einer API-Antwort und in keiner einzigen Auflistung.

Eine Folge sollten Sie vor Ihrem hundertsten Konto kennen: beim Anlegen einer Website wird darunter auch ein Panel-Login angelegt, mit API-Zugang, und dieser Login überlebt das Löschen der Website. Nach einem Löschvorgang gemessen: Unix-Benutzer weg, Home-Verzeichnis weg, vhost weg, Datenbankzeile weg; der Eigentümer-Login war noch da. Der Aufräumpfad von CyberPanel wird von einer Prüfung bewacht, die zu diesem Zeitpunkt nicht gelingen kann, und der daraus folgende Fehler wird verschluckt. Entfernt ihn nichts darüber, hinterlässt jede gekündigte Kundschaft einen Login.

Das Anlegen meldet Erfolg, bevor es etwas weiß

Das ist das Wichtigste, was man an der API von CyberPanel verstehen muss.

createWebsite antwortet nach etwa drei Sekunden mit:

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

Das kommt an, bevor die meiste Arbeit getan ist: der Endpunkt baut eine Befehlszeile, startet sie ohne zu warten und kehrt zurück. Der echte Fortschritt liegt in einer Statusdatei, die über einen separaten Aufruf gelesen wird. Gemessen, ein echtes Anlegen:

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

Rund fünfzig Sekunden, davon etwa achtundzwanzig ein SSL-Versuch, den das Panel ohnehin unternimmt: Die API überschreibt dieses Feld bedingungslos, es gibt also keinen Weg, über die API eine Website ohne SSL anzulegen. Bei einer Domain, die noch nicht öffentlich auflöst, sind das achtundzwanzig Sekunden Warten auf ein Zertifikat, das nicht kommt.

Und die erste Antwort ist kein Urteil. Mit absichtlich falschen Eingaben gemessen:

Nur die Form von Domain und E-Mail wird sofort geprüft. Ob die Domain frei ist und ob das Paket existiert, zeigt sich erst in der Statusdatei. Eine Anbindung, die der ersten Antwort vertraut, meldet eine erfolgreiche Bestellung für eine Domain, die bereits vergeben war.

Zwei Einzelheiten machen das Abfragen schwieriger, als es aussieht. Das Lesen eines abgeschlossenen Status löscht die Datei, eine zweite Abfrage liefert also „Datei nicht vorhanden“ mit einem „noch nicht fertig“-Kennzeichen: Ein Client, der einmal zu oft abfragt, sieht für immer „läuft noch“ für ein Anlegen, das geglückt ist. Und der Statusaufruf liegt ausschließlich auf dem nur für admin zugänglichen Teil, weshalb die Namensbedingung oben nicht optional ist.

Stilllegen ist ein Webserver-Trick, keine Kontosperre

Stilllegen und Reaktivieren sind der wohlerzogene Teil dieser API: beides wirkt sofort, und die eigene Liste des Panels zeigt den neuen Zustand unmittelbar.

Aber wissen Sie, was es tut. CyberPanel schreibt die vhost-Konfiguration der Website auf eine Stilllegungsseite um und startet den Webserver neu. Der Unix-Benutzer wird nicht gesperrt; FTP, Mail und Datenbanken laufen weiter. Die Website wird unerreichbar und sonst nichts. Das unterscheidet sich von DirectAdmin, und es zählt, sobald Sie das Stilllegen einsetzen, um Zahlung durchzusetzen.

Noch etwas, das eine Konstante im Code wert ist und keine Variable: die Umsetzung lautet if state == "Suspend": … else: <reaktivieren>, ohne jede Prüfung des Wertes. An einer echten Website gemessen:

1. state:"Suspend"  → Liste: Suspended
2. state:"suspend"  → {"websiteStatus": 1, "error_message": "None"}
3. Liste:           → Active     ← ein Kleinbuchstabe hat die Website reaktiviert

Ein Tippfehler schaltet eine stillgelegte Kundschaft stillschweigend wieder ein und meldet Erfolg.

Der Paketwechsel ändert die Buchführung und sonst nichts

changePackageAPI kehrt nach etwa 270 Millisekunden zurück, und das Panel zeigt den neuen Paketnamen. Danach von innerhalb des Servers gemessen, mit einem Paket mit absichtlich anderen Grenzen: das Plattenkontingent war unverändert (soft 0, hard 0) und die vhost-Konfiguration trug weiterhin die Speicher- und Prozessgrenzen des alten Pakets.

Es wurde nichts angewendet. Der ganze Vorgang ist eine Feldänderung in der Datenbank. Lesen Sie den Paketnamen in CyberPanel als Buchführung und nicht als Grenze, die mitgewandert wäre, und was darüber liegt, sollte das sagen, statt ein wirksames Upgrade zu suggerieren.

Es gibt keine Verbrauchsdaten

CyberPanel ist das einzige Control Panel in Provibr ohne Verbrauchsdiagramme, und das ist keine Auslassung der Integration: das Panel misst es nicht.

Datenvolumen wird berechnet und dann verworfen: Es erreicht die Liste nie. Der Plattenverbrauch stammt aus einem Zwischenspeicher am Website-Datensatz, und bei einer frisch angelegten Website ist dieses Feld leer, der gemeldete Wert fällt also auf null zurück. Eine Null aus einem leeren Zwischenspeicher lässt sich nicht von einer Website unterscheiden, die tatsächlich nichts verbraucht. Ein Diagramm, das ewig auf null steht, sieht aus wie eine Messung; deshalb gibt es keines.

Was Provibr damit macht

Provibr verbindet sich über einen Agenten in Ihrem eigenen Netzwerk, der ausgehend verbindet: Das Panel muss also nichts öffnen. Er fragt nach vier Dingen: der Adresse des Panels samt Port 8090, dem Benutzernamen admin, dem Passwort dieses Administrators und, solange das Panel noch das mitgelieferte Zertifikat verwendet, dem SHA-256-Fingerabdruck zum Anheften.

Letzteres ist in der Praxis nicht optional. Jedes frische CyberPanel liefert dasselbe selbstsignierte Zertifikat aus, ausgestellt auf www.example.com und von CyberPanel selbst signiert. Ein Browser nennt es deshalb falsch statt selbstsigniert, und die Kette prüft sich nie. Den Fingerabdruck anzuheften bedeutet, genau diesem einen Zertifikat zu vertrauen, statt die Prüfung abzuschalten. Legen Sie ein eigenes Zertifikat auf den Hostnamen des Panels, prüft sich die Kette von selbst und das Feld darf leer bleiben.

Machen Sie sich klar, was dieses Passwort ist. CyberPanel hat kein API-Token, das diese Befehle abdeckt: Innerhalb seiner eigenen API ist der Token-Weg je Endpunkt an oder aus, und gerade die vier, die eine Website anlegen, stilllegen, umpacken und entfernen, verlangen das Passwort. Es ist also das vollständige Passwort Ihres Hauptadministrators.

Damit steht: Pakete werden als Webhosting-Pläne unter eigenem Namen und Preis verkäuflich, Bestellungen legen Websites an und warten auf das echte Ergebnis statt auf die erste Antwort, Stilllegen und Reaktivieren funktionieren auf Wunsch und bei Überschreiten Ihrer Kapazität, und bereits vorhandene Websites lassen sich importieren.

Was es nicht tut

Provibr verwaltet Websites, nicht das Panel: es installiert CyberPanel nicht, aktualisiert es nicht und ändert keine Servereinstellungen. Es gibt keine Konsole. DNS, Postfächer und Datenbanken bleiben unangetastet: CyberPanel kann das alles selbst, und nichts darüber steuert es an. Und es gibt keine Verbrauchsdiagramme, weil es nichts Ehrliches zu zeichnen gibt.

Sie müssen nicht auf ein Panel setzen. Provibr betreibt heute seine Controlpanels, Hypervisoren und Gamepanels nebeneinander, in einem Bestand, mit einem Rechtemodell und einem Aktivitätsprotokoll.