Vendre des serveurs de jeu avec GameAP

GameAP est un petit projet. Le 21 août 2026, son dépôt GitHub comptait 60 étoiles, 9 forks et 2 contributeurs. Cela mérite d’être dit, car cela fixe les attentes : il n’existe pas autour de lui un grand écosystème de modules de facturation, de scripts de provisionnement et de fils de discussion. Si vous exploitez GameAP et souhaitez vendre ce qu’il héberge, vous êtes largement seul.

Cette page comble cet écart. Provibr se connecte à un panneau GameAP et y provisionne, contrôle et importe des serveurs de jeu. Tout ce qui suit a été mesuré sur un véritable panneau GameAP 4.4.2, et non recopié d’une liste de fonctionnalités, y compris les endroits où GameAP se comporte autrement qu’on ne l’attendrait.

Ce que l’intégration couvre réellement

Les deux lignes « non » ne sont pas des oublis ; les raisons figurent à la fin.

Étape 1 : le jeton d’API

GameAP s’authentifie avec un seul jeton d’API. Pas de client OAuth2, pas de paire de clés, pas de session à maintenir en vie : un porteur, et c’est tout le justificatif.

Quatre choses comptent.

Il doit être créé par un administrateur et porter le droit de création. Les jetons GameAP sont limités par portée. Un jeton sans admin:server:create liste parfaitement les serveurs mais ne peut ni les créer ni les supprimer. Mieux vaut le savoir avant votre première commande, car un jeton correctement limité mais mal choisi paraît sain jusqu’au moment précis où un client paie. Provibr vérifie le droit de création lors du test de connexion, pas à la première commande.

La suppression dépend de ce même droit. Il n’existe aucune portée server:delete dans GameAP. Nous avons mesuré une suppression réussie avec un jeton ne portant que admin:server:create et les portées serveur ordinaires. Un seul jeton couvre tout le cycle de vie.

Le jeton a la forme id|secret. C’est la forme Laravel Sanctum : un identifiant numérique, une barre verticale et un secret de 48 caractères. Provibr conserve cette forme et refuse un jeton collé sans l’identifiant devant : c’est une véritable erreur de copie, et l’attraper là vaut mieux qu’une 401 déroutante plus loin.

Il n’expire pas. La table personal_access_tokens de GameAP n’a pas de colonne expires_at. C’est le justificatif de longue durée le plus propre de tous les panneaux que nous avons intégrés : l’agent continue de fonctionner pendant des mois sans que personne ne ressaisisse quoi que ce soit. Comparez avec les panneaux où le secret est un mot de passe et où chaque rotation devient un ticket de support.

Une note pratique : GameAP affiche le jeton une seule fois et n’en conserve ensuite qu’une empreinte. Copiez-le immédiatement. Provibr ne le stocke pas non plus, renvoyer les identifiants signifie donc créer un nouveau jeton.

Étape 2 : le transport, en toute franchise

Une installation GameAP par défaut sert du HTTP simple sur le port 8025, le port 443 étant fermé. Le formulaire d’identifiants ne comporte pas de champ pour une empreinte TLS, car sans TLS il n’y a pas de certificat à épingler.

Cela fonctionne. Cela signifie aussi que le jeton d’API, et tout ce que fait l’intégration, circule en clair. Si cela vous importe (et sur un panneau qui héberge les serveurs de vos clients, cela devrait sans doute), placez devant un reverse proxy avec TLS. L’agent valide alors la chaîne de certificats normalement, sans épinglage.

Étape 3 : le forfait, et pourquoi il n’y a pas de liste

Un serveur GameAP se construit à partir d’un jeu (un titre tel que samp ou minecraft) et d’un game mod, son modèle. Ensemble, ils correspondent à peu près à ce qu’est un egg chez Pterodactyl.

Voici la différence la plus nette avec tous les autres panneaux de jeu que nous prenons en charge : Provibr ne peut pas les lister pour vous. Avec un jeton d’agent limité par portée, /api/games, /api/game_mods et /api/nodes renvoient tous les trois une 403. La lecture du catalogue dépend du rôle administrateur, et aucun droit de jeton ne la débloque.

Il n’y a donc pas de liste déroulante. Vous ouvrez votre propre panneau GameAP, relevez le code du jeu et l’identifiant du mod, puis les saisissez dans le forfait. Un forfait de jeu porte ensuite ce code, cet identifiant de mod et les limites de ressources, et la commande est pilotée par le forfait à partir de là.

C’est plus de saisie qu’une liste. C’est aussi la forme honnête : une liste que nous ne pourrions pas remplir serait pire qu’un champ qui dit ce qu’il attend.

Étape 4 : placement et ports

Deux conséquences découlent de cette même 403.

Le nœud vient d’un réglage, pas du moteur de placement. Provibr classe les nœuds selon la capacité libre quand il le peut. Pas ici, car la liste des nœuds est totalement illisible. L’intégration porte à la place un identifiant de nœud, qui vaut 1 sur un panneau à un seul nœud. Sur un panneau à plusieurs nœuds, un serveur atterrit sur celui que vous avez désigné, et rien n’est classé.

Les ports viennent d’une plage que vous définissez. GameAP n’a pas de système d’allocation : rien ne distribue de port libre. L’agent choisit lui-même un ensemble de ports libres (jeu, requête et RCON) dans une plage que vous réglez sur l’intégration.

Ce que fait réellement une commande

C’est là que GameAP s’écarte le plus d’un panneau comme Pterodactyl, et là qu’une intégration naïve se trompe.

1. 01POST /api/servers écrit l’enregistrement en base. Il n’installe rien.
2. 02Un second appel lance l’installation, que le daemon du panneau exécute comme tâche asynchrone.
3. 03Provibr interroge cette tâche jusqu’à un état final.
4. 04Ensuite le serveur démarre.

La règle décisive : la réponse HTTP d’une action signifie seulement que la tâche est en file d’attente. Pas qu’elle a réussi. Nous avons mesuré un stop revenu en erreur à cause d’une concurrence sur l’hôte : chaque serveur de jeu tourne comme une unité systemd sur le nœud, et systemctl stop peut perdre une course contre lui-même. Le résultat de la tâche est la vérité ; la réponse HTTP est un accusé de réception. Provibr lit la tâche.

Deux autres réalités mesurées à prévoir. Il n’y a ni identifiant externe ni clé d’idempotence, et les noms de serveurs ne sont pas uniques : nous avons créé deux serveurs du même nom et obtenu deux 201 avec des identifiants différents. L’identifiant renvoyé par l’appel de création est la seule identité qui existe, une création rejouée produit donc silencieusement un doublon. Et l’environnement d’installation n’est pas partout complet : une installation de TeamSpeak 3 sur un panneau standard a échoué faute de lbzip2 pour extraire le .tar.bz2, alors qu’une installation SA-MP sur la même machine s’est déroulée proprement. Attendez-vous à ce que « l’installation marche pour un jeu et pas pour l’autre » devienne une catégorie de support.

La suspension : à lire avant de compter dessus

Lorsque Provibr suspend un serveur de jeu (pour faire respecter une limite de capacité), il arrête le serveur et le marque bloqué dans le panneau.

Les deux moitiés sont nécessaires, et voici pourquoi : le drapeau blocked de GameAP n’applique rien. Nous avons mis blocked sur un serveur SA-MP en fonctionnement et il est resté en ligne, répondant aux requêtes de jeu en direct. Nous avons ensuite envoyé un démarrage à un serveur bloqué et obtenu une tâche tout à fait normale. Le drapeau est administratif.

Provibr arrête donc le serveur pour faire réellement respecter la limite. Mais quiconque a un accès direct au panneau GameAP peut le redémarrer. Le blocage est autant une notion Provibr qu’une notion du panneau, et nous préférons l’écrire plutôt que vous laisser le découvrir lors de votre premier dépassement.

Ce que Provibr ne fait pas ici

Pas de console. GameAP en possède une, via un WebSocket. Mais elle repose sur un jeton éphémère distinct issu de sa propre étape d’authentification et sur son propre protocole de trames, un chemin différent du tunnel que notre agent partage avec les autres panneaux de jeu. C’est un vrai travail, pas un interrupteur. Activer l’onglet avant que ce travail existe promettrait un tunnel absent.

Pas de graphiques d’utilisation. GameAP ne remonte, par serveur, ni processeur, ni mémoire, ni disque, ni réseau. Il n’y a pas de point d’accès. Un graphique bloqué à zéro ressemble à une mesure, et « aucune mesure » et « aucune utilisation » ne sont pas la même chose : nous n’affichons donc rien.

Pas de gestion du panneau. Les nœuds, les fichiers, les utilisateurs et le panneau lui-même restent les vôtres. Ce dont l’intégration s’occupe, c’est un serveur de jeu sur le panneau.

Ce que cela change pour un petit hébergeur

Quand on exploite GameAP, le choix est généralement présenté ainsi : « gardez votre panneau et facturez à la main » ou « passez à quelque chose qu’un système de facturation parle déjà ». C’est un faux choix, et un choix coûteux : migrer un panneau plein de serveurs de jeu en production n’est pas l’affaire d’un week-end.

Provibr se connecte à des panneaux de contrôle, des hyperviseurs et des panneaux de jeu côte à côte. Vous n’avez pas à choisir. Gardez GameAP pour les jeux que vous hébergez déjà, ajoutez à côté ce dont vous avez besoin, et faites tourner la commande, le décompte de capacité et la suspension pour impayé sur l’ensemble depuis un seul endroit.