Zum Inhalt springen

Blog ·

Das CyberPanel-WHMCS-Modul und die Alternative

Was ein WHMCS-Modul für CyberPanel kann und was nicht, denn die API setzt die Decke. Gemessene Grenzen und eine Provisioning-Schicht darüber.

Von Provibr

Wenn Sie WHMCS betreiben und OpenLiteSpeed-Hosting verkaufen wollen, suchen Sie nach einem CyberPanel-Provisioning-Modul. Am 21. August 2026 gemessen liefern die Ergebnisse für diesen Suchbegriff ein GitHub-Repository, das von einer einzelnen Person gepflegt wird, sowie einen Community-Forenbeitrag.

Das ist keine Kritik an jemandes Arbeit. Es beschreibt eine Lücke: eine Software, die zwischen Ihren Rechnungen und den Websites Ihrer Kundschaft steht und die die meisten Hoster als Nebenprojekt vorfinden statt als Produkt.

Diese Seite handelt davon, was ein solches Modul kann, was es strukturell nicht kann, und wie eine andere Form von Lösung aussieht. Der erste Teil wiegt am schwersten, denn die Decke ist nicht das Modul; sie ist die API von CyberPanel.

Die Decke: was die API von CyberPanel zulässt

Gegen CyberPanel 3.0 gemessen, nicht aus der Dokumentation übernommen. Jedes Modul (das auf GitHub, eines, das Sie selbst schreiben, oder das weiter unten beschriebene) wird von all dem begrenzt.

Das Anlegen antwortet, bevor es das Ergebnis kennt

createWebsite kehrt nach etwa drei Sekunden mit createWebSiteStatus: 1 zurück. Das ist kein Urteil; es bedeutet, dass die Arbeit begonnen wurde. Der Endpunkt startet einen Hintergrundbefehl und kehrt sofort zurück. Der echte Fortschritt liegt in einer Statusdatei, die separat abgefragt werden muss.

Mit absichtlich falschen Eingaben gemessen:

FallHTTP-AntwortWas tatsächlich geschah
Domain existiert bereitscreateWebSiteStatus: 1, ErfolgThis website already exists. [404]
Unbekanntes PaketcreateWebSiteStatus: 1, ErfolgPackage matching query does not exist. [404]
Ungültige DomaincreateWebSiteStatus: 0sofort abgelehnt

Nur die Form von Domain und E-Mail wird vorab geprüft. Ein Modul, das der ersten Antwort vertraut, setzt eine WHMCS-Bestellung auf aktiv für eine Website, die nie angelegt wurde. Und die Kundschaft erhält Zugangsdaten für etwas, das nicht existiert.

Diese Statusdatei abzufragen hat zwei weitere Haken. Das Lesen eines abgeschlossenen Status löscht ihn, eine Abfrage zu viel macht aus einem fertigen Anlegen also ein dauerhaftes „läuft noch“. Und der Statusaufruf liegt auf dem Teil der API von CyberPanel, der jeden Administrator ablehnt, der nicht wörtlich admin heißt.

Das ganze Anlegen dauert etwa fünfzig Sekunden, davon rund achtundzwanzig ein SSL-Versuch, den CyberPanel bedingungslos unternimmt: Die API überschreibt dieses Feld, was Sie auch senden. Jedes Modul braucht ein Zeitlimit, das dazu passt.

Der Paketwechsel ändert ein Datenbankfeld

changePackageAPI kehrt nach etwa 270 Millisekunden zurück, und das Panel zeigt den neuen Namen. Danach von innerhalb des Servers gemessen, mit einem Paket mit 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. Eine WHMCS-Upgrade-Bestellung kann also abgeschlossen und berechnet werden und den Namen im Panel ändern, während die tatsächlichen Grenzen der Kundschaft genau die alten sind. Kein Modul kann das beheben: Die gesamte Umsetzung dieses Endpunkts ist eine Feldänderung.

Das Stilllegen sperrt das Konto nicht

CyberPanel legt eine Website still, indem es ihren vhost auf eine Stilllegungsseite umschreibt und den Webserver neu startet. Der Unix-Benutzer wird nicht gesperrt; FTP, Mail und Datenbanken laufen weiter. Legen Sie wegen ausbleibender Zahlung still, hat Ihre Kundschaft weiterhin ihre Mail und ihre Datenbank. Das kann genau das sein, was Sie wollen, aber es sollte eine Entscheidung sein und keine Überraschung.

Es gibt auch eine schärfere Kante: die Umsetzung lautet if state == "Suspend": … else: <reaktivieren>, ohne Prüfung. Gemessen: "suspend" kleingeschrieben zu senden hat eine stillgelegte Website reaktiviert und Erfolg gemeldet. Jedes Modul sollte diese zwei Werte als Konstanten halten und sie nie aus einer Variablen zusammensetzen.

Es gibt keine Verbrauchsdaten

Das Datenvolumen wird von CyberPanel berechnet und dann verworfen, bevor es irgendeine Liste erreicht. Der Plattenverbrauch stammt aus einem Zwischenspeicher am Website-Datensatz, der bei einer neuen Website leer ist, der Wert fällt also auf null zurück. Und eine Null aus einem leeren Zwischenspeicher lässt sich nicht von einer Website unterscheiden, die nichts verbraucht.

WHMCS hat einen Hook zur Verbrauchserfassung, der Platten- und Datenvolumenzahlen erwartet. Bei CyberPanel gibt es nichts Ehrliches, was man hineinschreiben könnte: ein Modul, das es trotzdem füllt, meldet einen Standardwert und keine Messung.

Der API-Zugang ist aus, und die Prüfreihenfolge verbirgt, warum

Bei einem frischen CyberPanel ist die API abgeschaltet, auch für den Hauptadministrator, und der Schalter wird vor dem Passwort geprüft. Bei ausgeschaltetem Schalter liefern ein richtiges und ein falsches Passwort also dasselbe API Access Disabled. Die erste Störung jedes Moduls für dieses Panel sieht aus wie ein Problem mit den Zugangsdaten und ist keines.

Was das für ein Modul bedeutet

Nichts davon ist innerhalb eines WHMCS-Moduls zu beheben, denn nichts davon ist ein Modulproblem. Was sich zwischen Modulen unterscheidet, ist der ehrliche Umgang damit:

  • Fragt es den Anlegestatus ab oder vertraut es der ersten Antwort?
  • Liest es den Status einmal und hält das Ergebnis fest, oder fragt es weiter, bis es das Ergebnis versehentlich löscht?
  • Sagt es Ihnen, dass ein Paketwechsel nichts angewendet hat?
  • Lässt es den Verbrauchs-Hook leer oder füllt es ihn mit Nullen, die wie Daten aussehen?
  • Sagt es „API-Zugang ist abgeschaltet“ statt „ungültige Zugangsdaten“?

Das sind die Fragen, die Sie jedem Modul stellen sollten, das Sie erwägen. Sie lassen sich durch Lesen des Codes beantworten, und sie wiegen schwerer als die Funktionsliste. Eine kommt noch dazu, und die betrifft Sie und nicht den Code: wer pflegt es in achtzehn Monaten? Ein Provisioning-Modul steht auf dem kritischen Pfad jeder Bestellung, die Sie annehmen.

Die Alternative: eine Provisioning-Schicht, kein Panel-Modul

Provibr steht zwischen Ihrem Abrechnungssystem und Ihrer Infrastruktur. Es ist kein WHMCS-Modul für CyberPanel; es ist eine Provisioning-Plattform, die mit CyberPanel spricht und mit der WHMCS über ein Modul spricht, unabhängig davon, was darunter liegt.

Der praktische Unterschied:

Ein CyberPanel-WHMCS-ModulProvibr
Abgedeckte PanelsCyberPanelControlpanels, Hypervisoren und Gamepanels, darunter CyberPanel
WHMCS-Anbindungdieses Modulein Modul für alle
Abrechnung außerhalb WHMCSnoch ein Modul schreibenREST-API
ErreichbarkeitWHMCS muss ans Panel kommenAgent verbindet ausgehend, nichts geöffnet
Speicherung der Zugangsdatenin der WHMCS-Datenbankim Tresor des Agenten auf Ihrem Host
Ergebnis des Anlegenshängt vom Modul abfragt den echten Status ab
Verbrauchsdiagramme bei CyberPanelnicht verfügbarkeine, und es sagt das
Paketwechsel bei CyberPanelwendet nichts anwendet nichts an, und sagt das
Kostenkostenlosje verwaltetem Hosting-Konto und Monat
DNS, Mail, DatenbankenPanelPanel
Wer es pflegtwechselndein Unternehmen, das es verkauft

Zwei Zeilen verdienen eine Erläuterung, denn das sind die ehrlichen.

Kosten. Das Modul ist kostenlos und Provibr nicht. Provibr berechnet die Kapazität, die Sie reservieren (wie viele Hosting-Konten Sie gleichzeitig betreiben dürfen), zu einem gestaffelten Stückpreis, der mit steigender Zahl sinkt. Was Sie Ihrer eigenen Kundschaft berechnen, bleibt vollständig Ihre Sache. Haben Sie zwölf CyberPanel-Websites und keine Wachstumspläne, ist ein kostenloses Modul die richtige Antwort.

Dieselben Grenzen, andere Ehrlichkeit. Provibr repariert den Paketwechsel von CyberPanel nicht, erfindet keine Verbrauchszahlen und sperrt ein stillgelegtes Konto nicht. Es kann das auch nicht: das sind Eigenschaften des Panels. Was es tut, ist sich zu weigern, etwas anderes vorzugeben.

Wie es in WHMCS passt

Ein Modul, als schlichte ZIP-Datei in modules/servers/ installiert. In WHMCS fügen Sie einen Server hinzu, der mit einem API-Schlüssel auf Provibr zeigt, und lassen dann ein WHMCS-Produkt auf einen Provibr-Webhosting-Plan zeigen. Eine bezahlte Bestellung legt das Konto an, eine Stilllegung legt es still, eine Beendigung entfernt es. Ihre Kundschaft behält ein Konto, eine Rechnung und einen Login.

Der API-Schlüssel trägt Geltungsbereiche, und was er tatsächlich darf, ist die Schnittmenge dieser Bereiche und der Rechte des Mitglieds, zu dem er gehört. Ein Schlüssel kann Zugang also nur einengen, nie erweitern. Nehmen Sie einer Kollegin ein Recht, wird jeder ihrer Schlüssel bei der nächsten Anfrage enger, ohne dass jemand etwas zurückziehen muss.

Betreiben Sie kein WHMCS, stehen dieselben Vorgänge über die REST-API bereit: ein Schlüssel, eine Basis-URL. Alles, was eine Maschine berührt, antwortet „angenommen“ mit einem Befehl zum Verfolgen, denn Ihre Infrastruktur ist nur über den Agenten in Ihrem eigenen Netzwerk erreichbar. Lesevorgänge antworten sofort.

Wann das Modul die bessere Wahl ist

Ganz offen: ist CyberPanel das einzige Panel, das Sie betreiben, haben Sie WHMCS bereits, ist Ihr Volumen klein und lesen Sie ohne Weiteres PHP, wenn etwas kaputtgeht, dann ist ein Modul weniger Maschinerie und keine monatlichen Kosten. Die Grenzen am Anfang dieser Seite gelten für beide Möglichkeiten gleichermaßen.

Für eine Schicht darüber spricht es, sobald Sie mehr als ein Panel betreiben, sobald Sie die Zugangsdaten von Ihrem WHMCS-Host weghaben wollen, sobald etwas anderes als WHMCS Bestellungen aufgeben muss, oder sobald Sie wollen, dass der Provisioning-Pfad jemandes Produkt ist statt jemandes Wochenende.

Provibr betreibt heute seine Controlpanels, Hypervisoren und Gamepanels nebeneinander, in einem Bestand, unter einem Rechtemodell, mit einem Aktivitätsprotokoll. Sie müssen sich nicht zwischen CyberPanel und allem anderen entscheiden.

Häufige Fragen

Gibt es ein offizielles CyberPanel-WHMCS-Modul?

Gemessen am 21. August 2026 lieferte diese Suche ein GitHub-Repository, das eine Einzelperson pflegt, und einen Forenthread. Das beschreibt eine Lücke und ist keine Kritik an jemandes Arbeit.

Warum meldet das Modul Erfolg für eine Website, die nie angelegt wurde?

Weil createWebsite antwortet, bevor es das Ergebnis kennt. Eine bereits vorhandene Domain und ein unbekanntes Paket kommen beide als createWebSiteStatus: 1 zurück, und das heißt, die Arbeit wurde begonnen, nicht dass sie gelang. Vorab geprüft wird nur die Form der Domain und der E-Mail-Adresse.

Wendet eine Paketänderung auf CyberPanel wirklich etwas an?

Nein. Gemessen an CyberPanel 3.0 antwortet changePackageAPI in rund 270 Millisekunden und das Panel zeigt den neuen Namen, während Festplattenkontingent und vhost-Limits unverändert bleiben. Die gesamte Implementierung dieses Endpunkts ist eine Feldänderung, und kein Modul kann das reparieren.

Warum ergibt ein korrektes Passwort „API Access Disabled“?

Weil die API auf einem frischen CyberPanel aus ist, auch für den Hauptadministrator, und das Flag vor dem Passwort geprüft wird. Ein richtiges und ein falsches Passwort liefern dieselbe Antwort, sodass der erste Fehlschlag jedes Moduls für dieses Panel wie ein Anmeldeproblem aussieht und keines ist.

Modul oder Provisioning-Schicht?

Wenn CyberPanel Ihr einziges Panel ist, Sie WHMCS bereits haben und Ihr Volumen klein ist, ist ein Modul weniger Maschinerie und keine monatliche Rechnung. Eine Schicht darüber lohnt sich, sobald Sie mehr als ein Panel betreiben, sobald die Zugangsdaten von Ihrem WHMCS-Host verschwinden sollen, oder sobald etwas anderes als WHMCS Bestellungen auslösen muss.

Fangen Sie mit einem Host und einem Agenten an

Konto erstellen, den Agenten mit einem einzigen Befehl installieren und Ihren ersten Proxmox-Host verbinden. Die Testphase läuft 14 Tage und fragt nicht nach Zahlungsdaten.