Scegliere un pannello di gioco dall’API che automatizza

Quasi tutti i confronti tra pannelli per server di gioco sono scritti per chi passerà il tempo a cliccare dentro un pannello. Se ha intenzione di vendere server di gioco, quella persona non è Lei. Il pannello lo vedrà all’incirca due volte l’anno, mentre il suo sistema di fatturazione lo vedrà ogni pochi minuti, per sempre.

Il confronto utile è quindi un altro: che cosa permette di fare l’API, che cosa si rifiuta di dirle, e quale delle promesse dell’interfaccia il pannello applica davvero quando un cliente smette di pagare.

Tutto quanto segue è stato misurato costruendo integrazioni contro Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 e MCSManager 10.18.2, nell’agosto 2026.

Un pannello manca dalla tabella di proposito. AMP non c’è perché non lo abbiamo misurato. È un prodotto ragionevole con un’API vera, e scrivere una riga di confronto a partire dalla sua documentazione anziché dalle sue risposte sarebbe esattamente il tipo di riempitivo dal tono sicuro contro cui questo testo argomenta.

Entrare: sei pannelli, cinque modelli di credenziali

Tre di questi richiedono un avvertimento.

Pterodactyl e Pelican hanno bisogno di entrambe le chiavi, e il motivo è strutturale: sull’Application API non esiste alcun endpoint di accensione. Un’integrazione configurata con la sola chiave applicativa può creare server che il suo proprietario non riesce ad avviare.

Pelican accetta una chiave client sull’Application API. GET /api/application/servers, /nodes e /users rispondono tutti 200 con la chiave sbagliata, e l’errore emerge solo su una scrittura, come errore di validazione su un campo utente mancante. Pterodactyl risponde 403 alla stessa richiesta. Su Pelican, controllare il prefisso della chiave è l’unico modo per intercettare una coppia scambiata prima che diventi un guasto incomprensibile in fase di provisioning. Su WISP, che non ha alcun prefisso, non c’è modo di intercettarlo.

MCSManager viene distribuito con l’API disattivata. Un’installazione nuova ha enableApiKey a false e, finché qualcuno non lo attiva, ogni chiamata restituisce 403 «Insufficient Permissions», comprese le chiamate fatte con una chiave valida appartenente a un amministratore valido. È un ticket di supporto il primo giorno per chiunque non sappia dove guardare. Già che ci siamo: MCSManager applica anche un limite di otto richieste al secondo per cookie di sessione, quindi un client che conserva i cookie viene rallentato dove un client che li scarta non lo è.

La domanda che decide: la sospensione fa qualcosa?

A ognuno di questi pannelli si può chiedere di sospendere un server. Non è quella la domanda. La domanda è se un cliente che ha ancora le credenziali del pannello possa annullarla.

I tre pannelli della famiglia Pterodactyl hanno una primitiva vera e non c’è nulla da discutere.

MCSManager è la sorpresa. Nemmeno lui ha un endpoint di sospensione, ma ha una scadenza: porti la data di fine di un’istanza nel passato e il daemon si rifiuta di avviarla. L’abbiamo verificato contro il pannello e non contro la nostra stessa protezione, con una richiesta grezza, e abbiamo ottenuto 500 Instance expired. Unable to start the instance. Quella è applicazione della regola. Due avvertenze: deve anche terminare l’istanza, perché altrimenti un server in esecuzione continua a girare finché il controllo orario della scadenza non lo intercetta, fino a sessanta minuti dopo. E se un cliente aveva impostato una propria data di scadenza, tocca a Lei rimetterla alla riattivazione; il nostro, per ora, non lo fa.

PufferPanel non ha nulla. Non c’è alcun endpoint di sospensione né alcuna colonna di sospensione nel suo modello dati; il vocabolario di stato è running e installing. L’azione migliore disponibile è fermare il server e terminarlo se non si ferma. Un cliente con accesso al pannello può premere avvia.

GameAP ha un flag che non fa nulla. Esiste un campo blocked, e impostarlo è solo un fatto amministrativo. Lo abbiamo impostato su un server SA-MP in esecuzione e il server è rimasto online, rispondendo a query di gioco reali, e in seguito è stato possibile riavviarlo dal pannello.

Questa distinzione vale la pena costruirla nel proprio modello dati anziché smussarla. Sui due pannelli che non la applicano, la descrizione onesta di ciò che è accaduto è «il server è stato fermato e bloccato nel pannello, ma un accesso diretto può riavviarlo», e questo appartiene al record di audit dell’azione. Registrare sei pannelli come «sospeso» quando due di essi si limitano a desiderarlo è il modo in cui un sistema di fatturazione smette di incassare in silenzio.

Creare un server: quattro forme diverse

Qui non c’è alcun terreno comune. Quattro di questi pannelli modellano un server di gioco in modo radicalmente diverso, e la forma della chiamata di creazione ne consegue.

Pterodactyl e Pelican vogliono tutto in una volta. Nome, proprietario, egg, immagine docker, comando di avvio, l’intero insieme delle variabili d’ambiente comprese quelle che il cliente non vede mai, limits, feature_limits e un’allocazione. Non esiste una creazione parziale; un campo mancante è un rifiuto per campo. Un valore che vale la pena conoscere: limits.io è validato between:10,1000, quindi inviare 0 per «illimitato» è un 422 su un campo di cui nessun cliente sentirà mai parlare. Pelican ha invertito quella regola: lì 0 va bene e omettere il campo è l’errore.

PufferPanel è rovesciato. L’identificatore del server lo conia Lei, otto caratteri, poi esegue un PUT dell’intera definizione del template in linea, perché l’elenco dei template non porta con sé le variabili. Creare non installa: quella è una seconda chiamata. E per eliminare bisogna prima fermare, altrimenti si ottiene un 500.

GameAP crea una riga di database e nient’altro. POST /api/servers le dà un server con installed: 0; l’installazione è una seconda chiamata il cui esito finisce in un task del daemon anziché nella risposta HTTP, quindi si interroga. Non c’è un ID esterno né una chiave di idempotenza, e i nomi non sono unici: messe insieme, queste cose significano che una creazione ritentata produce un duplicato in silenzio. L’ID restituito è l’unica identità che ottiene, quindi lo memorizzi prima che possa andare storto qualcos’altro.

MCSManager non ha alcun concetto di template. Un’istanza è un comando di avvio, e l’astrazione finisce lì. Esiste un elenco di preset di installazione rapida, sessantatré, ma nessuno porta un ID: il pannello confronta titolo più descrizione, cinquanta dei sessantatré titoli non sono unici, e i valori dipendono dalla lingua. Qualunque cosa vi si basi si rompe quando il cliente cambia la lingua del pannello.

Che cosa si può vedere dopo

Due voci sono peggiori di quanto sembrino. GameAP risponde 403 su /api/nodes a un token API, quindi un motore di collocazione non può vedere affatto la capacità e va istruito su dove mettere le cose. E il dato del disco di MCSManager non è semplicemente inaffidabile: il campo è dichiarato a zero nel daemon e non viene mai assegnato, quindi è sempre zero, su ogni istanza, per sempre.

L’endpoint /resources di Pterodactyl mette in cache per venti secondi, il che conta più di quanto sembri: se interroga più in fretta ottiene indietro gli stessi byte, e un calcolo ingenuo del traffico di rete trasforma contatori identici in un calo che non è mai avvenuto. Pelican ha ereditato lo stesso comportamento. WISP non lo mette in cache, ma WISP non ha il campo uptime, che è proprio il campo con cui distinguere una lettura fresca da una ripetuta.

Come scegliere davvero

• Le servono una sospensione applicabile e un’API vera. Pterodactyl, oppure Pelican se preferisce il fork sviluppato attivamente. È la risposta noiosa e corretta per quasi tutti quelli che vendono game hosting.
• Vuole hosting senza Docker su macchine piccole. MCSManager, e si adatta meglio di quanto la sua reputazione suggerisca, perché la scadenza le dà un’applicazione reale della regola. Accetti che avrà due metriche di utilizzo e nessuna integrazione della console.
• Fa già girare PufferPanel o GameAP. Va bene, ma costruisca la sospensione al di sopra: è la piattaforma a dover bloccare l’accesso al pannello, perché il pannello non lo farà.
• Sta scegliendo oggi, senza eredità. L’API del pannello sarà il vincolo della sua automazione per anni, e due di questi sei non sanno applicare l’unica operazione da cui il suo sistema di fatturazione dipende di più.

Che cosa non è misurato qui

AMP, come detto sopra. Le versioni di Pterodactyl precedenti alla 1.11, su un pannello dove questo è esattamente il tipo di comportamento che si sposta nelle release minori. I rate limit di Pterodactyl e Pelican, che per essere stabiliti onestamente richiederebbero centinaia di richieste contro un pannello vivo. MCSManager con Docker attivo, dove dovrebbero esistere più metriche ma dove non abbiamo mai visto un campo popolato. E il GameAP classico in PHP, dato che il pannello che abbiamo misurato è la riscrittura in Go, che differisce almeno nel livello di autenticazione.

Provibr integra tutti e sei questi pannelli attraverso un agente che gira dentro la sua rete; le note di configurazione sono sotto Pterodactyl, Pelican, PufferPanel, GameAP e MCSManager.