Blog ·
Gameservers verkopen met GameAP
Verkoop gameserverhosting op GameAP: het admin-API-token, waarom er geen keuzelijst met spellen is, hoe plaatsing en poorten werken, en wat opschorten doet.
Door Provibr
GameAP is een klein project. Op 21 augustus 2026 had de GitHub-repository 60 sterren, 9 forks en 2 bijdragers. Dat is de moeite van het benoemen waard, want het schept verwachtingen: er is geen groot ecosysteem van billingmodules, provisioningscripts en forumdraden omheen. Draai je GameAP en wil je verkopen wat erop staat, dan sta je er grotendeels alleen voor.
Deze pagina gaat over dat gat. Provibr koppelt aan een GameAP-paneel en levert, bedient en importeert er gameservers op. Alles hieronder is gemeten tegen een echt GameAP 4.4.2-paneel en niet van een featurelijst overgeschreven, inclusief de plekken waar GameAP zich anders gedraagt dan je zou verwachten.
Wat de integratie werkelijk dekt
| Mogelijkheid | Ondersteund |
|---|---|
| Aanmaken, starten, stoppen, herstarten, herinstalleren, verwijderen | Ja |
| Opschorten en hervatten | Ja, met een kanttekening (zie hieronder) |
| Bestaande servers importeren | Ja |
| Console in de browser | Nee |
| Verbruiksgrafieken (cpu, geheugen, schijf, netwerk) | Nee |
| Het paneel, zijn nodes, bestanden of gebruikers beheren | Nee |
De twee "nee"-regels zijn geen omissies; de redenen staan onderaan.
Stap 1: het API-token
GameAP authenticeert met één API-token. Geen OAuth2-client, geen sleutelpaar, geen sessie om in leven te houden: één bearer, en dat is de hele credential.
Vier dingen die ertoe doen.
Het moet door een beheerder gemaakt worden en de create-bevoegdheid dragen. GameAP-tokens zijn gescopeerd. Een token zonder admin:server:create kan servers prima opsommen maar ze niet aanmaken of verwijderen. Dat wil je weten vóór je eerste bestelling, want een gescopeerd-maar-verkeerd token ziet er gezond uit tot precies het moment dat een klant betaalt. Provibr controleert de create-bevoegdheid bij het testen van de verbinding, niet bij de eerste bestelling.
Verwijderen hangt aan diezelfde bevoegdheid. Er bestaat in GameAP helemaal geen server:delete-scope. We hebben een delete zien slagen met een token dat alleen admin:server:create plus de gewone server-scopes droeg. Eén token dekt de hele levenscyclus.
Het token heeft de vorm id|geheim. Dat is de Laravel-Sanctum-vorm: een numerieke id, een pijp, en een geheim van 48 tekens. Provibr houdt die vorm aan en weigert een token dat zonder de id ervoor geplakt is. Dat is een echte plakfout, en hem daar vangen is beter dan een verwarrende 401 verderop.
Het verloopt niet. De tabel personal_access_tokens in GameAP heeft geen expires_at-kolom. Dit is de schoonste langlevende credential van alle panelen die we gekoppeld hebben: de agent werkt maandenlang door zonder dat iemand iets opnieuw invoert. Vergelijk dat met panelen waar het geheim een wachtwoord is en elke rotatie een supportticket wordt.
Eén praktische noot: GameAP toont het token één keer en bewaart daarna alleen een hash. Kopieer het meteen. Provibr slaat het evenmin op, dus inloggegevens opnieuw versturen betekent een nieuw token aanmaken.
Stap 2: transport, en daar eerlijk over zijn
Een verse GameAP-installatie serveert kale HTTP op poort 8025, met 443 dicht. Er is geen veld voor een TLS-fingerprint in het formulier, want zonder TLS is er geen certificaat om te pinnen.
Dat werkt. Het betekent ook dat het API-token, en alles wat de integratie doet, onversleuteld over de lijn gaat. Vind je dat bezwaarlijk (en op een paneel met de servers van je klanten erop hoort dat waarschijnlijk zo te zijn), zet er dan een reverse proxy met TLS voor. De agent valideert dan gewoon de certificaatketen, zonder pin.
Stap 3: het plan, en waarom er geen keuzelijst is
Een GameAP-server wordt gebouwd uit een spel (een titel als samp of minecraft) en een game mod, zijn template. Samen zijn ze ongeveer wat één egg bij Pterodactyl is.
Hier zit het scherpste verschil met elk ander gamepaneel dat we ondersteunen: Provibr kan ze niet voor je opsommen. Met een gescopeerd agent-token geven /api/games, /api/game_mods en /api/nodes alle drie een 403. De catalogus lezen is rolgebonden aan een adminsessie, en geen enkele tokenbevoegdheid ontsluit hem.
Er is dus geen keuzelijst. Je opent je eigen GameAP-paneel, leest de gamecode en de mod-id, en typt ze in het plan. Een gameplan draagt daarna die gamecode, die mod-id en de resourcelimieten, en bestellen is vanaf dat punt plangedreven.
Het is meer typewerk dan een keuzelijst. Het is ook de eerlijke vorm: een keuzelijst die we niet kunnen vullen is erger dan een veld dat zegt wat het wil.
Stap 4: plaatsing en poorten
Uit diezelfde 403 volgen twee gevolgen.
De node komt uit een instelling, niet uit de plaatsingsengine. Provibr rangschikt nodes op vrije capaciteit waar dat kan. Hier niet, want de nodelijst is helemaal niet te lezen. In plaats daarvan draagt de integratie een node-id, dat op een paneel met één node gewoon 1 is. Op een paneel met meerdere nodes landt een server op de node die jij noemde, en er wordt niets gerangschikt.
Poorten komen uit een bereik dat jij instelt. GameAP heeft geen eigen allocatiesysteem: er is niets dat een vrije poort uitdeelt. De agent kiest zelf een vrije set poorten (spel, query en RCON) uit een bereik dat je op de integratie instelt.
Wat bestellen werkelijk doet
Hier wijkt GameAP het sterkst af van een paneel als Pterodactyl, en hier gaat een naïeve integratie mis.
POST /api/serversschrijft de databaserij. Er wordt niets geïnstalleerd.- Een tweede aanroep start de installatie, en de daemon van het paneel voert die uit als asynchrone taak.
- Provibr pollt die taak tot hij een eindstatus bereikt.
- Daarna start de server.
De doorslaggevende regel: het HTTP-antwoord van een actie betekent alleen dat de taak in de wachtrij staat. Niet dat hij geslaagd is. We hebben een stop gemeten die terugkwam met een fout uit een race op de host: elke gameserver draait als een eigen systemd-unit op de node, en systemctl stop kan een race met zichzelf verliezen. De uitkomst van de taak is de waarheid; het HTTP-antwoord is een ontvangstbewijs. Provibr leest de taak.
Nog twee gemeten werkelijkheden om rekening mee te houden. Er is geen extern id en geen idempotency-sleutel, en servernamen zijn niet uniek: we maakten twee servers met dezelfde naam aan en kregen twee keer een 201 met verschillende id. De id die de create-aanroep teruggeeft is de enige identiteit die er is, dus een herhaalde create maakt stilzwijgend een duplicaat. En de installatie-omgeving is niet overal compleet: een TeamSpeak 3-installatie op een standaardpaneel strandde omdat lbzip2 ontbrak voor het uitpakken van de .tar.bz2, terwijl een SA-MP-installatie op dezelfde machine schoon draaide. Reken erop dat "de installatie lukt bij het ene spel wel en bij het andere niet" een supportcategorie wordt.
Opschorten: lees dit voor je erop vertrouwt
Wanneer Provibr een gameserver opschort (om een capaciteitslimiet te handhaven), stopt hij de server en markeert hem geblokkeerd in het paneel.
Beide helften zijn nodig, en dit is waarom: de blocked-vlag van GameAP handhaaft niets. We zetten blocked op een draaiende SA-MP-server en die bleef online, met antwoord op live spelquery's. Daarna stuurden we een start naar een geblokkeerde server en kregen gewoon een taak terug. De vlag is administratief.
Provibr stopt de server dus om de limiet echt te handhaven. Maar iedereen met directe toegang tot het GameAP-paneel kan hem weer starten. De blokkade is net zo goed een Provibr-begrip als een paneelbegrip, en dat schrijven we liever op dan dat je het tijdens je eerste overschrijding ontdekt.
Wat Provibr hier niet doet
Geen console. GameAP heeft er wel een, over een websocket, maar die loopt op een apart kortlevend token uit een eigen authenticatiestap en een eigen frameprotocol, een ander pad dan de tunnel die onze agent met de andere gamepanelen deelt. Dat is echt werk, geen vlaggetje. Het tabblad aanzetten voordat dat werk bestaat zou een tunnel beloven die er niet is.
Geen verbruiksgrafieken. GameAP rapporteert per server geen cpu, geheugen, schijf of netwerk. Er is geen endpoint. Een grafiek die vastzit op nul ziet eruit als een meting, en "geen meting" en "geen verbruik" zijn niet hetzelfde, dus tonen we niets.
Geen paneelbeheer. Nodes, bestanden, gebruikers en het paneel zelf blijven van jou. Waar de integratie over gaat is een gameserver op het paneel.
Wat dit betekent voor een kleine hoster
Draai je GameAP, dan wordt de keuze meestal voorgesteld als "hou je paneel en factureer met de hand" of "stap over op iets waar een billingsysteem al mee praat". Dat is een schijnkeuze, en een dure: een paneel vol draaiende gameservers migreren is geen weekendklus.
Provibr koppelt aan controlepanelen, hypervisors en gamepanelen naast elkaar. Je hoeft niet te kiezen. Hou GameAP voor de spellen die je al host, zet ernaast wat je verder nodig hebt, en laat het bestellen, de capaciteitstelling en het opschorten-bij-niet-betalen over al die panelen heen vanaf één plek lopen.