Minecraft bots you run rather than rent, for Java and Bedrock. A desktop client, a headless daemon, a hub that manages both, and a proxy for your own client, built on a from-scratch Minecraft protocol stack, where your account credentials stay sealed under your own password.
The site is still in development and not publicly available yet. It will live at mcbot.nick22985.com.
One Rust workspace, run three different ways, plus a proxy beside it
A daemon with a window attached. It links the same supervisor and worker crates the headless daemon runs, so enrollment, the hub link and the key schedule have exactly one implementation. Ships on Windows, macOS and Linux.
Runs on a VPS, a home server, or inside Kubernetes with no display server at all. A supervisor holds the hub link and spawns one worker process per owner; workers are where bots actually live.
Where bots are created, assigned to daemons, watched live and driven by hand. A separate realtime process carries socket.io for browsers and a raw websocket server for daemons on a single port, with a Postgres-elected leader so it survives losing a replica.
Puts your own Minecraft client through mcbot. It runs as a sidecar the desktop app starts, or as a hosted gateway that accepts public traffic while holding no refresh token, credential key or database credential.
Bot hosting, hands-on control, packet tools and my own protocol stack
Two editions, three transports, and a lab that tests how far each release gets
Native TCP, from the pre-netty legacy wire through modern configuration-phase protocols. Packet ids and registries are generated per version from Mojang's own reports.
My own RakNet: connection setup, reliability, ordering and splitting. Packet tables come from Mojang's bedrock-protocol-docs, sign-in from the Xbox Live and PlayFab chain.
HTTP signaling into WebRTC data channels driven by str0m. Opted into per bot, advertised separately, and never silently falls back to RakNet.
Roughly ninety releases, each booted from Mojang's own server download. A release claims the highest rung it held, and the first rung that fails ends the climb. A decode failure can be minimised into a byte fixture that replays in the normal test gate with no JVM.
Daemons dial out and hold the connection open, because a hub that reaches inward only works in a cluster
The high-volume path, and the only droppable one:
A dedicated crate encodes the architecture as tests:
Enforced in code and tests, not written down as intent
Daemons run behind home NAT and on VPS firewalls nobody else controls, so nothing in the hub may open a connection towards one. The wire protocol has no message that asks for it and no field a daemon could advertise an address in.
The hub resolves ownership from the caller's token; nothing a daemon or a request sends can name an owner. Every query touching a bot-scoped table carries an owner predicate in the SQL, and a test enforces the shape.
The process holding the hub link and every owner's ciphertext links no Minecraft protocol code, so it is never the one decoding bytes from an arbitrary third-party server. A worker, in turn, cannot reach the hub.
What is stored is an OAuth refresh token, sealed under your own password and rotated on every use. You can revoke it from your Microsoft account without changing your password and without my cooperation.
Shared daemons refuse private and loopback server addresses, so a bot running on hardware I host can only be pointed at public Minecraft servers.
The runner is a separate artifact that nothing in the workspace depends on, enforced by the architecture tests. An operator installs it by path and checksum, and the daemon refuses to exec it on a mismatch.
Only you can decrypt the credential. The bot runs while you are there to unlock it, and nothing on any machine but yours can start it.
Your own daemon holds a wrapped key, so your bot keeps running without you. The hosted side still cannot read it.
A daemon I run holds the wrapped key so the bot survives your machine being off. The most convenient option, and the one that trusts me the most. You have to opt in.
A Rust workspace, a Tauri shell, and a TanStack Start hub
mcbot is in active development. The hub is not open to sign-ups yet, and Bedrock and the hosted proxy stay marked experimental until the lab and a recorded real-client run both pass.