Gameserver verkaufen mit GameAP

GameAP ist ein kleines Projekt. Am 21. August 2026 hatte das GitHub-Repository 60 Sterne, 9 Forks und 2 Mitwirkende. Das gehört ausgesprochen, denn es setzt die Erwartung: Es gibt kein großes Ökosystem aus Abrechnungsmodulen, Provisionierungsskripten und Forenbeiträgen darum herum. Wer GameAP betreibt und verkaufen möchte, was darauf läuft, steht weitgehend allein da.

Diese Seite schließt diese Lücke. Provibr verbindet sich mit einem GameAP-Panel und stellt darauf Gameserver bereit, steuert und importiert sie. Alles Folgende wurde an einem echten GameAP-4.4.2-Panel gemessen und nicht von einer Funktionsliste abgeschrieben, einschließlich der Stellen, an denen GameAP sich anders verhält als erwartet.

Was die Integration tatsächlich abdeckt

Die beiden „Nein“-Zeilen sind kein Versehen; die Gründe stehen am Ende.

Schritt 1: das API-Token

GameAP authentifiziert sich mit einem einzigen API-Token. Kein OAuth2-Client, kein Schlüsselpaar, keine Sitzung, die am Leben gehalten werden muss: ein Bearer, und das ist die gesamte Zugangsberechtigung.

Vier Dinge sind daran wichtig.

Es muss von einem Administrator erstellt werden und die Berechtigung zum Anlegen tragen. GameAP-Tokens sind gescopet. Ein Token ohne admin:server:create kann Server einwandfrei auflisten, sie aber weder anlegen noch löschen. Das sollten Sie vor der ersten Bestellung wissen, denn ein gescopetes, aber falsches Token wirkt genau bis zu dem Moment gesund, in dem ein Kunde bezahlt. Provibr prüft die Anlege-Berechtigung beim Testen der Verbindung, nicht bei der ersten Bestellung.

Löschen hängt an derselben Berechtigung. Einen server:delete-Scope gibt es in GameAP überhaupt nicht. Wir haben ein erfolgreiches Löschen mit einem Token gemessen, das nur admin:server:create und die gewöhnlichen Server-Scopes trug. Ein Token deckt den gesamten Lebenszyklus ab.

Das Token hat die Form id|geheimnis. Das ist die Laravel-Sanctum-Form: eine numerische ID, ein Pipe-Zeichen und ein 48-Zeichen-Geheimnis. Provibr behält diese Form bei und weist ein Token zurück, das ohne die vorangestellte ID eingefügt wurde. Das ist ein echter Einfügefehler, und ihn dort abzufangen ist besser als eine verwirrende 401 weiter hinten.

Es läuft nicht ab. Die Tabelle personal_access_tokens in GameAP hat keine Spalte expires_at. Das ist die sauberste langlebige Zugangsberechtigung aller Panels, die wir angebunden haben: Der Agent arbeitet monatelang weiter, ohne dass jemand etwas neu eingibt. Vergleichen Sie das mit Panels, bei denen das Geheimnis ein Passwort ist und jede Rotation zu einem Support-Ticket wird.

Ein praktischer Hinweis: GameAP zeigt das Token einmal an und speichert danach nur einen Hash. Kopieren Sie es sofort. Provibr speichert es ebenfalls nicht, das erneute Senden der Zugangsdaten bedeutet also, ein neues Token zu erstellen.

Schritt 2: Transport, und dabei ehrlich bleiben

Eine Standardinstallation von GameAP liefert einfaches HTTP auf Port 8025 aus, Port 443 ist geschlossen. Im Zugangsdatenformular gibt es kein Feld für einen TLS-Fingerabdruck, denn ohne TLS gibt es kein Zertifikat, das sich anheften ließe.

Das funktioniert. Es bedeutet aber auch, dass das API-Token und alles, was die Integration tut, unverschlüsselt über die Leitung geht. Wenn Ihnen das wichtig ist (und bei einem Panel, auf dem die Server Ihrer Kunden liegen, sollte es das wohl sein), setzen Sie einen Reverse Proxy mit TLS davor. Der Agent validiert dann die Zertifikatskette wie üblich, ohne Anheftung.

Schritt 3: der Plan, und warum es keine Auswahlliste gibt

Ein GameAP-Server wird aus einem Spiel (einem Titel wie samp oder minecraft) und einem Game Mod gebaut, seiner Vorlage. Zusammen sind sie ungefähr das, was bei Pterodactyl ein Egg ist.

Hier liegt der schärfste Unterschied zu jedem anderen Gamepanel, das wir unterstützen: Provibr kann sie nicht für Sie auflisten. Mit einem gescopeten Agent-Token geben /api/games, /api/game_mods und /api/nodes alle drei eine 403 zurück. Das Lesen des Katalogs ist an eine Admin-Sitzung gebunden, und keine Token-Berechtigung schaltet es frei.

Es gibt also kein Auswahlfeld. Sie öffnen Ihr eigenes GameAP-Panel, lesen den Spielcode und die Mod-ID ab und tragen sie in den Plan ein. Ein Gameplan trägt danach diesen Spielcode, diese Mod-ID und die Ressourcengrenzen, und die Bestellung läuft ab da plangesteuert.

Das ist mehr Tipparbeit als eine Auswahlliste. Es ist auch die ehrliche Form: Ein Auswahlfeld, das wir nicht füllen könnten, wäre schlimmer als ein Feld, das sagt, was es will.

Schritt 4: Platzierung und Ports

Aus derselben 403 folgen zwei Konsequenzen.

Der Knoten kommt aus einer Einstellung, nicht aus der Platzierungslogik. Provibr sortiert Knoten nach freier Kapazität, wo es geht. Hier nicht, denn die Knotenliste lässt sich überhaupt nicht lesen. Stattdessen trägt die Integration eine Knoten-ID, die auf einem Panel mit einem Knoten schlicht 1 ist. Auf einem Panel mit mehreren Knoten landet ein Server auf dem Knoten, den Sie benannt haben, und es wird nichts sortiert.

Ports kommen aus einem Bereich, den Sie festlegen. GameAP hat kein eigenes Zuteilungssystem: Nichts vergibt einen freien Port. Der Agent wählt selbst einen freien Satz Ports (Spiel, Query und RCON) aus einem Bereich, den Sie an der Integration einstellen.

Was eine Bestellung tatsächlich auslöst

Hier weicht GameAP am stärksten von einem Panel wie Pterodactyl ab, und hier geht eine naive Integration schief.

1. 01POST /api/servers schreibt den Datenbankeintrag. Es wird nichts installiert.
2. 02Ein zweiter Aufruf startet die Installation, und der Daemon des Panels führt sie als asynchrone Aufgabe aus.
3. 03Provibr fragt diese Aufgabe ab, bis sie einen Endzustand erreicht.
4. 04Danach startet der Server.

Die entscheidende Regel: Die HTTP-Antwort einer Aktion bedeutet nur, dass die Aufgabe in der Warteschlange steht. Sie bedeutet nicht, dass sie erfolgreich war. Wir haben ein stop gemessen, das mit einem Fehler aus einem Wettlauf auf dem Host zurückkam: Jeder Gameserver läuft als eigene systemd-Unit auf dem Knoten, und systemctl stop kann einen Wettlauf mit sich selbst verlieren. Das Ergebnis der Aufgabe ist die Wahrheit, die HTTP-Antwort ist eine Empfangsbestätigung. Provibr liest die Aufgabe.

Zwei weitere gemessene Gegebenheiten, mit denen zu rechnen ist. Es gibt keine externe ID und keinen Idempotenzschlüssel, und Servernamen sind nicht eindeutig: Wir haben zwei Server mit demselben Namen angelegt und zweimal eine 201 mit unterschiedlicher ID erhalten. Die ID aus dem Anlege-Aufruf ist die einzige Identität, die es gibt, ein wiederholtes Anlegen erzeugt also stillschweigend ein Duplikat. Und die Installationsumgebung ist nicht überall vollständig: Eine TeamSpeak-3-Installation auf einem Standardpanel scheiterte, weil lbzip2 für das Entpacken der .tar.bz2 fehlte, während eine SA-MP-Installation auf derselben Maschine sauber durchlief. Rechnen Sie damit, dass „die Installation klappt beim einen Spiel und beim anderen nicht“ eine Support-Kategorie wird.

Sperren: lesen Sie das, bevor Sie sich darauf verlassen

Wenn Provibr einen Gameserver sperrt (um eine Kapazitätsgrenze durchzusetzen), stoppt es den Server und markiert ihn im Panel als blockiert.

Beide Hälften sind nötig, und zwar deshalb: Das blocked-Flag von GameAP setzt nichts durch. Wir haben blocked auf einem laufenden SA-MP-Server gesetzt, und er blieb online und beantwortete Live-Spielabfragen. Anschließend haben wir einen Start an einen blockierten Server geschickt und ganz normal eine Aufgabe zurückbekommen. Das Flag ist administrativ.

Provibr stoppt den Server also, um die Grenze tatsächlich durchzusetzen. Aber jeder mit direktem Zugang zum GameAP-Panel kann ihn wieder starten. Die Sperre ist ebenso sehr ein Provibr-Begriff wie ein Panel-Begriff, und das schreiben wir lieber auf, als dass Sie es bei Ihrer ersten Überschreitung entdecken.

Was Provibr hier nicht tut

Keine Konsole. GameAP hat eine, über einen WebSocket, aber sie läuft über ein separates, kurzlebiges Token aus einem eigenen Authentifizierungsschritt und ein eigenes Frame-Protokoll, ein anderer Weg als der Tunnel, den unser Agent mit den übrigen Gamepanels teilt. Das ist echte Arbeit, kein Schalter. Den Reiter zu aktivieren, bevor diese Arbeit existiert, würde einen Tunnel versprechen, den es nicht gibt.

Keine Auslastungsdiagramme. GameAP meldet je Server weder CPU noch Speicher, Festplatte oder Netzwerk. Es gibt keinen Endpunkt. Ein Diagramm, das auf null steht, sieht aus wie eine Messung, und „keine Messung“ und „keine Auslastung“ sind nicht dasselbe, deshalb zeigen wir nichts.

Keine Panel-Verwaltung. Knoten, Dateien, Benutzer und das Panel selbst bleiben Ihre Sache. Worum es der Integration geht, ist ein Gameserver auf dem Panel.

Was das für einen kleinen Hoster bedeutet

Wer GameAP betreibt, bekommt die Wahl meist so gestellt: „Panel behalten und von Hand abrechnen“ oder „auf etwas wechseln, das ein Abrechnungssystem bereits spricht“. Das ist eine Scheinwahl, und eine teure: Ein Panel voller laufender Gameserver zu migrieren ist keine Wochenendarbeit.

Provibr verbindet sich mit Controlpanels, Hypervisoren und Gamepanels nebeneinander. Sie müssen sich nicht entscheiden. Behalten Sie GameAP für die Spiele, die Sie schon hosten, stellen Sie daneben, was Sie sonst brauchen, und lassen Sie Bestellung, Kapazitätszählung und Sperrung bei Nichtzahlung über alle Panels hinweg von einer Stelle aus laufen.