Vender servidores de juego con GameAP

GameAP es un proyecto pequeño. El 21 de agosto de 2026, su repositorio de GitHub tenía 60 estrellas, 9 forks y 2 contribuidores. Vale la pena decirlo en voz alta, porque fija las expectativas: no hay a su alrededor un gran ecosistema de módulos de facturación, scripts de aprovisionamiento e hilos de foro. Si ejecuta GameAP y quiere vender lo que aloja, está prácticamente solo.

Esta página trata de cerrar esa brecha. Provibr se conecta a un panel de GameAP y aprovisiona, controla e importa servidores de juego en él. Todo lo que sigue se midió contra un panel real de GameAP 4.4.2 en lugar de leerse de una lista de funciones, incluidas las partes en las que GameAP se comporta de forma distinta a lo que uno esperaría.

Lo que la integración cubre realmente

Las dos filas de «no» no son descuidos, y las razones están al final.

Paso 1: el token de API

GameAP se autentica con un solo token de API. Sin cliente OAuth2, sin par de claves, sin sesión que mantener viva: un portador, y eso es toda la credencial.

Cuatro cosas importan de él.

Debe crearlo un administrador, y debe llevar la capacidad de creación. Los tokens de GameAP están limitados por alcance. Un token sin admin:server:create puede listar servidores perfectamente, pero no puede crearlos ni eliminarlos. Vale la pena saberlo antes del primer pedido, porque un token bien limitado pero equivocado parece sano hasta el momento preciso en que un cliente paga. Provibr comprueba la capacidad de creación al probar la conexión, no en el primer pedido.

La eliminación depende de esa misma capacidad. No existe ningún alcance server:delete en GameAP. Medimos una eliminación exitosa con un token que solo llevaba admin:server:create más los alcances de servidor ordinarios. Un solo token cubre todo el ciclo de vida.

El token tiene la forma id|secret. Es la forma de Laravel Sanctum: un id numérico, una barra vertical y un secreto de 48 caracteres. Provibr conserva esa forma y rechaza un token pegado sin el id delante: es un error de copia real, y atraparlo ahí vale más que un 401 desconcertante más adelante.

No caduca. La tabla personal_access_tokens de GameAP no tiene columna expires_at. Es la credencial de larga duración más limpia de todos los paneles que hemos integrado: el agente sigue funcionando durante meses sin que nadie vuelva a introducir nada. Compárese con los paneles donde el secreto es una contraseña y cada rotación se convierte en un ticket de soporte.

Una nota práctica: GameAP muestra el token una sola vez y después solo guarda un hash. Conviene copiarlo de inmediato. Provibr tampoco lo almacena, así que reenviar las credenciales significa generar un nuevo token.

Paso 2: el transporte, y ser honesto al respecto

Una instalación de GameAP por defecto sirve HTTP simple en el puerto 8025, con el 443 cerrado. No hay campo de huella TLS en el formulario de credenciales, porque sin TLS no hay ningún certificado que fijar.

Eso funciona. También significa que el token de API, y todo lo que hace la integración, viaja sin cifrar. Si eso importa (y en un panel que aloja los servidores de sus clientes probablemente debería), conviene poner delante un proxy inverso con TLS. El agente valida entonces la cadena de certificados de forma normal, sin fijación.

Paso 3: el plan, y por qué no hay lista

Un servidor de GameAP se construye a partir de un juego (un título como samp o minecraft) y un game mod, que es su plantilla. Juntos son, más o menos, lo que un egg es en Pterodactyl.

He aquí la diferencia más marcada con todos los demás paneles de juego que admitimos: Provibr no puede listarlos en su lugar. Con un token de agente limitado por alcance, /api/games, /api/game_mods y /api/nodes devuelven los tres un 403. La lectura del catálogo está restringida por rol a una sesión de administrador, y ninguna capacidad de token la desbloquea.

Así que no hay lista desplegable. Se abre el propio panel de GameAP, se lee el código del juego y el id del mod, y se escriben en el plan. Un plan de juego lleva entonces ese código de juego, ese id de mod y los límites de recursos, y a partir de ahí el pedido se impulsa por plan.

Es más escritura que una lista. También es la forma honesta: una lista desplegable que no pudiéramos rellenar sería peor que un campo que dice lo que quiere.

Paso 4: colocación y puertos

Dos consecuencias se derivan de ese mismo 403.

El nodo viene de un ajuste, no del motor de colocación. Provibr clasifica los nodos por capacidad libre cuando puede. Aquí no puede, porque no puede leer la lista de nodos en absoluto. En su lugar, la integración lleva un id de nodo, que es 1 en un panel de un solo nodo. En un panel con varios nodos, un servidor aterriza en el nodo que se haya nombrado, y no se clasifica nada.

Los puertos vienen de un rango que se define. GameAP no tiene un sistema de asignación propio: nada reparte un puerto libre. El agente elige un conjunto libre de puertos (juego, consulta y RCON) de un rango que se configura en la integración.

Lo que hace realmente un pedido

Aquí es donde GameAP más se diferencia de un panel como Pterodactyl, y donde una integración ingenua se equivoca.

1. 01POST /api/servers escribe el registro en la base de datos. No instala nada.
2. 02Una segunda llamada inicia la instalación, y el demonio del panel la ejecuta como una tarea asíncrona.
3. 03Provibr sondea esa tarea hasta que alcanza un estado final.
4. 04Después el servidor arranca.

La regla decisiva: la respuesta HTTP de una acción solo significa que la tarea se puso en cola. No significa que haya tenido éxito. Medimos un stop que volvió con un error por una condición de carrera en el host: cada servidor de juego se ejecuta como su propia unidad systemd en el nodo, y systemctl stop puede perder una carrera contra sí mismo. El resultado de la tarea es la verdad; la respuesta HTTP es un acuse de recibo. Provibr lee la tarea.

Dos realidades medidas más que conviene prever. No hay ni id externo ni clave de idempotencia, y los nombres de servidor no son únicos: creamos dos servidores con el mismo nombre y obtuvimos dos 201 con ids diferentes. El id que devuelve la llamada de creación es la única identidad que existe, lo que significa que una creación reintentada produce en silencio un duplicado. Y el entorno de instalación no es uniformemente completo: una instalación de TeamSpeak 3 en un panel estándar falló porque faltaba lbzip2 para la extracción del .tar.bz2, mientras que una instalación de SA-MP en la misma máquina se ejecutó sin problemas. Conviene esperar que «la instalación funciona para un juego y no para otro» sea una categoría de soporte.

La suspensión: leer esto antes de confiar en ella

Cuando Provibr suspende un servidor de juego (para hacer respetar un límite de capacidad), detiene el servidor y lo marca como bloqueado en el panel.

Ambas mitades son necesarias, y he aquí por qué: el indicador blocked de GameAP no impone nada. Pusimos blocked en un servidor SA-MP en funcionamiento y siguió en línea, respondiendo a consultas de juego en directo. Después enviamos un inicio a un servidor bloqueado y obtuvimos una tarea normal. El indicador es administrativo.

Así que Provibr detiene el servidor para hacer respetar realmente el límite. Pero cualquiera con acceso directo al panel de GameAP puede volver a iniciarlo. El bloqueo es tanto un concepto de Provibr como del panel, y preferimos escribirlo a dejar que se descubra durante su primer exceso de capacidad.

Lo que Provibr no hace aquí

Sin consola. GameAP sí tiene una, sobre un websocket, pero funciona con un token efímero distinto que sale de su propio paso de autenticación y con su propio protocolo de tramas, un camino diferente del túnel que nuestro agente comparte con los demás paneles de juego. Es un trabajo real, no un interruptor. Activar la pestaña antes de que ese trabajo exista prometería un túnel que no está ahí.

Sin gráficos de uso. GameAP no reporta, por servidor, ni CPU, ni memoria, ni disco, ni red. No hay endpoint. Un gráfico clavado en cero parece una medición, y «ninguna medición» y «ningún uso» no son la misma cosa, así que no mostramos nada.

Sin gestión del panel. Los nodos, los archivos, los usuarios y el propio panel siguen siendo suyos. Un servidor de juego en el panel es de lo que trata la integración.

Dónde deja esto a un pequeño proveedor

Si GameAP es lo que ejecuta, la elección suele plantearse como «conservar su panel y facturar a mano» o «pasar a algo que un sistema de facturación ya hable». Es una elección falsa, y cara: migrar un panel lleno de servidores de juego en producción no es cosa de un fin de semana.

Provibr se conecta a paneles de control, hipervisores y paneles de juego en paralelo. No hay que elegir uno. Conviene conservar GameAP para los juegos que ya aloja, añadir junto a él lo que necesite después, y ejecutar los pedidos, el recuento de capacidad y la suspensión por impago sobre todos ellos desde un solo lugar.