Webhosting mit Plesk verkaufen

Plesk betreibt für Sie bereitwillig hundert Abonnements. Was es nicht tut, ist eine Bestellung anzunehmen, das Geld einzuziehen, zu bemerken, dass eine Rechnung offen blieb, oder das Konto stillzulegen, das dazugehört. In dieser Lücke zwischen „einem Panel, das Websites hostet“ und „einem Hosting-Geschäft“ liegt die Arbeit, und auf dieser Seite geht es darum, sie zu überbrücken, ohne in die vier Stellen zu treten, in die man leicht tritt.

Was Plesk Ihnen bereits gibt

Ein Abonnement ist die Einheit, die Sie verkaufen: eine Hauptdomain, ein Serviceplan, Speicher- und Traffic-Grenzen und alles darunter. Ein Serviceplan ist die Beschreibung dieses Pakets durch das Panel selbst: Speicherkontingent, monatlicher Traffic, wie viele Domains und Postfächer, welche Dienste an sind. Beide Begriffe existieren bereits, Sie erfinden also kein Produktmodell, Sie benennen eines, das da ist.

Die API ist auf eine Weise gut, die gerade für ein Hosting-Produkt zählt: Ein Aufruf liest jedes Abonnement auf dem Server, mit Plan, Status, Speicherkontingent und Auslastung. Wir haben das mit 0.33 Sekunden gemessen, egal wie viele es sind. Drei Leseaufrufe geben Ihnen das vollständige Bild eines Servers (Abonnements, Kunden, Pläne), und diese Zahl wächst nicht mit Ihrer Kundenzahl. Dasselbe Bild über REST aufzubauen bräuchte einen Aufruf plus drei je Abonnement.

Ein Key öffnet zwei APIs, und Sie brauchen beide

Plesk hat eine moderne REST-v2-API und eine ältere XML/RPC-API. Keine ist für sich vollständig, und das ist keine Frage der Vorliebe.

REST v2 kennt keine Abonnements und keine Servicepläne. Wir haben seine 43 Pfade aus seinem eigenen OpenAPI-Dokument aufgezählt; /subscriptions und /service-plans sind nicht darunter, und sie abzufragen liefert einen 404, dargestellt als HTML-Seite statt als JSON. Da der Serviceplan das Hosting-Paket ist, muss die gesamte Paketseite über XML laufen.

Der rettende Umstand sind die Zugangsdaten. Der von POST /api/v2/auth/keys ausgestellte Key funktioniert in beiden unverändert: als X-API-Key auf REST und als KEY am XML-Endpunkt. Gemessen, derselbe Key, beide APIs. Sie fragen den Betreiber also nach einem Wert, nicht nach zwei.

Was es Sie kostet, sind zwei Fehler-Vokabulare. REST beantwortet einen unbrauchbaren Key mit HTTP 401 und einem völlig leeren Body. XML beantwortet denselben Key mit HTTP 200 und einem Fehlercode im Dokument. Was uns zur scharfen Kante bringt.

Ein Authentifizierungsfehler, der wie ein leerer Server aussieht

Weil die XML-API für einen schlechten Key HTTP 200 zurückgibt, liest ein Client, der auf den Statuscode prüft, einen Authentifizierungsfehler als eine erfolgreiche Runde, die nichts fand. Und eine erfolgreiche Runde, die nichts fand, hat in jeder Hosting-Plattform eine Bedeutung: Jedes Konto, das gestern da war, ist weg.

Die Folge ist kein kaputtes Dashboard. Es ist ein System, das jeden einzelnen Ihrer Kunden als gelöscht markiert, weil ein Key abgelaufen ist. Die Regel, die daraus folgt, ist absolut: Auf der XML-API trägt der Statuscode überhaupt keine Information, nicht einmal über die Authentifizierung. Parsen Sie das Dokument und behandeln Sie eine unlesbare Antwort als unbekannt statt als leer.

Auch ein leerer Server erzeugt keinen Fehler: Er erzeugt ein einzelnes leeres Ergebnis, was die richtige Antwort ist, wenn es wirklich keine gibt. Diese beiden auseinanderzuhalten ist die ganze Aufgabe.

Die Stilllegungs-Falle: dasselbe Feld schreiben und lesen

Es gibt zwei Wege, ein Abonnement in Plesk stillzulegen, und sie schreiben nicht dasselbe Feld.

Lesen Sie die zweite Zeile noch einmal. Ein Stilllegen über REST lässt das Feld, das die Sammelabfrage liest, auf null. Ein Hosting-Produkt, das über REST stilllegt und über XML abfragt, zeigt das Konto also als aktiv, während es tatsächlich stillgelegt ist. Nichts wirft einen Fehler. Nichts wird rot. Ihr Panel und Ihr Server sind schlicht uneins, und der Erste, dem es auffällt, ist ein Kunde, der eine Website nicht erreicht, die Sie für laufend halten.

Die Regel: stilllegen und fortsetzen über dasselbe Feld, das Sie lesen. Provibr nutzt XML <webspace><set><gen_setup><status>, und danach bewegen sich beide Ansichten gemeinsam: Das XML-Feld meldet 16 und REST meldet suspended.

gen_info.status ist eine Bitmaske, und die von uns gemessenen Werte sind 0 für aktiv, 1 für webspace-off und 16 für vom Administrator deaktiviert. Alles, was nicht null ist, gilt als stillgelegt, was die einzige Lesart ist, die einen bisher ungesehenen Wert übersteht.

Zwei Datensätze, die wir das Panel nie abfragen

Plesk gibt Geheimnisse heraus, wenn Sie den falschen Datensatz anfordern, und es tut das im Klartext:

• <webspace><get> mit dem Datensatz hosting liefert das FTP-Passwort des Kontos im Klartext, mit einem Feld, das es ausdrücklich als Klartext kennzeichnet.
• <customer><get> mit dem Datensatz gen_info liefert den Passwort-Hash des Kunden (bcrypt) samt dem Hash-Typ.

Eine Redaktionsschicht ist die falsche Antwort darauf. Die richtige Antwort ist, nicht zu fragen. Die Abfrage von Provibr fordert genau vier Datensätze an (allgemeine Infos, Limits, Statistiken und Abonnements), und wir sind sie Feld für Feld durchgegangen, um zu bestätigen, dass keiner ein Geheimnis trägt. Die Kundenliste kommt aus REST, das gar kein Passwortfeld hat.

Es gibt eine Design-Folge, die es wert ist, genannt zu werden, weil sie etwas erklärt, das sonst wie eine Lücke aussieht. Der FTP- oder Systembenutzer eines Abonnements wäre eine attraktive kurze Kennung, aber er liegt nur im Datensatz hosting, ihn als Identität zu nutzen hieße also, bei jedem Abfragezyklus das Passwort jedes Kunden abzuholen. Daher stattdessen die Domain.

Die Identität eines Abonnements ist ein Domainname

In Plesk ist ein Abonnement nach seiner Hauptdomain benannt. Das ist es, was das Panel anzeigt, wonach seine API filtert und was jede Integration speichern muss.

Das ist ein echter Unterschied zu cPanel und DirectAdmin, wo ein Konto getrennt einen kurzen Benutzernamen und eine Domain hat, und es hat eine praktische Folge: Die Domain lässt sich hinterher nicht ändern. Was auch immer Ihr Abrechnungssystem als Kennung eines Plesk-Abonnements speichert, ist ein Domainname, und ein Kunde, der seine Website umbenennen will, verlangt ein neues Abonnement statt einer Bearbeitung.

Zwei kleinere Dinge, die unterwegs gemessen wurden. Plesks eigene Spezifikation nennt ein Kundenpasswort von 5 bis 14 Zeichen; ein Passwort mit 22 Zeichen wurde ohne Beanstandung akzeptiert, das dokumentierte Limit ist also nicht das durchgesetzte. Und Plesk wählt die IP-Adresse selbst aus seinem eigenen Pool, weshalb ein Hosting-Konto in Provibr ein leeres Adressfeld hat, bis das Panel eine meldet.

Eine fehlgeschlagene Bestellung kann ein halbes Abonnement hinterlassen

Gemessen: Eine Domain mit einem Serviceplan anzulegen, den es nicht gibt, antwortet mit HTTP 404 und einer klaren Meldung, und das Domain-Objekt existiert danach trotzdem, ohne Hosting-Typ und mit leerem Document-Root. Plesk legt zuerst das Objekt an und wendet danach den Plan an und macht nichts rückgängig, wenn der zweite Schritt scheitert.

Der Kunde hat bezahlt, die Bestellung scheiterte, und der nächste Versuch scheitert nun anders, weil die Domain bereits in Gebrauch ist, durch ein Konto, das er nie erhalten hat. Schlagen Sie den Plan also nach, bevor Sie irgendetwas anlegen, aus der Planliste, die Sie schon geholt haben, und räumen Sie nach jedem fehlgeschlagenen Anlegen auf. Zum Vergleich: Ein Feld-Validierungsfehler wie ein doppelter Login kommt als HTTP 400 zurück und hinterlässt nichts: Diese Prüfung läuft vor der Erstellung, und nur die Plansuche kommt zu spät.

Keine Verzögerung, was seltener ist, als es sein sollte

Die Auslastungsauflistung von DirectAdmin läuft in beide Richtungen rund drei Sekunden hinter der Realität her, was einen zweiten maßgeblichen Aufruf erzwingt. Plesk nicht. Wir haben ein Anlegen und ein Löschen gegen den Sammel-Lesevorgang gemessen:

    0 ms  create
 4519 ms  create returns 201
 4957 ms  bulk read sees the subscription      <- immediately
 4957 ms  delete
12622 ms  delete returns 200
13001 ms  bulk read no longer sees it          <- immediately

Plesk ist transaktional: Sobald der Aufruf antwortet, ist die Änderung im Sammel-Lesevorgang sichtbar. Eine maßgebliche Quelle, kein zweiter Aufruf, kein Warten.

Die Zeiten selbst sind bemerkenswert. Ein Abonnement anzulegen dauert 4.1 bis 4.5 Sekunden und eines zu löschen 7.7 Sekunden, lang genug, dass einem Kunden, der ein Bestellformular betrachtet, gesagt werden muss, dass etwas geschieht. Ein Planwechsel dauert 1.5 Sekunden und ein Stilllegen 0.78.

Was Provibr mit all dem tut

Provibr sitzt zwischen Ihrer Abrechnung und Ihrem Plesk-Server. Sie verbinden den Server mit einem API-Key, und danach ist ein Abonnement eine gewöhnliche Zeile: bestellen, stilllegen, fortsetzen, in einen anderen Serviceplan verschieben, löschen.

• Ein Key, weil derselbe Key beide APIs öffnet.
• Das Stilllegen geht über das Feld, das die Abfrage liest, sodass Panel und Server nicht auseinanderdriften können.
• Die Abfrage fordert nie einen Datensatz an, der ein Passwort enthält, sodass kein Kundengeheimnis die Plattform erreicht.
• Der Plan wird vor dem Anlegen aufgelöst, und ein fehlgeschlagenes Anlegen wird aufgeräumt statt liegen gelassen.
• Nichts wird auf sein eigenes Wort geglaubt. Jede Mutation endet damit, das Abonnement zurückzulesen.
• Der Agent wählt sich nach außen aus Ihrem Netzwerk, sodass Port 8443 nicht zum Internet zeigt und auf dem Plesk-Server nichts installiert wird.
• Abonnements, die Sie nicht über Provibr bestellt haben, bleiben unangetastet, bis Sie sie importieren, was einen Server mit zweihundert bestehenden Kunden übernehmbar macht statt zu einem Neuaufbau.

Was es nicht tut

Es verwaltet Abonnements auf einem Plesk-Server, den Sie betreiben, nicht den Server selbst: Dienste, DNS-Zonen, Mail-Routing und die Einstellungen des Panels selbst bleiben, wo sie sind. Es gibt keine Konsole, denn ein Hosting-Konto ist keine Maschine. Postfächer, Datenbanken und DNS innerhalb eines Abonnements gehören Plesk und Ihrem Kunden.

Eine ehrliche Lücke: Alles hier wurde mit einem Administrator-Key gemessen. Ob ein auf einen Reseller oder Kunden beschränkter Key die XML-API überhaupt nutzen kann, ist ungetestet, deshalb prüft die Integration bei der Verbindung und lehnt Zugangsdaten ab, die nur einen Teil eines Panels sehen können, statt stillschweigend ein halbes zu verwalten.

Weiterlesen

• Plesk-Abrechnung und -Provisionierung automatisieren: die drei Momente, in denen Geld und Maschinen sich berühren, und die Fallen in jedem.
• cPanel-Alternativen für Hosting-Anbieter: sechs Panels nach Lizenzmodell, Migrationsaufwand und gemessenem API-Verhalten.
• Plesk einrichten: der API-Key, Servicepläne, Webpläne und Abonnements importieren.

Gemessen an Plesk Obsidian 18.0.80 im August 2026, mit allen Antworten als Fixtures aufgezeichnet. Das Verhalten mit einem auf einen Reseller beschränkten Key, mit mehr als einem Abonnement je Kunde und unter realer Verkehrslast wurde nicht gemessen und ist oben als solches vermerkt.