Een gamepaneel kiezen op de API die je automatiseert

De meeste vergelijkingen van gamepanelen zijn geschreven voor de persoon die er straks in gaat klikken. Ga je gameservers verkopen, dan ben jij die persoon niet. Jij ziet het paneel ruwweg twee keer per jaar; jouw facturatiesysteem ziet het elke paar minuten, voor altijd.

De nuttige vergelijking is dus een andere: wat laat de API je doen, wat weigert hij je te vertellen, en welke van de beloftes in de interface dwingt het paneel werkelijk af als een klant ophoudt met betalen?

Alles hieronder is gemeten tijdens het bouwen van integraties tegen Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 en MCSManager 10.18.2, in augustus 2026.

Eén paneel staat er bewust niet bij. AMP ontbreekt omdat we het niet gemeten hebben. Het is een redelijk product met een echte API, en een vergelijkingsregel schrijven op basis van de documentatie in plaats van op de antwoorden zou precies de zelfverzekerd klinkende vulling zijn waar dit stuk tegen pleit.

Binnenkomen: zes panelen, vijf inlogmodellen

Drie daarvan hebben een waarschuwing nodig.

Pterodactyl en Pelican hebben allebei de sleutels nodig, en de reden is structureel: er bestaat geen power-endpoint op de Application API. Een integratie die alleen met een applicatiesleutel is ingericht, kan servers aanmaken die de eigenaar ervan niet kan starten.

Pelican accepteert een clientsleutel op de Application API. GET /api/application/servers, /nodes en /users geven alle drie 200 terug met de verkeerde sleutel, en de vergissing komt pas boven bij een schrijfactie, als een validatiefout over een ontbrekend gebruikersveld. Pterodactyl antwoordt op datzelfde verzoek met 403. Op Pelican is het controleren van het voorvoegsel van de sleutel de enige manier om een verwisseld paar te betrappen voordat het een verwarrende storing wordt op het moment van provisioning. Op WISP, dat helemaal geen voorvoegsel heeft, is er geen manier om hem te betrappen.

MCSManager komt met zijn API uitgeschakeld. Een verse installatie heeft enableApiKey op false staan, en tot iemand dat aanzet geeft elke aanroep 403 terug met "Insufficient Permissions", ook aanroepen met een geldige sleutel van een geldige beheerder. Dat is op dag één een supportticket voor iedereen die niet weet waar hij moet kijken. Nu je er toch bent: MCSManager knijpt ook af op acht verzoeken per seconde per sessiecookie, dus een client die cookies bewaart wordt afgeknepen waar een client die ze weggooit dat niet wordt.

De vraag die beslist: doet opschorten iets?

Elk van deze panelen kan de opdracht krijgen om een server op te schorten. Dat is de vraag niet. De vraag is of een klant die nog steeds inloggegevens voor het paneel heeft, dat ongedaan kan maken.

De drie panelen uit de Pterodactyl-familie hebben een echte primitieve en daar valt niets over te bespreken.

MCSManager is de verrassing. Ook dat paneel heeft geen opschort-endpoint, maar het heeft wel een vervaldatum: zet de eindtijd van een instantie in het verleden en de daemon weigert hem te starten. Dat hebben we tegen het paneel gecontroleerd en niet tegen onze eigen bewaking, met een rauw verzoek, en we kregen 500 Instance expired. Unable to start the instance. Dat is handhaving. Twee kanttekeningen: je moet de instantie er óók bij killen, want anders draait een lopende server gewoon door tot de uurlijkse vervalcontrole hem opmerkt, tot zestig minuten later. En had de klant zelf een vervaldatum ingesteld, dan is het aan jou om die bij het hervatten terug te zetten; de onze doet dat nog niet.

PufferPanel heeft niets. Er is geen opschort-endpoint en geen kolom voor opgeschort in het datamodel; het statusvocabulaire is running en installing. De best beschikbare actie is de server stoppen en hem killen als hij niet stopt. Een klant met toegang tot het paneel kan op start drukken.

GameAP heeft een vlag die niets doet. Er is een veld blocked, en dat instellen is puur administratief. Wij zetten hem op een draaiende SA-MP-server en de server bleef online, beantwoordde live gamequeries, en kon daarna gewoon weer vanuit het paneel gestart worden.

Dat onderscheid is het waard om in je eigen datamodel op te nemen in plaats van weg te poetsen. Op de twee panelen die het niet afdwingen luidt de eerlijke beschrijving van wat er gebeurd is: "de server is gestopt en in het paneel geblokkeerd, maar een directe login kan hem weer starten", en dat hoort in de auditregistratie van de actie. Zes panelen vastleggen als "opgeschort" terwijl twee ervan dat alleen maar wensen, is hoe een facturatiesysteem stilletjes ophoudt met innen.

Een server aanmaken: vier verschillende vormen

Hier is helemaal geen gemeenschappelijke grond. Vier van deze panelen modelleren een gameserver fundamenteel anders, en de vorm van de aanmaakaanroep volgt daaruit.

Pterodactyl en Pelican willen alles in één keer. Naam, eigenaar, egg, docker-image, startcommando, de complete set omgevingsvariabelen inclusief de variabelen die de klant nooit ziet, limits, feature_limits en een allocatie. Er bestaat geen gedeeltelijke aanmaak; een ontbrekend veld is een weigering per veld. Eén waarde is het kennen waard: limits.io wordt gevalideerd als between:10,1000, dus 0 sturen voor "onbeperkt" is een 422 op een veld waar geen enkele klant ooit van hoort. Pelican heeft die regel omgedraaid: daar is 0 prima en is het veld weglaten de fout.

PufferPanel zit binnenstebuiten. Je bedenkt de server-identifier zelf, acht tekens, en doet daarna een PUT met de volledige templatedefinitie erin, want de templatelijst draagt geen variabelen. Aanmaken is niet installeren: dat is een tweede aanroep. En verwijderen vereist eerst stoppen, anders krijg je een 500.

GameAP maakt een databaserij aan en verder niets. POST /api/servers geeft je een server met installed: 0; installeren is een tweede aanroep waarvan de uitkomst in een daemontaak landt en niet in het HTTP-antwoord, dus je pollt. Er is geen extern ID en geen idempotentiesleutel, en namen zijn niet uniek, wat er samen op neerkomt dat een opnieuw geprobeerde aanmaak stilletjes een duplicaat oplevert. Het teruggegeven ID is de enige identiteit die je krijgt, dus sla hem op voordat er iets anders mis kan gaan.

MCSManager kent helemaal geen templatebegrip. Een instantie is een startcommando, en dat is de hele abstractie. Er bestaat een lijst met snelinstallatie-presets, drieënzestig stuks, maar geen daarvan draagt een ID: het paneel matcht op titel plus omschrijving, vijftig van de drieënzestig titels zijn niet uniek, en de waarden zijn taalafhankelijk. Alles wat daarop gesleuteld is, breekt zodra de klant de taal van het paneel wijzigt.

Wat je daarna kunt zien

Twee regels daar zijn slechter dan ze lijken. GameAP geeft 403 op /api/nodes voor een API-token, dus een plaatsingsmotor kan de capaciteit helemaal niet zien en moet verteld worden waar hij dingen moet neerzetten. En het schijfcijfer van MCSManager is niet alleen maar onbetrouwbaar: het veld is in de daemon als nul gedeclareerd en er wordt nooit iets aan toegekend, dus het is altijd nul, op elke instantie, voor altijd.

Het endpoint /resources van Pterodactyl cachet twintig seconden, en dat doet er meer toe dan het klinkt: poll je sneller, dan krijg je dezelfde bytes terug, en een naïeve berekening van de netwerksnelheid maakt van identieke tellers een dip die nooit gebeurd is. Pelican erfde hetzelfde gedrag. WISP cachet het niet, maar WISP heeft geen uptime-veld, en dat is precies het veld waarmee je een verse meting van een herhaalde zou onderscheiden.

Hoe je dan echt kiest

• Je hebt afdwingbaar opschorten en een echte API nodig. Pterodactyl, of Pelican als je de actief ontwikkelde fork wilt. Dit is het saaie juiste antwoord voor de meeste mensen die gamehosting verkopen.
• Je wilt hosting zonder Docker op kleine machines. MCSManager, en het past beter dan zijn reputatie doet vermoeden, want de vervaldatum geeft je echte handhaving. Neem erbij dat je twee verbruiksmetingen krijgt en geen consolekoppeling.
• Je draait al PufferPanel of GameAP. Prima, maar bouw je opschorting eroverheen: het platform moet de toegang tot het paneel blokkeren, want het paneel doet dat niet.
• Je kiest vandaag zonder erfenis. De API van het paneel gaat jarenlang de beperking van je automatisering zijn, en twee van deze zes kunnen de ene operatie waar je facturatiesysteem het meest van afhangt niet afdwingen.

Wat hier niet gemeten is

AMP, zoals hierboven gezegd. Pterodactyl-versies onder 1.11, op een paneel waar dit precies het soort gedrag is dat in patchreleases verschuift. Ratelimieten op Pterodactyl en Pelican, waarvoor honderden verzoeken tegen een levend paneel nodig zouden zijn om ze eerlijk vast te stellen. MCSManager met Docker aan, waar meer metingen zouden moeten bestaan maar waar wij nooit een gevuld veld hebben gezien. En het klassieke PHP-GameAP, want het paneel dat wij gemeten hebben is de Go-herschrijving, die op zijn minst in de authenticatielaag afwijkt.

Pterodactyl naast Pelican behandelt de fork. Provibr koppelt alle zes deze panelen via een agent die binnen je eigen netwerk draait; de installatienotities staan onder Pterodactyl, Pelican, PufferPanel, GameAP en MCSManager.