Add dashboard for monitoring all Minecraft servers and clusters

[danihengeveld]

Summary

Implement a dashboard to provide insightful and clear information about all managed Minecraft servers and clusters. The focus will be on display/monitoring only – no server actions/commands at this stage.

Requirements

• Build a web dashboard using the latest tanstack start RC following React best practices. (use other tanstack components and npm packages where needed)
• Use the latest shadcn/ui library for building UI components with a beautiful and clean look.
• Style the dashboard with the latest Tailwind CSS.
• Only display information about the Minecraft servers and clusters. No controls/commands for now.
• New project in monorepo.
• Pnpm or preferably Bun as package manager
• Dashboard should be published as docker image (follow already existing github actions setup for ci/cd and releasing)
• Deployment of dashboard is configurable in helm chart, when enabled auto deployed and operator will adjust server config where needed

Dashboard Features

• List all Minecraft servers and clusters, displaying:
  • Status (online/offline, ping/latency)
  • Server/cluster details: name, type (standalone/clustered), version, location/region
  • Live metrics: player count, max players, uptime, CPU/RAM/resource usage (if available)
  • Error states, warnings, and recent activity (where possible)
• UI should focus on clarity, usability, and beauty without being overwhelming.

Server/Cluster Information Gathering — Analysis

There are several common approaches to gathering Minecraft server status and telemetry information:

1. Kubernetes API or Internal Resource Polling

   • Directly query the hosting cluster for resources (pods/services) and scrape metadata.
   • Positives: Simple in cloud-native environments, especially for clusters managed via k8s operator.
   • Negatives: Not Minecraft-specific; poor for metrics like player count, TPS, etc.

2. RCON Protocol (Query/Remote Console)

   • Minecraft servers natively support RCON, allowing status/command interface.
   • Can be used to periodically query for server metadata (player count, list, version, TPS, plugins, etc.)
   • Positives: Native, near-realtime, works with vanilla and most modded servers, wide ecosystem support (many npm/go/c# client libs available).
   • Negatives: Requires RCON to be enabled and secured. Since servers are managed via the operator, it is acceptable to require RCON if the user explicitly enables dashboarding (should be optional/configurable in the operator's settings).

3. Server Query Protocol (UDP/Motd)

   • Lightweight protocol for server status (player list/count, MOTD). No deep stats or management access.
   • Positives: Secure (read-only), easy to enable.
   • Negatives: Very limited (won’t provide advanced stats).

4. Metrics Plugins

   • E.g., Plan Player Analytics or Spark
   • Provide dashboards/REST APIs for advanced stats, logs, player history, performance metrics.
   • Positives: Rich server-specific metrics, easy integration.
   • Negatives: Requires installing and maintaining plugins; but can be automated by the operator if needed.

Recommendation

For MVP:

• Use RCON to fetch real-time status (online, player count, version, etc.) and basic statistics from the servers. RCON is widely supported and easy to test.
• Since we manage servers ourselves via the operator, RCON can be required if dashboarding is enabled by the user (should be clearly documented and configurable in the operator).
• Poll for status once per minute while the dashboard is open; do not poll aggressively or when dashboard is closed/inactive.
• Consider supplementing with Server Query Protocol for environments where RCON isn’t enabled, as an optional fallback for minimal status info.
• No telemetry/history storage required—only live status is shown in dashboard; historical analytics can be reconsidered later if needed.

Final Notes

• No authentication required for dashboard (for now).

Next Steps

• Confirm operator RCON configuration UI/flags for dashboard feature enablement
• Finalize supported data fields for display
• Prototype dashboard layout and connection logic

---