Ein Gamepanel nach seiner API auswählen

Die meisten Vergleiche von Gameserver-Panels sind für die Person geschrieben, die darin herumklicken wird. Wenn Sie Gameserver verkaufen wollen, sind Sie diese Person nicht. Sie werden das Panel etwa zweimal im Jahr sehen, und Ihr Abrechnungssystem wird es alle paar Minuten sehen, für immer.

Der nützliche Vergleich ist also ein anderer: Was lässt die API Sie tun, was verweigert sie Ihnen zu sagen, und welche der Versprechen aus der Oberfläche setzt das Panel tatsächlich durch, wenn ein Kunde aufhört zu zahlen.

Alles Folgende wurde beim Bauen von Integrationen gegen Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 und MCSManager 10.18.2 gemessen, im August 2026.

Ein Panel fehlt bewusst in der Tabelle. AMP steht hier nicht, weil wir es nicht gemessen haben. Es ist ein vernünftiges Produkt mit einer echten API, und eine Vergleichszeile aus seiner Dokumentation statt aus seinen Antworten zu schreiben wäre genau die selbstsicher klingende Füllung, gegen die dieser Text argumentiert.

Hineinkommen: sechs Panels, fünf Zugangsmodelle

Drei davon brauchen eine Warnung.

Pterodactyl und Pelican brauchen beide Schlüssel, und der Grund ist struktureller Art: Auf der Application-API gibt es keinen Power-Endpunkt. Eine Integration, die nur mit einem Application-Schlüssel eingerichtet ist, kann Server anlegen, die ihr Eigentümer nicht starten kann.

Pelican akzeptiert einen Client-Schlüssel auf der Application-API. GET /api/application/servers, /nodes und /users liefern mit dem falschen Schlüssel alle 200, und der Fehler zeigt sich erst bei einem Schreibvorgang, als Validierungsfehler über ein fehlendes Benutzerfeld. Pterodactyl antwortet auf dieselbe Anfrage mit 403. Auf Pelican ist die Prüfung des Schlüsselpräfixes die einzige Möglichkeit, ein vertauschtes Paar zu fangen, bevor daraus ein verwirrender Fehlschlag beim Bereitstellen wird. Auf WISP, das überhaupt kein Präfix hat, gibt es diese Möglichkeit nicht.

MCSManager wird mit abgeschalteter API ausgeliefert. Eine frische Installation hat enableApiKey auf false, und bis jemand das einschaltet, liefert jeder Aufruf 403 „Insufficient Permissions“, auch Aufrufe mit einem gültigen Schlüssel eines gültigen Administrators. Das ist am ersten Tag ein Supportticket für jeden, der nicht weiß, wo er nachsehen muss. Wenn Sie schon dabei sind: MCSManager begrenzt außerdem auf acht Anfragen pro Sekunde je Sitzungs-Cookie, ein Client, der Cookies behält, wird also gedrosselt, wo einer, der sie wegwirft, es nicht wird.

Die entscheidende Frage: bewirkt eine Sperre etwas?

Jedem dieser Panels kann man sagen, es solle einen Server sperren. Das ist nicht die Frage. Die Frage ist, ob ein Kunde, der noch Zugangsdaten fürs Panel hat, das rückgängig machen kann.

Die drei Panels aus der Pterodactyl-Familie haben ein echtes Primitiv, da gibt es nichts zu besprechen.

MCSManager ist die Überraschung. Es hat ebenfalls keinen Sperr-Endpunkt, aber es hat einen Ablauf: Setzen Sie die Endzeit einer Instanz in die Vergangenheit, und der Daemon weigert sich, sie zu starten. Wir haben das gegen das Panel geprüft und nicht gegen unsere eigene Absicherung, mit einer rohen Anfrage, und bekamen 500 Instance expired. Unable to start the instance. Das ist Durchsetzung. Zwei Einschränkungen: Sie müssen die Instanz zusätzlich abschießen, denn sonst läuft ein laufender Server weiter, bis die stündliche Ablaufprüfung ihn erwischt, bis zu sechzig Minuten später. Und hatte ein Kunde ein eigenes Ablaufdatum gesetzt, liegt es an Ihnen, es beim Freigeben zurückzusetzen; unsere Umsetzung tut das noch nicht.

PufferPanel hat nichts. Es gibt keinen Sperr-Endpunkt und keine Spalte für eine Sperre im Datenmodell; das Statusvokabular ist running und installing. Die beste verfügbare Handlung ist, den Server zu stoppen und ihn abzuschießen, wenn er nicht stoppt. Ein Kunde mit Panelzugang kann auf Start drücken.

GameAP hat ein Flag, das nichts bewirkt. Es gibt ein Feld blocked, und es zu setzen ist rein administrativ. Wir haben es an einem laufenden SA-MP-Server gesetzt, und der Server blieb online, beantwortete weiterhin Spielabfragen und ließ sich danach aus dem Panel wieder starten.

Diesen Unterschied sollten Sie in Ihr eigenes Datenmodell einbauen, statt ihn zu glätten. Auf den beiden Panels, die ihn nicht durchsetzen, lautet die ehrliche Beschreibung des Geschehenen „der Server wurde gestoppt und im Panel blockiert, aber eine direkte Anmeldung kann ihn wieder starten“, und das gehört in den Prüfeintrag der Handlung. Sechs Panels als „gesperrt“ zu verbuchen, wenn zwei davon es sich nur wünschen, ist der Weg, auf dem ein Abrechnungssystem still aufhört zu kassieren.

Einen Server anlegen: vier verschiedene Formen

Hier gibt es überhaupt keinen gemeinsamen Boden. Vier dieser Panels modellieren einen Gameserver grundlegend verschieden, und die Form des Anlege-Aufrufs folgt daraus.

Pterodactyl und Pelican wollen alles auf einmal. Name, Eigentümer, Egg, Docker-Image, Startbefehl, den vollständigen Satz Umgebungsvariablen samt derer, die der Kunde nie sieht, limits, feature_limits und eine Allocation. Ein teilweises Anlegen gibt es nicht; ein fehlendes Feld ist eine Absage je Feld. Ein Wert lohnt sich zu wissen: limits.io wird mit between:10,1000 validiert, 0 für „unbegrenzt“ zu senden ist also ein 422 auf einem Feld, von dem kein Kunde je hören wird. Pelican hat diese Regel umgedreht, dort ist 0 in Ordnung und das Feld wegzulassen der Fehler.

PufferPanel ist von innen nach außen gestülpt. Sie prägen die Serverkennung selbst, acht Zeichen, und schicken dann per PUT die vollständige Template-Definition inline mit, denn die Template-Liste trägt keine Variablen. Anlegen installiert nicht: Das ist ein zweiter Aufruf. Und Löschen verlangt vorheriges Stoppen, sonst bekommen Sie ein 500.

GameAP legt eine Datenbankzeile an und sonst nichts. POST /api/servers gibt Ihnen einen Server mit installed: 0; die Installation ist ein zweiter Aufruf, dessen Ergebnis in einer Daemon-Aufgabe landet und nicht in der HTTP-Antwort, Sie fragen also nach. Es gibt keine externe ID und keinen Idempotency-Key, und Namen sind nicht eindeutig, was zusammen bedeutet, dass ein wiederholtes Anlegen still ein Duplikat erzeugt. Die zurückgegebene ID ist die einzige Identität, die Sie bekommen, speichern Sie sie also, bevor irgendetwas anderes schiefgehen kann.

MCSManager hat überhaupt kein Template-Konzept. Eine Instanz ist ein Startbefehl, und das ist die ganze Abstraktion. Es gibt eine Liste von Schnellinstallations-Vorlagen, dreiundsechzig Stück, aber keine trägt eine ID: Das Panel gleicht über Titel plus Beschreibung ab, fünfzig der dreiundsechzig Titel sind nicht eindeutig, und die Werte hängen von der Sprache ab. Alles, was darauf schlüsselt, geht kaputt, sobald der Kunde die Sprache des Panels wechselt.

Was Sie danach sehen können

Zwei Einträge darin sind schlimmer, als sie aussehen. GameAP antwortet auf /api/nodes für ein API-Token mit 403, eine Platzierungslogik kann Kapazität also gar nicht sehen und muss gesagt bekommen, wohin sie etwas legen soll. Und die Disk-Zahl von MCSManager ist nicht bloß unzuverlässig: Das Feld ist im Daemon als null deklariert und wird nie zugewiesen, es ist also immer null, auf jeder Instanz, für immer.

Der Endpunkt /resources von Pterodactyl zwischenspeichert zwanzig Sekunden lang, und das zählt mehr, als es klingt: Fragen Sie schneller ab, bekommen Sie dieselben Bytes zurück, und eine naive Berechnung der Netzrate macht aus identischen Zählern einen Einbruch, den es nie gab. Pelican hat dasselbe Verhalten geerbt. WISP speichert das nicht zwischen, aber WISP hat kein Uptime-Feld, und genau das wäre das Feld, mit dem Sie eine frische Messung von einer wiederholten unterscheiden.

Wie Sie tatsächlich wählen

• Sie brauchen eine durchsetzbare Sperre und eine echte API. Pterodactyl, oder Pelican, wenn Sie den aktiv entwickelten Fork wollen. Das ist die langweilige richtige Antwort für die meisten, die Gamehosting verkaufen.
• Sie wollen Hosting ohne Docker auf kleinen Maschinen. MCSManager, und es passt besser, als sein Ruf vermuten lässt, denn der Ablauf gibt Ihnen echte Durchsetzung. Nehmen Sie hin, dass Sie zwei Verbrauchswerte bekommen und keine Anbindung der Konsole.
• Sie betreiben bereits PufferPanel oder GameAP. In Ordnung, aber bauen Sie Ihre Sperre darüber: Die Plattform muss den Panelzugang blockieren, denn das Panel wird es nicht tun.
• Sie wählen heute ohne Altlasten. Die API des Panels wird auf Jahre die Beschränkung Ihrer Automatisierung sein, und zwei dieser sechs können die eine Operation nicht durchsetzen, von der Ihr Abrechnungssystem am meisten abhängt.

Was hier nicht gemessen ist

AMP, wie oben gesagt. Pterodactyl-Versionen unter 1.11, auf einem Panel, bei dem sich genau diese Art Verhalten in Point-Releases verschiebt. Ratenbegrenzungen bei Pterodactyl und Pelican, für die es Hunderte Anfragen gegen ein laufendes Panel bräuchte, um sie ehrlich festzustellen. MCSManager mit aktiviertem Docker, wo es mehr Messwerte geben sollte, wo wir aber nie ein gefülltes Feld gesehen haben. Und klassisches PHP-GameAP, denn das gemessene Panel ist die Go-Neufassung, die sich zumindest in ihrer Authentifizierungsschicht unterscheidet.

Pterodactyl neben Pelican behandelt den Fork. Provibr bindet alle sechs dieser Panels über einen Agenten an, der in Ihrem eigenen Netz läuft; die Einrichtungsnotizen stehen unter Pterodactyl, Pelican, PufferPanel, GameAP und MCSManager.