mcbot - minecraft bots you run rather than rent, for java and bedrock: a tauri desktop client, a headless rust daemon, a hub that manages both, and a java proxy for your own client, all on my own from-scratch protocol stack

mcbot is a self-hostable Minecraft bot platform built from one Rust workspace. The same supervisor and worker crates run as a headless daemon on a VPS, as a hosted daemon in Kubernetes, and inside a Tauri 2 desktop app that is just a daemon with a window. Enrollment, the hub link and the key schedule each have one implementation. Daemons always dial out to the hub, because real ones sit behind home NAT and firewalls I don't control. I wrote the protocol stack myself, with no third-party Minecraft crate. Java runs from the pre-netty 1.4 wire to 26.x, with the protocol version passed as a parameter instead of a compile flag. Bedrock is experimental. It has its own RakNet and NetherNet (WebRTC) transports, packet tables generated from Mojang's protocol docs, and the Xbox Live and PlayFab sign-in chain. A compatibility lab boots real servers from Mojang's downloads and records how far each release climbs an eight-rung ladder, from a status ping to decoded chunks. In the browser, owners can move a bot, use a vanilla-layout inventory with drag and drop, answer server dialogs and forms, and decode, edit and resend packets from the log. A Java proxy, as a desktop sidecar or hosted gateway, gives an ordinary Minecraft client the same capture, rules and injection tools. A separately installed runner adds navigation and repeatable multi-bot test scenarios. An MCP adapter lets AI agents control bots through the same owner-authorized operations the UI uses. The hub is a TanStack Start app on Postgres with organizations, per-org entitlements and a highly available realtime process. It never sees a Minecraft or Microsoft password. Users sign in with Microsoft directly, and the hub keeps a sealed, rotating refresh token they can revoke without me. It's still in development, and the hosted hub at mcbot.nick22985.com isn't public yet.

The Minecraft stack is mine

No azalea, no valence, no third-party NBT crate. mc-proto implements Java's varints, framing, compression, encryption, NBT and packets, down to the pre-netty legacy wire; mc-world holds chunks, palettes and registries; mc-physics produces movement a server will accept; mc exposes an edition-agnostic session facade. Packet ids and registry data are generated per version from Mojang's own reports, so a new game version is a table rather than a fork. The same reports produce JSON packet schemas the browser uses to decode, edit and resend packets for every protocol from 1.14.4 on.

Bedrock, transport up

mc-raknet implements RakNet over UDP: connection setup, reliability, ordering and splitting. mc-nethernet implements NetherNet's HTTP signaling and drives WebRTC data channels through str0m. mc-bedrock generates its packet tables from Mojang's bedrock-protocol-docs releases, and sign-in walks the Microsoft, Xbox Live, PlayFab and franchise services with a fresh P-384 identity per session. Inventory gestures go out as ItemStackRequest and settle on ItemStackResponse. It is marked experimental until the lab and a recorded account canary both pass on the same build.

Evidence, not claims

The compatibility lab boots each of roughly ninety releases from Mojang's own server downloads and climbs an eight-rung ladder: status ping, login, keepalive, chat, movement, inventory, and decoded world chunks. A failed rung names itself, and a decode failure can be minimised into a byte fixture that replays in the ordinary test gate with no JVM.

The dependency graph is the architecture

A dedicated arch crate encodes the whole crate graph as tests and fails the build on any edge not in it. The supervisor daemon links no protocol code, so the process holding every owner's ciphertext is never the one parsing bytes from arbitrary third-party servers, and a worker cannot reach the hub. The automation runner is a workspace member nothing depends on, so it can never ship inside the daemon or desktop app by accident.

Tenancy and the key schedule

Every daemon holds a hub-issued token with a tenancy claim. Daemons I run are Shared, and daemons a user runs are SingleOwner. Assignment is enforced in the hub, never delegated to the daemon, and nothing in the wire protocol lets a daemon name an owner. Credentials are sealed under the user's own password; the daemon-wrapped key is what makes always-on possible. Shared daemons also refuse private and loopback server addresses, so a hosted bot can't be pointed back at my network.

One control plane, two front doors

The hub's own controls and the MCP adapter call the same owner-authorized operations, with the same capabilities, control leases and result semantics. The adapter adds a JSON-RPC transport and a tool schema and nothing else; a tool with no hub counterpart is treated as a bug. Commands are intents, not packets, so a hub a second behind cannot desync a bot.

• •Desktop client (Tauri 2 + React) that runs bots locally with a GUI
• •Headless daemon for a VPS, home server, or hosted Kubernetes
• •Web hub for creating bots, assigning them to daemons, and watching them live
• •Java Edition from 1.4.6 to 26.x, plus experimental Bedrock over RakNet and NetherNet
• •Microsoft device-code and PKCE sign-in, so no Minecraft password is ever typed into the app
• •Per-bot credential posture: attended, always-on self-hosted, or always-on hosted
• •Browser controls: movement, look, use and attack, a vanilla-layout inventory with drag and drop, server dialogs and Bedrock forms, and the tab list
• •Packet log with a schema-driven decoder and field editor, resend, saved rule sets, and live rule hit counts
• •Java proxy as a desktop sidecar or hosted gateway, with private packet captures, intercept rules and injection
• •Optional automation runner for navigation and versioned multi-bot test scenarios with assertions and run comparisons
• •MCP adapter exposing the hub's bot controls to AI agents under scoped, owner-granted permissions
• •Organizations with per-org entitlements and limits
• •Config-driven bot behaviours (anti-AFK, chat responder, low-health alerts) validated against typed parameter descriptors
• •Scrubbed per-bot fault reports streamed from daemons to the hub
• •Compatibility lab that grades every release against a real server, plus fixture replay in the normal test gate
• •Public HTTP API for acting on behalf of a user, used by a companion Discord bot

• •Writing the Minecraft protocol from scratch for both editions, with the protocol version threaded through as a parameter so roughly ninety Java releases, from the pre-netty 1.4 wire to 26.x, share one implementation
• •Writing Bedrock's transports myself, both RakNet over UDP with reliability, ordering and splitting, and NetherNet's signaling and WebRTC data channels
• •Proving compatibility with a lab that boots real servers from Mojang's own downloads and grades each release on an eight-rung ladder
• •Designing a multi-tenant trust model where a daemon I host runs many owners' bots while a daemon a user runs is assigned nothing but their own, enforced hub-side at assignment time
• •Sealing credentials so how much can be decrypted is the user's choice per bot: attended, always-on self-hosted, or always-on hosted, with one key schedule behind all three
• •Running a hosted proxy gateway that accepts untrusted public Minecraft traffic while owning no refresh token, credential key or database credential
• •Giving AI agents bot control through MCP without a second permission model, so every tool maps to an operation and interaction the hub already has
• •Keeping the hub from ever dialling a daemon, since daemons run behind home NAT and on VPS firewalls outside my control

frontend

React 19, TanStack Start, Tauri 2, Tailwind CSS, CodeMirror, Three.js

backend

Rust, Tokio, Bun realtime process, better-auth, socket.io + raw WebSockets, MCP (JSON-RPC)

database

PostgreSQL, Redis, SQLite, Drizzle ORM

tools

Docker, Kubernetes, Caddy, pm2, str0m (WebRTC), rustls, argon2 / ChaCha20-Poly1305 / X25519 / P-384

In development. The repository stays private until it's ready. Role: author.

scrnly(1), mana-stats(1), scalelink(1)