We just shipped our first non-Minecraft expansion: Hytale. This release was more than adding a Docker image. We used it as a forcing function to clean up assumptions across API routes, DNS, logs, and frontend options.

What we added

• New Hytale runtime support in provisioning and lifecycle endpoints
• UDP port mapping for Hytale containers (5520/udp)
• Cloudflare DNS records with _hytale._udp SRV support
• Dedicated Hytale options schema in the dashboard
• Public marketing pages for Minecraft Java, Bedrock, and Hytale

The refactor that mattered

Before this change, several paths assumed a binary world: Java vs Bedrock. We replaced that with runtime detection and explicit behavior per game type.

• Provisioning: runtime-aware image behavior and port bindings
• Logs: route selection now supports Java, Bedrock, and Hytale
• DNS: SRV naming is now selected by game protocol needs
• UI: options are schema-driven per runtime instead of hardcoded branches

Minecraft stays the core

We are still Minecraft-first. Java remains the most feature-rich path with the best customization depth, including mods and plugins support directly from the dashboard.

Why this matters long term

This refactor gives us a cleaner path to future game types. Instead of adding one-off conditionals, we can compose runtime-specific behavior where it belongs: provisioning, DNS, logs, and options schemas.

Next steps: keep tightening runtime-specific controls and add richer game-specific docs as support expands.

Related posts

• DNS & Routing: From Traefik UDP to Cloudflare SRV
• On-Demand Provisioning with Dockerode + Fastify