A desktop manager for up to 500 headless Cristalix client sessions.
C7xBotManager architecture. A simplified view of real implementation layers; no invented UI screenshot.
C7xBotManager is a desktop tool for operating multiple lightweight Cristalix/Minecraft clients without launching a full game for each account. It handles authentication, session state, proxies and automation through a native manager and a headless Java runtime.
I designed the application architecture, implemented its management tools and optimized networking and automation. The initial research into part of the authentication protocol had outside assistance. The product was distributed through one-time purchases to roughly ten users.
The difficult part was not opening a socket. Each account has its own authentication state, connection, realm, queue, proxy and automation tasks. A bulk operation must not turn them into one global blocking workflow.
The desktop interface lets the operator select accounts or groups and send an action through the local API.
The Java runtime maintains the individual lifecycle of each account. Connection state and current automation are available for diagnostics.
A shared Netty/NIO network runtime handles protocol I/O. The packet pipeline includes proxy handling, encryption, framing and decoding.
Proxy health, quarantine, failover and reconnect policies handle connection errors without restarting the whole application.
The system has been used with up to 500 simultaneous client sessions. That figure describes actual configuration scale, not a synthetic performance benchmark.
The Java side uses a shared NIO runtime rather than starting a full Minecraft process per account. Session initialization builds a Netty pipeline with optional SOCKS/HTTP proxy handlers, encryption, packet sizing and a codec for the supported protocol.
One concrete problem was an interaction between proxied connections and PacketLib’s priority writes. Calling the normal activation path on Netty’s event loop could block while the proxy pipeline was still settling. I moved that activation to a small worker and let Netty queue the writes safely.
The interface is hosted in a native Go application with Win32 window handling and WebView2. It starts and manages a Java backend process and communicates with it through the local API. This keeps protocol and automation logic independent from window rendering.
I also built account-group operations, live logs, diagnostics, an encrypted local account vault and isolated release/build profiles. Windows uses native window and tray integration; portable macOS/Linux builds open the manager UI in a browser.
Connections can use HTTP or SOCKS proxies, with pool health checks and failover. Each account needs a predictable network identity and error handling; a bad endpoint must not silently affect unrelated sessions.
On top of the transport, the runtime implements realm switching, queue processing, navigation and dungeon automation. These features depend on actual server state rather than visual input automation.
The product reached roughly ten paying users and supported configurations with up to 500 active client sessions. I continued developing it as both a networked runtime and a practical desktop tool.
Protocol compatibility also requires ongoing work: packet handling, authentication and state transitions have to be adapted when the external service changes.