Cómo vender alojamiento de Minecraft con MCSManager

El alojamiento de Minecraft es donde empiezan la mayoría de los negocios de alojamiento de juegos, y con razón: la demanda es constante, los clientes son pacientes con los proveedores pequeños, y la barrera técnica hasta el primer cliente de pago es realmente baja. El panel con el que se empieza suele ser el que corría en el hardware que se tenía.

MCSManager es en el que aterriza mucha gente. Es de código abierto, es pequeño, abarca varias máquinas, y (la propiedad que lo decide para muchos) no requiere Docker. Ese solo hecho lo pone en hardware donde la familia Pterodactyl es poco práctica, y vale la pena entender por qué antes de construir un negocio sobre él.

Qué es realmente MCSManager

Dos piezas, en la forma ya estándar: un panel web y un demonio. El panel es la interfaz y el lugar donde ocurre la administración entre nodos; el demonio se ejecuta en cada máquina y es lo que realmente inicia, detiene y supervisa los procesos. Un panel puede hablar con muchos demonios, así que crecer consiste en añadir una máquina en lugar de levantar un segundo panel.

Está escrito en TypeScript (Node.js y Vue en la interfaz, Node.js en los demonios), lo que lo hace ligero de ejecutar y fácil de leer si alguna vez se necesita saber exactamente qué hace. Alrededor de 4800 estrellas en GitHub en el momento de escribir esto, en desarrollo activo, y traducido a varios idiomas.

El ámbito es Minecraft primero, con los títulos basados en Steam a su lado: Palworld, Terraria, Project Zomboid y el resto de esa familia. Si su catálogo es «Minecraft, más el juego de supervivencia al que todo el mundo juega este año», eso encaja limpiamente con MCSManager.

La cuestión de Docker, y por qué lo decide todo

Pterodactyl y sus descendientes requieren contenedores. Es un diseño defendible (da aislamiento y límites de recursos gratis), pero también fija un suelo sobre dónde se puede ejecutar.

MCSManager admite Docker y no lo impone. Los servidores pueden ejecutarse como procesos simples gestionados por el demonio. Tres consecuencias prácticas:

• Se ejecuta en hardware barato y torpe. Un VPS pequeño donde los contenedores anidados resultan molestos, una máquina OpenVZ o LXC, un equipo reaprovechado en una oficina: MCSManager funcionará ahí.
• Se ejecuta en Windows. Para un aficionado que se convierte en empresa, eso suele ser lo que hay realmente disponible.
• La contrapartida es el aislamiento. Sin contenedores, «el servidor de este cliente se comió toda la memoria» no es automáticamente el problema de otro, contenido en otra parte. El aislamiento y los límites que se quieran, se organizan por cuenta propia: cgroups, usuarios separados, máquinas separadas, o activar Docker de todos modos.

Ese último punto es en el que hay que pensar antes del décimo cliente en lugar de después. Ejecutar procesos no aislados para gente que ha pagado va muy bien con tres servidores y es una mala idea con trescientos. El panel dejará hacer las dos cosas.

Autenticación y multiusuario

MCSManager tiene múltiples usuarios y claves de API: se genera una clave por usuario y es la que autentica el acceso programático, y el demonio tiene su propia clave como único medio de autenticar un panel ante él.

Vale la pena ser claro sobre para qué sirve ese modelo: los usuarios de MCSManager son personas que operan servidores. No son clientes con suscripción. No hay ningún plan asociado a un usuario, ni vencimiento, ni precio, ni factura, ni nada que diga que un usuario ha dejado de pagar. Si da a cada cliente un acceso al panel, le ha dado una cuenta de operador sobre su infraestructura y está siguiendo en otro lugar completamente distinto quién le debe dinero.

Eso no es un defecto. Es igual en todos los paneles de juego, incluidos aquellos por los que la gente paga dinero. Es simplemente la línea donde el panel se detiene y empieza su negocio.

Lo que vender exige realmente

El panel da la mitad de máquina: crear un servidor, iniciarlo, detenerlo, reiniciarlo, llegar a una consola, eliminarlo. La mitad comercial es enteramente para construir o comprar:

• Un formulario de pedido y un catálogo, con planes que signifiquen algo en memoria, plazas o almacenamiento.
• Un pago que aprovisione en segundos. En el alojamiento de juegos esto no es un lujo: el cliente suele estar sentado con amigos esperando para unirse, y un retraso de aprovisionamiento medido en minutos es la forma de perderlo.
• Un camino de reclamación de pagos: vencido, avisado, suspendido, restablecido. La suspensión importa más aquí que en el alojamiento web, porque un servidor de juego dejado en marcha consume memoria de forma continua para alguien que ha dejado de pagar.
• Una capacidad que se pueda ver, para saber qué se está soportando en todos esos demonios antes de que lo diga la factura de alojamiento.
• Un registro de auditoría, para que «quién eliminó ese mundo» tenga respuesta. En el alojamiento de Minecraft en concreto, esa pregunta se hace, y la respuesta tiene que ser mejor que un encogimiento de hombros.
• Un modelo de permisos para su personal, para que un voluntario de soporte pueda reiniciar un servidor sin poder eliminar uno.

La mayoría de los pequeños proveedores de alojamiento de Minecraft ejecutan esta mitad sobre una hoja de cálculo, un enlace de pago y mucha buena voluntad. Eso funciona hasta que deja de hacerlo, y el fallo rara vez es espectacular: es una acumulación lenta de servidores que nadie paga, reembolsos que no se pueden reconstruir, y una noche al mes dedicada a cuadrar las cuentas a mano.

Una nota práctica sobre el propio proyecto

MCSManager tiene su origen en la comunidad de habla china y ahí sigue estando su centro de gravedad. El panel está correctamente internacionalizado y existe documentación en inglés, pero cuando se busca una respuesta profunda (un caso límite en el protocolo del demonio, un despliegue inusual), el material más rico y las respuestas más rápidas de la comunidad están a menudo en chino. La traducción automática lo resuelve bien. Vale la pena saberlo antes de necesitar soporte a medianoche que descubrirlo entonces.

Dónde encaja Provibr

La compatibilidad con MCSManager está en producción. Un agente dentro de la propia red habla con el panel web por http o https, de modo que ni el panel ni los demonios que hay detrás tienen que dar la cara a internet. Crear, arrancar, detener, reiniciar, suspender y eliminar instancias funciona, y lo que ya está en el panel se puede importar. Alrededor de eso está la capa descrita arriba: planes y capacidad a un precio por unidad, un modelo de permisos para el equipo, un registro de actividad completo, y una API REST y un módulo WHMCS para que aquello con lo que ya se factura pueda pilotarlo.

MCSManager ya reparte una sola instalación entre varios demonios, así que crecer significa añadir una máquina y no un segundo panel. Provibr lee esa lista y coloca el servidor nuevo en la memoria libre; cuando hay más de un demonio y ningún valor por defecto, se niega en lugar de adivinar. Aquí la suspensión es de verdad: MCSManager mantiene abajo por sí mismo una instancia caducada, de modo que un cliente con acceso al panel no puede volver a arrancarla.

Lo que la integración no puede hacer es borrar las carencias del panel. No hay consola, porque la de MCSManager va sobre socket.io, y no hay gráficas de uso, porque el panel no las mide. Tampoco hay reinstalación: MCSManager solo reconstruye a partir de un preajuste y Provibr construye a partir de un comando de arranque. Sin Docker el panel no impone ningún límite, y la integración lo dice en lugar de fingir lo contrario.

Lo que no hará

Gestionar servidores no es gestionar el panel. Instalar MCSManager, actualizarlo, añadir demonios, elegir si usar Docker o no y cuidar de las máquinas de debajo sigue siendo cosa suya. Los mundos, los plugins, los mods y las copias de seguridad se quedan en el panel, donde el proveedor y sus clientes los siguen usando.

El alojamiento de juegos rara vez se queda solo en alojamiento de juegos. Provibr ejecuta hoy sus paneles de control, sus hipervisores y sus paneles de juego en paralelo, bajo un solo inventario, un solo modelo de permisos y un solo registro de actividad. Servidores de Minecraft en un panel, el VPS al que un cliente asciende en otro, y un solo lugar donde puede ver ambos.