A single Rust binary

Most of infrastructure's complexity isn't what's running — it's what's running around it.

Pick any modern sandbox or dev-environment product and list the dependencies. E2B: Nomad, Consul, Postgres, ClickHouse, Redis. Daytona: PostgreSQL, Redis, Harbor, NestJS + Go runners. Codespaces: GitHub's entire internal stack. These are serious engineering teams making reasonable choices — you get a feature by adding a system, you scale by adding another system, you operate by adding monitoring on top of all of them.

Then somebody tries to self-host it. Every external system is a conversation with the platform team. Every dependency is a failure mode. Every version skew is a support ticket. What looked like a product becomes a mini-Kubernetes install.

We took the opposite bet.

Zero external dependencies

boxd is static Rust binaries built from a single Cargo workspace. In single-node mode you compile one binary that runs every role; in production we run four (control, worker, proxy, DNS) from the same codebase, deployed straight onto KVM-capable hosts. No external database, no external queue, no external scheduler, nothing to install alongside them. If the host has KVM, boxd runs.

Not because we don't like Postgres. Postgres is great. But every dependency you ship is a dependency your customer has to operate. For a SaaS product that runs on your own infrastructure, that cost is yours to swallow. For a product that wants to live in someone else's cloud, datacenter, or country, that cost falls on them — and it's often the thing that kills the deal.

We wanted to be droppable. That meant taking the dependencies off the table before we added them.

What we built instead

State lives in two places. Raft for consensus (control-plane writes), SQLite for local reads (every node has its own replica). Both embedded. No network hops to an external coordinator, no separate DB to manage, no Redis to tune.

Scheduling is a function on the Raft state. Not a separate system. Workers read local replicas, act on assignments, write status back into the log. The control plane is Raft; everything else reads from Raft.

Networking is per-VM public IPv4, direct. No service mesh. No ingress controller. No overlay between your agent and the outside world. SSH just works.

We own the VMM. Custom Rust, built on KVM. Not Firecracker, not QEMU. That sounds like overkill until you try to self-host Firecracker — at which point the amount of glue you need starts to look expensive.

Why this matters

The default customer conversation for an infra product goes:

"We love it. Can we run it in our own cloud?"

"Sure — here's the install guide. You'll need these services provisioned…"

We wanted the second line to be:

"Sure. Here's the binary. Run it on any KVM-capable host. That's it."

That's the ask from regulated industries, from EU-sovereignty-first teams, from anyone whose security review includes "what external services does this touch?" It's the ask from Matt Biilmann, CEO of Netlify, who told us bluntly that on-prem is a real pillar, not a side bet. The teams who want to run their own infra aren't going to wait for you to rewrite yours.

Simplicity compounds

A single binary is easier to build. Easier to test. Easier to deploy. Easier to audit. Easier to reason about. Every one of those makes development faster on our side and makes adoption faster on yours. We didn't pick zero dependencies as a moat; we picked it because every system you add slows you down.

It turns out to be a moat anyway. Competitors who bolted onto Kubernetes, Postgres, and Redis can't undo that without rewriting. Customers comparing boxd's setup against competitors' notice. Engineers with production-infra trauma notice hardest.

One Rust binary. No Postgres. No Redis. No Kubernetes. Drop it in anywhere.

That's what simple looks like.

For why this matters most when you self-host: self-hosted agent execution for engineering teams. For how this single binary compares to the well-funded alternatives in our actual lane: boxd vs sprites.dev.