Montando un servidor de Hytale cuando la documentación no existe

Hytale se lanzó en acceso anticipado y quise montar un servidor dedicado. La documentación oficial cubría lo básico (descargar, ejecutar, conectar), pero se saltaba la mayoría de detalles prácticos. Tampoco había guías de la comunidad todavía. Así que monté uno, apunté cada paso y automaticé lo que pude.

Esto es cómo fue el proceso.

La sorpresa del protocolo

Lo primero que me pilló fue el protocolo de red. La mayoría de servidores de juegos usan TCP, o TCP más UDP para voz. Hytale usa QUIC sobre el puerto UDP 5520. Si tus reglas de firewall solo permiten TCP, el servidor arranca sin problemas pero nadie puede conectarse. Sin error, sin timeout, solo silencio. Eso me costó más tiempo del que me gustaría admitir.

La autenticación fue el siguiente obstáculo. Los servidores de Hytale requieren credenciales OAuth2 vinculadas a tu cuenta de Hypixel Studios. El proceso tiene dos fases en el navegador (registrar el servidor y autorizarlo) que no se pueden automatizar. Las completas manualmente y luego pegas las credenciales en la configuración del servidor. Es más seguro que el modelo antiguo de Minecraft, pero significa que la automatización completa no es posible.

En la parte de Java: JDK 25 Temurin, que aún no está en los repositorios de la mayoría de distros. Ajuste de G1GC, porque los flags por defecto de la JVM no van bien para servidores de juegos. Y una descarga de 3,2 GB de assets en el primer arranque que la documentación no menciona.

Diez fases de configuración

El script de configuración para Linux (linux/hytale-setup.sh) pasa por diez fases:

1. Preparación del sistema: actualizaciones, fail2ban, configuración de zona horaria
2. Instalación de Java: Temurin JDK 25 a través del repositorio de Adoptium
3. Usuario y directorios: un usuario dedicado hytale-server, archivos en /opt/hytale
4. Descarga del servidor: interactiva, por el requisito de OAuth2
5. Ajuste de JVM: detecta la RAM disponible y configura los tamaños del heap
6. Configuración del servidor: genera config.json, whitelist.json
7. Firewall: reglas UFW para SSH en el puerto 22 y tráfico del juego en 5520/UDP
8. Servicio systemd: arranque automático, reinicio ante fallos, hardening de seguridad
9. Autenticación inicial: el paso /auth login que vincula el servidor a tu cuenta
10. Resumen: muestra los datos de conexión y los siguientes pasos

El equivalente en Windows cubre lo mismo en siete fases, usando PowerShell, Windows Firewall y tareas programadas en lugar de sus contrapartes de Linux. Mismas ideas, herramientas diferentes.

Backup y actualización

El script de configuración pone en marcha el servidor. Los otros cuatro scripts lo mantienen funcionando.

Los scripts de backup (Linux y Windows) crean archivos comprimidos con marca de tiempo del directorio del servidor. Rotan las copias antiguas automáticamente —siete por defecto— y admiten backups en caliente, sin necesidad de parar el servidor. Los scripts de actualización gestionan el ciclo de parar-backup-descargar-reiniciar: apagan el servidor, hacen una copia de seguridad, descargan los archivos más recientes y lo vuelven a arrancar.

Seis scripts en total entre las dos plataformas. Cada uno tiene modo dry-run.

Escribir el tutorial

El archivo del tutorial (HYTALE_SERVER_TUTORIAL.md) acabó en 44 KB repartidos en más de 18 secciones. Escribirlo llevó más tiempo que la configuración en sí.

Empieza con una recomendación de hosting gestionado: 5-20 € al mes, sin necesidad de saber Linux. No todo el mundo debería hacer self-hosting, y el tutorial necesitaba ser claro con eso desde el principio. Para quienes sí quieran hacerlo, hay una tabla de escalado de memoria (2-3 GB para 5-10 jugadores, hasta 22-26 GB para 50-100), un checklist de seguridad y tablas de solución de problemas comunes.

Convertir el historial del terminal en un tutorial significa hacer explícito cada paso implícito. Tienes que recordar qué asumiste, qué te saltaste, qué solo sabías por experiencia. El flujo de OAuth2 fue un buen ejemplo: lo había hecho una vez y había interiorizado los pasos, pero escribirlos reveló cuántos clics y redirecciones había de por medio.

Decisiones de diseño

Algunas cosas que tuve en cuenta al escribir los scripts:

• Modos dry-run en los seis scripts: ver qué cambiaría antes de que nada cambie
• Ejecución idempotente: seguro de reejecutar, se salta pasos ya completados
• Memoria JVM automática: calcula el tamaño del heap a partir de la RAM disponible, de 2 GB a 26 GB
• Multiplataforma: Bash para Linux, PowerShell para Windows, con funcionalidades equivalentes
• Hardening de seguridad: sandboxing de systemd, usuario de servicio dedicado, reglas de firewall mínimas

El quick-start en Linux es un solo comando:

curl -sL https://raw.githubusercontent.com/blugart-dev/hytale-server-toolkit/main/linux/hytale-setup.sh | bash -s -- --dry-run

Quita --dry-run cuando estés listo.

Lo que aprendí

Los juegos nuevos necesitan documentación pronto. Siempre hay una brecha entre que un juego se lanza y que la comunidad tenga guías decentes. Alguien tiene que escribir la primera, y no requiere un conocimiento profundo: solo paciencia y ganas de escribir las cosas.

Una guía y un script se complementan. La guía explica lo que está pasando. El script lo hace repetible. Sirven a audiencias distintas y ninguno reemplaza al otro.

Escribir las cosas te obliga a entenderlas. Sabía lo suficiente para que el servidor funcionara. Escribir el tutorial me hizo darme cuenta de cuántos pasos había hecho en piloto automático sin entender del todo por qué. El flujo de OAuth2 en particular: hay cosas que no se pueden automatizar, y el script tiene que gestionar eso con elegancia, pausándose y diciéndole al usuario qué hacer manualmente.

El toolkit está en GitHub. Lo use alguien o no, entiendo mejor la infraestructura de servidores de Hytale por haberlo escrito.