Vendere server di gioco con GameAP

GameAP è un piccolo progetto. Il 21 agosto 2026 il suo repository GitHub aveva 60 stelle, 9 fork e 2 contributori. Vale la pena dirlo ad alta voce, perché fissa le aspettative: non c’è un grande ecosistema di moduli di fatturazione, script di provisioning e discussioni sul forum attorno a esso. Se gestisce GameAP e vuole vendere ciò che ospita, è in gran parte da solo.

Questa pagina serve a colmare quel divario. Provibr si collega a un pannello GameAP e vi crea, controlla e importa server di gioco. Tutto ciò che segue è stato misurato su un vero pannello GameAP 4.4.2 anziché copiato da un elenco di funzionalità, comprese le parti in cui GameAP si comporta in modo diverso da come ci si aspetterebbe.

Cosa copre davvero l’integrazione

Le due righe «no» non sono sviste, e le ragioni sono alla fine.

Passaggio 1: il token API

GameAP si autentica con un solo token API. Nessun client OAuth2, nessuna coppia di chiavi, nessuna sessione da mantenere attiva: un bearer, e questa è l’intera credenziale.

Quattro cose contano al riguardo.

Deve essere creato da un amministratore e deve portare il permesso di creazione. I token GameAP hanno un ambito limitato. Un token senza admin:server:create elenca perfettamente i server ma non può crearli né eliminarli. Vale la pena saperlo prima del primo ordine, perché un token con l’ambito impostato ma errato sembra sano fino al momento preciso in cui un cliente paga. Provibr verifica il permesso di creazione al test della connessione, non al primo ordine.

L’eliminazione dipende dallo stesso permesso. In GameAP non esiste alcun ambito server:delete. Abbiamo misurato un’eliminazione riuscita con un token che portava solo admin:server:create più i normali ambiti server. Un solo token copre l’intero ciclo di vita.

Il token ha la forma id|secret. È la forma di Laravel Sanctum: un id numerico, una barra verticale e un secret di 48 caratteri. Provibr mantiene questa forma e rifiuta un token incollato senza l’id davanti: è un vero errore di copia, e intercettarlo è meglio di una 401 sconcertante più avanti.

Non scade. La tabella personal_access_tokens in GameAP non ha una colonna expires_at. È la credenziale a lunga durata più pulita di tutti i pannelli che abbiamo integrato: l’agente continua a funzionare per mesi senza che nessuno reinserisca nulla. Da confrontare con i pannelli in cui il secret è una password e ogni rotazione diventa un ticket di assistenza.

Una nota pratica: GameAP mostra il token una sola volta e in seguito ne conserva solo un hash. Lo copi subito. Nemmeno Provibr lo memorizza, quindi rinviare le credenziali significa generare un nuovo token.

Passaggio 2: il trasporto, con onestà

Un’installazione GameAP predefinita serve semplice HTTP sulla porta 8025, con la 443 chiusa. Nel modulo delle credenziali non c’è un campo per l’impronta TLS, perché senza TLS non c’è alcun certificato da fissare.

Funziona. Significa anche che il token API, e tutto ciò che fa l’integrazione, viaggia non cifrato. Se questo le importa (e su un pannello che ospita i server dei suoi clienti probabilmente dovrebbe), metta davanti un reverse proxy con TLS. L’agente allora convalida la catena di certificati normalmente, senza fissaggio.

Passaggio 3: il piano, e perché non c’è un elenco

Un server GameAP si costruisce da un gioco (un titolo come samp o minecraft) e da un game mod, che è il suo modello. Insieme corrispondono più o meno a ciò che un egg è su Pterodactyl.

Ecco la differenza più netta rispetto a ogni altro pannello di gioco che supportiamo: Provibr non può elencarli al posto suo. Con un token agente ad ambito limitato, /api/games, /api/game_mods e /api/nodes restituiscono tutti e tre una 403. La lettura del catalogo è vincolata al ruolo di una sessione amministratore, e nessun permesso del token la sblocca.

Quindi non c’è alcun elenco a discesa. Apre il suo pannello GameAP, legge il codice del gioco e l’id del mod, e li digita nel piano. Un piano di gioco porta poi quel codice del gioco, quell’id del mod e i limiti di risorse, e l’ordine è guidato dal piano da lì in avanti.

È più digitazione di un elenco. È anche la forma onesta: un elenco a discesa che non potremmo popolare sarebbe peggio di un campo che dice ciò che vuole.

Passaggio 4: posizionamento e porte

Due conseguenze derivano da quella stessa 403.

Il nodo proviene da un’impostazione, non dal motore di posizionamento. Provibr ordina i nodi in base alla capacità libera quando può. Qui non può, perché non riesce affatto a leggere la lista dei nodi. L’integrazione porta invece un id del nodo, che su un pannello a nodo singolo è 1. Su un pannello a più nodi, un server atterra sul nodo che ha indicato, e nulla viene ordinato.

Le porte provengono da un intervallo che imposta lei. GameAP non ha un proprio sistema di allocazione: nulla distribuisce una porta libera. L’agente sceglie un insieme di porte libere (gioco, query e RCON) da un intervallo che configura sull’integrazione.

Cosa fa davvero un ordine

È qui che GameAP si discosta di più da un pannello come Pterodactyl, ed è qui che un’integrazione ingenua sbaglia.

1. 01POST /api/servers scrive il record nel database. Non installa nulla.
2. 02Una seconda chiamata avvia l’installazione, e il daemon del pannello la esegue come attività asincrona.
3. 03Provibr interroga quell’attività finché non raggiunge uno stato finale.
4. 04Poi il server si avvia.

La regola decisiva: la risposta HTTP di un’azione significa solo che l’attività è stata messa in coda. Non significa che sia riuscita. Abbiamo misurato uno stop tornato con un errore per una race condition sull’host: ogni server di gioco gira come una propria unità systemd sul nodo, e systemctl stop può perdere una race contro sé stesso. L’esito dell’attività è la verità; la risposta HTTP è una ricevuta. Provibr legge l’attività.

Altre due realtà misurate su cui vale la pena pianificare. Non esistono né un id esterno né una chiave di idempotenza, e i nomi dei server non sono univoci: abbiamo creato due server con lo stesso nome e ottenuto due 201 con id diversi. L’id restituito dalla chiamata di creazione è l’unica identità che esista, il che significa che una creazione ripetuta produce silenziosamente un duplicato. E l’ambiente di installazione non è ovunque completo: un’installazione di TeamSpeak 3 su un pannello standard è fallita perché mancava lbzip2 per l’estrazione del .tar.bz2, mentre un’installazione SA-MP sulla stessa macchina è filata liscia. Ci si aspetti che «l’installazione funziona per un gioco e non per un altro» diventi una categoria di assistenza.

Sospensione: da leggere prima di farci affidamento

Quando Provibr sospende un server di gioco (per far rispettare un limite di capacità), ferma il server e lo marca come bloccato nel pannello.

Entrambe le metà sono necessarie, ed ecco perché: il flag blocked di GameAP non impone nulla. Abbiamo impostato blocked su un server SA-MP in esecuzione ed è rimasto online, rispondendo a query di gioco in tempo reale. Abbiamo poi inviato un avvio a un server bloccato e ottenuto un’attività del tutto normale. Il flag è amministrativo.

Quindi Provibr ferma il server per far rispettare davvero il limite. Ma chiunque abbia accesso diretto al pannello GameAP può riavviarlo. Il blocco è un concetto di Provibr tanto quanto del pannello, e preferiamo metterlo per iscritto piuttosto che lasciarglielo scoprire durante il suo primo superamento.

Cosa Provibr non fa qui

Nessuna console. GameAP ne ha una, su un websocket. Ma gira con un token separato e a vita breve, ottenuto da un proprio passaggio di autenticazione e con un proprio protocollo di frame, un percorso diverso dal tunnel che il nostro agente condivide con gli altri pannelli di gioco. È lavoro vero, non un interruttore. Attivare la scheda prima che quel lavoro esista prometterebbe un tunnel che non c’è.

Nessun grafico di utilizzo. GameAP non segnala, per singolo server, né CPU, né memoria, né disco, né rete. Non esiste un endpoint. Un grafico bloccato a zero sembra una misurazione, e «nessuna misurazione» e «nessun utilizzo» non sono la stessa cosa, quindi non mostriamo nulla.

Nessuna gestione del pannello. I nodi, i file, gli utenti e il pannello stesso restano suoi. Ciò di cui si occupa l’integrazione è un server di gioco sul pannello.

Cosa comporta questo per un piccolo host

Se è GameAP ciò che gestisce, la scelta tende a essere presentata così: «tenere il proprio pannello e fatturare a mano» oppure «passare a qualcosa che un sistema di fatturazione parli già». È una falsa scelta, e costosa: migrare un pannello pieno di server di gioco in produzione non è un lavoro da un fine settimana.

Provibr si collega a pannelli di controllo, hypervisor e pannelli di gioco fianco a fianco. Non deve sceglierne uno. Mantenga GameAP per i giochi che ospita già, aggiunga accanto ciò che le serve, e gestisca gli ordini, il conteggio della capacità e la sospensione per mancato pagamento su tutti da un unico posto.