Maintainers
Built and maintained in the open
A small core team stewards Craftling across the control plane, the host agent, and storage — alongside everyone who sends a pull request.
Craftling is a control plane for multi-host, Firecracker-microVM Minecraft hosting. Declare the servers you want — a desired-state reconciler schedules them across your host fleet, boots them in hardware-isolated microVMs, and keeps world data durable in object storage.
One reconciler owns every compute side effect. Declare desired state through the API or console; Craftling makes it real and keeps it that way.
Every two seconds, Craftling diffs what you asked for against what's actually running and converges the gap — the single writer of all compute side effects.
Each server boots in its own microVM with a dedicated kernel and rootfs — true hardware-level isolation between tenants, not shared containers.
Worker hosts dial in and hold one gRPC stream open to the control plane — registering, heartbeating, and taking commands on it. Drop the stream and the host is marked down at once; capacity and liveness are always current.
Unplaced servers are assigned to a ready host with room, reserving CPU and memory atomically. Specs too big for any host fail fast as unschedulable.
Worlds live in S3-compatible object storage, pulled into the VM at boot and flushed back via RCON save-all — so a server can safely move between hosts.
Each VM gets a private IP and a published host port — SNAT out, DNAT in — on an eBPF/TCX dataplane riding kernel nf_conntrack. No Linux bridge, no iptables. Every flow emits an event, and per-VM byte, packet, and drop counters are tracked in eBPF maps.
Craftling never executes one-off imperative actions. You change what you want; observed status converges toward it, tick after tick.
Create a server with a version and size, or flip it between running and stopped — through the console or API. That's a write to desired_state, nothing more.
If a running server has no host, the scheduler picks a ready host with capacity and reserves it atomically — or marks it unschedulable and retries.
The control plane pushes the command down the gRPC stream the agent holds open, and the agent boots the Firecracker microVM. The control plane itself never touches KVM — and never dials the agent.
Agents report observed per-VM status back up the same stream, which reconciles into each server's status, tick after tick, until it matches what you asked for.
The control plane decides; host agents act. Neither leaks into the other — which is what makes the fleet safe to scale.
Stateless API + reconciler. HA behind a load balancer; never runs KVM.
Runs on each KVM host. Owns the microVM runtime; reports status up.
Durable record of intent, fleet, and worlds — survives any single node.
A phased path, each milestone anchored to real code and verified end-to-end. The control plane, fleet, scheduler, agent split, Firecracker runtime, an eBPF NAT dataplane, and durable world persistence have shipped — observability, reliability, and quotas are next.
Auth, roles, owner-scoped CRUD, the reconciler, and the Provisioner seam — shipped and e2e-tested.
Migration tooling, Start/Stop/Status on the Provisioner, and a server/agent mode split.
In-memory fleet inventory, agent-initiated registration + heartbeat over a persistent stream, capacity queries, and a reaper that marks stale hosts down.
Placement onto ready hosts with atomic capacity reservation; oversize specs marked unschedulable.
A dedicated host-agent binary and a RemoteProvisioner — the reconciler's call becomes a network hop.
Real microVMs from a versioned Minecraft rootfs — kernel + JRE + server jar, RCON enabled.
A per-server world disk overlaid on the read-only rootfs; an S3/dir WorldStore with restore-on-boot, consistent live snapshots, on-demand backups, and orphan GC.
Per-VM eBPF SNAT/DNAT over nf_conntrack — no bridge, no iptables — with a published host port written back to each server and per-flow telemetry in eBPF maps.
Deep health via RCON / Server-List-Ping probes (player count, MOTD) and Prometheus /metrics across the control plane and agents.
Retry with backoff, host-failure rescheduling with fencing, draining, and optional leader election.
Per-user limits on servers, vCPU, and memory — enforced at create and update.
Agent-to-plane mTLS, secrets management, isolation review, and the split deploy topology.
A small core team stewards Craftling across the control plane, the host agent, and storage — alongside everyone who sends a pull request.
Clone the repo, point it at your hosts, and declare the servers you want. Self-hosted, no vendor lock-in — contributions welcome.
AA
AN
SE
AM