Elegir un panel de juego por la API que se automatiza

La mayoría de las comparaciones de paneles de servidores de juego están escritas para quien va a hacer clic dentro de uno. Quien vaya a vender servidores de juego no es esa persona. Verá el panel dos veces al año, más o menos, y su sistema de facturación lo verá cada pocos minutos, para siempre.

Así que la comparación útil es otra: ¿qué deja hacer la API, qué se niega a contar, y cuál de las promesas de la interfaz impone el panel de verdad cuando un cliente deja de pagar?

Todo lo que sigue se midió construyendo integraciones contra Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 y MCSManager 10.18.2, en agosto de 2026.

Un panel está deliberadamente fuera de la tabla. AMP no está aquí porque no lo hemos medido. Es un producto razonable y con una API de verdad, y escribir su fila a partir de su documentación en lugar de a partir de sus respuestas sería exactamente el tipo de relleno con aire de certeza contra el que argumenta esta página.

Entrar: seis paneles, cinco modelos de credencial

Tres de ellos necesitan un aviso.

Pterodactyl y Pelican necesitan las dos claves, y la razón es estructural: no hay endpoint de encendido en la Application API. Una integración configurada solo con una clave de aplicación puede crear servidores que su dueño no puede arrancar.

Pelican acepta una clave de cliente en la Application API. GET /api/application/servers, /nodes y /users devuelven todos 200 con la clave equivocada, y el error solo aflora en una escritura, como un fallo de validación sobre un campo de usuario que falta. Pterodactyl responde 403 a la misma petición. En Pelican, comprobar el prefijo de la clave es la única manera de detectar un par intercambiado antes de que se convierta en un fallo confuso a la hora de aprovisionar. En WISP, que no tiene prefijo alguno, no hay manera de detectarlo.

MCSManager se entrega con su API desactivada. Una instalación nueva tiene enableApiKey en falso y, hasta que alguien lo active, cada llamada devuelve 403 «Insufficient Permissions», incluidas las llamadas hechas con una clave válida de un administrador válido. Eso es un ticket de soporte el primer día para cualquiera que no sepa dónde mirar. Ya puestos: MCSManager además limita a ocho peticiones por segundo por cookie de sesión, así que un cliente que conserva las cookies acaba estrangulado donde uno que las descarta no.

La pregunta que lo decide: ¿suspender hace algo?

A todos estos paneles se les puede decir que suspendan un servidor. Esa no es la pregunta. La pregunta es si un cliente que todavía tiene credenciales del panel puede deshacerlo.

Los tres paneles de la familia Pterodactyl tienen una primitiva de verdad y no hay nada que discutir.

MCSManager es la sorpresa. Tampoco tiene un endpoint de suspensión, pero tiene una caducidad: si se pone la fecha de fin de una instancia en el pasado, el demonio se niega a arrancarla. Lo comprobamos contra el panel y no contra nuestro propio control, con una petición cruda, y obtuvimos 500 Instance expired. Unable to start the instance. Eso es imponer. Dos matices: hay que matar también la instancia, porque si no un servidor en marcha sigue en marcha hasta que lo alcanza la comprobación horaria de caducidad, hasta sesenta minutos después. Y si un cliente había puesto su propia fecha de caducidad, es cosa de uno devolverla al reactivar; la nuestra todavía no lo hace.

PufferPanel no tiene nada. No hay endpoint de suspensión ni columna de suspendido en su modelo de datos; el vocabulario de estado es running e installing. La mejor acción disponible es parar el servidor y matarlo si no para. Un cliente con acceso al panel puede pulsar arrancar.

GameAP tiene una bandera que no hace nada. Hay un campo blocked, y activarlo es puramente administrativo. Lo activamos en un servidor SA-MP en marcha y el servidor siguió en línea, respondiendo consultas de juego en vivo, y después se pudo volver a arrancar desde el panel.

Esa distinción merece construirse dentro del modelo de datos propio en lugar de limarse. En los dos paneles que no la imponen, la descripción honesta de lo ocurrido es «el servidor se paró y se bloqueó en el panel, pero un acceso directo puede volver a arrancarlo», y eso pertenece al registro de auditoría de la acción. Anotar seis paneles como «suspendido» cuando dos de ellos solo desearían estarlo es la manera en que un sistema de facturación deja de cobrar en silencio.

Crear un servidor: cuatro formas distintas

Aquí no hay terreno común en absoluto. Cuatro de estos paneles modelan un servidor de juego de una manera radicalmente distinta, y la forma de la llamada de creación va detrás.

Pterodactyl y Pelican lo quieren todo de una vez. Nombre, dueño, egg, imagen docker, comando de arranque, el conjunto completo de variables de entorno incluidas las que el cliente no ve nunca, limits, feature_limits y una asignación. No hay creación parcial; un campo que falta es un rechazo por campo. Un valor que conviene conocer: limits.io se valida between:10,1000, así que enviar 0 para «ilimitado» es un 422 sobre un campo del que ningún cliente oirá hablar jamás. Pelican invirtió esa regla: ahí 0 vale y omitir el campo es el error.

PufferPanel está del revés. El identificador del servidor se acuña uno mismo, ocho caracteres, y después se hace un PUT con la definición completa de la plantilla en línea, porque la lista de plantillas no lleva las variables. Crear no instala: eso es una segunda llamada. Y borrar exige parar antes, o se obtiene un 500.

GameAP crea una fila en la base de datos y nada más. POST /api/servers devuelve un servidor con installed: 0; la instalación es una segunda llamada cuyo desenlace aterriza en una tarea del demonio y no en la respuesta HTTP, así que hay que sondear. No hay identificador externo ni clave de idempotencia, y los nombres no son únicos, lo que en conjunto significa que una creación reintentada produce un duplicado en silencio. El identificador devuelto es la única identidad que se obtiene, así que conviene guardarlo antes de que nada más pueda salir mal.

MCSManager no tiene concepto de plantilla en absoluto. Una instancia es un comando de arranque, y esa es toda la abstracción. Hay una lista de preajustes de instalación rápida, sesenta y tres, pero ninguno lleva identificador: el panel empareja por título más descripción, cincuenta de los sesenta y tres títulos no son únicos, y los valores dependen del idioma. Cualquier cosa indexada por ellos se rompe cuando el cliente cambia el idioma del panel.

Lo que se puede ver después

Dos entradas de ahí son peores de lo que parecen. GameAP devuelve 403 en /api/nodes para un token de API, así que un motor de colocación no puede ver la capacidad en absoluto y hay que decirle dónde poner las cosas. Y la cifra de disco de MCSManager no es solo poco fiable: el campo se declara a cero en el demonio y no se asigna nunca, así que es siempre cero, en cada instancia, para siempre.

El endpoint /resources de Pterodactyl guarda caché durante veinte segundos, lo que importa más de lo que suena: si se sondea más rápido, vuelven los mismos bytes, y un cálculo ingenuo de la tasa de red convierte contadores idénticos en una caída que nunca ocurrió. Pelican heredó el mismo comportamiento. WISP no lo cachea, pero WISP no tiene campo de tiempo activo, que es el campo que serviría para distinguir una lectura fresca de una repetida.

Cómo elegir de verdad

• Hace falta una suspensión que se imponga y una API de verdad. Pterodactyl, o Pelican si se prefiere la bifurcación con desarrollo activo. Esta es la respuesta aburrida y correcta para la mayoría de quienes venden alojamiento de juegos.
• Se busca alojamiento sin Docker en máquinas pequeñas. MCSManager, y encaja mejor de lo que sugiere su fama, porque la caducidad da una imposición real. Hay que aceptar dos métricas de uso y ninguna integración de consola.
• Ya se está ejecutando PufferPanel o GameAP. Bien, pero la suspensión hay que construirla encima: la plataforma tiene que bloquear el acceso al panel, porque el panel no lo hará.
• Se elige hoy y sin herencia. La API del panel va a ser la restricción de la automatización durante años, y dos de estos seis no pueden imponer la única operación de la que más depende un sistema de facturación.

Lo que aquí no está medido

AMP, como ya se ha dicho. Las versiones de Pterodactyl anteriores a la 1.11, en un panel donde este es exactamente el tipo de comportamiento que cambia en versiones menores. Los límites de tasa de Pterodactyl y de Pelican, que exigirían cientos de peticiones contra un panel vivo para establecerlos con honestidad. MCSManager con Docker activado, donde deberían existir más métricas pero donde nunca hemos visto un campo relleno. Y el GameAP clásico en PHP, ya que el panel que medimos es la reescritura en Go, que difiere al menos en su capa de autenticación.

Provibr integra los seis paneles a través de un agente que corre dentro de la red propia; las notas de configuración están en Pterodactyl, Pelican, PufferPanel, GameAP y MCSManager.