Webhosting mit HestiaCP verkaufen

HestiaCP ist das gesündeste offene Control Panel, das es gibt. Auf GitHub gemessen am 21. August 2026: 4.481 Sterne, 345 Mitwirkende und drei Releases innerhalb einer einzigen Woche. Es liefert Ihnen Konten, Pakete, DNS, Mail, Datenbanken und eine saubere Oberfläche, und es kostet nichts.

Was es Ihnen nicht liefert, ist eine Möglichkeit, all das zu verkaufen. Es gibt kein Bestellformular, keine Rechnung, keine Mahnung, kein „diese Kundschaft zahlt nicht mehr, schalten Sie sie ab“. Suchen Sie nach hestiacp billing, dann stehen am selben Tag gemessen Forenbeiträge ganz oben: Leute, die fragen, wie man HestiaCP-Konten verkauft, und andere Leute, die mit einem halben Skript antworten.

Diese Seite handelt von der Schicht darüber: was die API von HestiaCP wirklich zurückgibt, wo sie Ihnen wehtut, und was stimmen muss, bevor Sie einer fremden Person einen Bestellknopf hinstellen.

Was HestiaCP Ihnen bereits gibt

Zwei Dinge, und es sind die richtigen zwei.

Pakete. Ein HestiaCP-Paket beschreibt, was ein Konto nutzen darf: Speicherplatz, Datenvolumen und wie viele Domains, Datenbanken und Postfächer. Das ist Ihr Produktkatalog, einmal definiert und überall sonst nur über seinen Namen angesprochen.

Ein Kontolebenszyklus, der auf ein Abonnement passt. Anlegen, stilllegen, reaktivieren, in ein anderes Paket verschieben, löschen, genau die Zustände, die ein bezahltes Hosting-Konto durchläuft, und für jeden gibt es einen Befehl:

Der Rest dieser Seite handelt von der Lücke zwischen dieser Tabelle und etwas, auf das Sie sich um drei Uhr nachts verlassen können.

Die API hat zwei Türen, und eine davon lügt

POST https://host:8083/api/ akzeptiert zwei Arten von Zugangsdaten, und welche Sie senden, entscheidet darüber, welcher Code Ihre Anfrage bearbeitet. Der alte Weg nimmt Benutzername und Passwort. Der neuere, seit HestiaCP 1.6 verfügbar, nimmt einen Access Key: eine ID aus 20 Zeichen und ein Geheimnis aus 40 Zeichen.

Sie verhalten sich nicht gleich. Einen Befehl senden, den es gar nicht gibt:

Der Legacy-Weg meldet Erfolg für einen Befehl, der nie gelaufen ist. Die Ursache steht in HestiaCPs eigener Quelle: er gibt OK aus, sobald die Authentifizierung null zurücklieferte und der Befehl nichts auf stdout schrieb. Er sieht nie auf den Exit-Code des Befehls selbst und setzt für das Ergebnis weder einen HTTP-Status noch die Exit-Code-Kopfzeile. Jeder Befehl, der still scheitert, kommt als OK zurück.

Also: Access Keys verwenden. Nicht nur, weil der Legacy-Weg lügen kann, sondern weil ein Schlüssel einzeln zurückgezogen werden kann, im Panel namentlich aufgeführt ist und das Administratorpasswort Ihres Panels nicht in den Tresor eines anderen legt. Bauen Sie auch keinen Rückfall vom einen auf den anderen: Zwei Türen bedeuten zwei Fehleroberflächen, und hier ist die Rückfalltür die unzuverlässige.

Der HTTP-Status ist nicht die Antwort, der Exit-Code schon

HestiaCP faltet rund zwanzig interne Exit-Codes auf vier HTTP-Status. Zwei Folgen, beide gemessen:

Eine geglückte Änderung liefert 204, nicht 200. Jedes v-add-user, v-suspend-user, v-delete-user, v-add-web-domain und v-change-user-package kam als HTTP 204 mit leerem Body zurück. Ein Client, der nur 200 akzeptiert, weist also jeden Aufruf zurück, der funktioniert hat.

HTTP 401 bedeutet hier vier verschiedene Dinge: falsches Geheimnis (Exit 9), Schlüssel außerhalb seiner Berechtigungen (10), Adresse nicht zugelassen (10), und „dieser Benutzer ist bereits stillgelegt“ (5). Ein Client, der 401 als „Zugangsdaten falsch“ liest, meldet Ihnen einen abgelaufenen Schlüssel, während Sie lediglich ein Konto zweimal stillgelegt haben.

Lesen Sie Hestia-Exit-Code. Der Status ist eine Ableitung.

Der, der Sie wirklich lahmlegt

Fünf abgelehnte Aufrufe, und HestiaCP sperrt Ihre Adresse. Das ist kein Rate Limit, von dem man sich zurückziehen kann: Es ist fail2ban, standardmäßig mit maxretry = 5 gegen /var/log/hestia/auth.log konfiguriert, und es endet in einem iptables-DROP. Danach lehnt das Panel Ihre Aufrufe nicht mehr ab, es antwortet überhaupt nicht mehr: Ihre Überwachung zeigt Timeouts, und es sieht wie ein Netzwerkproblem aus.

Woran man hängen bleibt, ist die Frage, was als fehlgeschlagene Anmeldung zählt. Nicht nur ein falsches Geheimnis: HestiaCPs Schlüsselprüfung schreibt dieselbe failed to login-Zeile, wenn ein Schlüssel für einen Befehl außerhalb seiner Berechtigungen verwendet wird. Gemessen, im Auth-Log des Panels selbst:

12:57:52 <key> 84.85.173.142 v-list-users successfully launched
12:57:52 <key> 84.85.173.142 failed to login      ← ein Befehl außerhalb des Schlüsselumfangs

Daraus folgen drei Regeln, und keine davon ist optional:

1. 01Nach einem Authentifizierungs- oder Berechtigungsfehler niemals automatisch wiederholen. Eine Wiederholschleife auf einem falschen Schlüssel sperrt Sie binnen einer Minute aus, und dann lautet die Meldung für Ihre Kundschaft „Panel nicht erreichbar“ statt „Schlüssel stimmt nicht“, das denkbar schlechteste Signal, weil es auf das falsche Problem zeigt.
2. 02Der Schlüssel muss unbeschränkt sein, also dem Administrator gehören. Leere Berechtigungen bedeuten alle Befehle, und das akzeptiert HestiaCP nur für den Root-Benutzer. Der mitgelieferte Berechtigungssatz billing kommt nahe heran, lässt aber v-list-user-packages und v-list-web-domains aus, die zwei Befehle, die Ihren Paketkatalog und die Domains eines Kontos lesen. Mit diesem Satz bleiben beide leer, und ein beschränkter Schlüssel, der sie einmal pro Abfragerunde berührt, sperrt Sie planmäßig aus.
3. 03Ihr Fehlertext muss das erwähnen, denn zum Aufheben braucht es eine Shell auf dem Panel: v-delete-firewall-ban <Adresse> HESTIA.

Leer bedeutet niemand

Noch eine Falle beim ersten Mal. HestiaCP führt in API_ALLOWED_IP eine Liste der Adressen, die die API benutzen dürfen. Bei einer frischen Installation ist diese Liste leer, und leer bedeutet hier niemand, nicht jeder. Jeder Aufruf kommt mit 401 und IP is not allowed to connect with API zurück, während Ihr Schlüssel völlig in Ordnung ist. Das ist die wahrscheinlichste erste Störung der ganzen Anbindung, und sie verdient eine eigene Fehlermeldung statt eines allgemeinen „Authentifizierung fehlgeschlagen“.

Ein Konto anzulegen kostet zwei Aufrufe, und diese Lücke ist echt

DirectAdmin, cPanel und Virtualmin legen ein Konto samt Domain in einem Aufruf an. HestiaCP nicht:

v-add-user        USER PASSWORD EMAIL [PACKAGE] [NAME]   → legt den Benutzer an
v-add-web-domain  USER DOMAIN [IP] [RESTART] [ALIASES]   → hängt die Domain darunter

Scheitert der zweite Aufruf (die Domain gehört bereits jemandem, oder ihre Form wird abgelehnt), dann bleibt Ihnen ein echter Unix-Benutzer mit Home-Verzeichnis, ohne Website, und mit einer Zeile in jeder Zählung, die Sie ausführen. Gemessen mit einer absichtlich ungültigen Domain: der Benutzer existierte danach mit U_WEB_DOMAINS = 0. Was Sie auch bauen, es muss ausgleichen: scheitert Schritt zwei, den Benutzer löschen und den ursprünglichen Fehler melden.

Was Provibr damit macht

Provibr verbindet sich mit HestiaCP über einen Agenten, der in Ihrem eigenen Netzwerk läuft und ausgehend verbindet: Auf dem Panel muss also nichts geöffnet werden. Sie geben ihm vier Dinge: die Adresse des Panels samt Port 8083, die Access-Key-ID, das Geheimnis und, solange das Panel noch sein selbstsigniertes Zertifikat verwendet, den SHA-256-Fingerabdruck zum Anheften. Der Agent bewahrt sie in seinem eigenen Tresor auf Ihrem Host auf; die Plattform kann sie nicht zurücklesen.

Von da an:

• Pakete werden verkäuflich. Ein Webhosting-Plan zeigt auf ein Paket einer Integration, unter einem eigenen Namen, zu einem eigenen Preis.
• Fünf Aktionen, über den Benutzernamen adressiert: anlegen mit Domain und Paket, stilllegen, reaktivieren, Paket wechseln, löschen. Das zweistufige Anlegen wird wie oben beschrieben ausgeglichen.
• Der Verbrauch kommt gratis mit der Abfrage. Jede Auslesung von v-list-users trägt DISK_QUOTA, U_DISK, BANDWIDTH und U_BANDWIDTH für jedes Konto mit sich, alles in Megabyte. Grenzen und Verbrauch landen also auf der Serverseite und in den Diagrammen, ohne einen zweiten Aufruf, der dem ersten hinterherhinken könnte.
• Bereits vorhandene Konten lassen sich importieren. Der Agent listet auf, was auf dem Panel steht, und Sie haken ab, welche davon Server in Provibr werden.

Was es nicht tut

Provibr verwaltet Konten, nicht das Panel. Es installiert HestiaCP nicht, aktualisiert es nicht, ändert keine Servereinstellungen und rührt weder DNS noch Postfächer noch Datenbanken an: Die bleiben in HestiaCP, wo Sie und Ihre Kundschaft sie weiter benutzen. Für ein Hosting-Konto gibt es keine Konsole, weil es nichts gibt, woran man eine hängen könnte.

Und eine ehrliche Anmerkung zur Leistung: ein Panel mit vielen Konten auszulesen kostet je Konto einen zusätzlichen Aufruf, denn HestiaCP hat keinen Befehl, der die Domains aller Konten auf einmal auflistet. An 26 Konten gemessen sind das seriell gut 8,5 Sekunden; parallel bleibt es unter zwei. Wenn Sie das selbst schreiben, tun Sie es nicht seriell: Etwa ab 60 Konten beginnt eine serielle Abfrage mit ihrer eigenen nächsten Runde zu kollidieren.

Sie müssen sich nicht auf ein Panel festlegen. Provibr betreibt heute seine Controlpanels, Hypervisoren und Gamepanels nebeneinander, in einem Bestand, mit einem Rechtemodell und einem Aktivitätsprotokoll. HestiaCP für die Kundschaft, die ein offenes Panel will, etwas anderes für die, die nach cPanel fragt, und eine Stelle, an der Sie beides sehen.