boxd vs exe.dev: persistent SSH VMs, compared honestly

There are two products in the world today whose elevator pitch is persistent Linux machines over SSH, batteries included, for developers and AI agents. We're one of them. exe.dev is the other.

This is not a takedown. It's an honest comparison from the team building one of the two. We share a thesis: for the work agents and developers actually do — long-running, stateful, sometimes parallel — a real Linux VM with a stable address is the right primitive. The difference is in the design choices that fall out of that shared thesis.

What we agree on

Same architectural bet, line for line:

• Linux VMs, not containers. Real kernel, real apt, real systemd.
• Persistent disk. State across reboots is the default, not a feature flag.
• SSH as the interface. Not a browser, not an SDK first.
• VMs are long-lived. The user keeps the machine; ephemeral is the wrong default.
• Batteries included. HTTPS, DNS, reverse proxy out of the box.

If you're picking between us, you're not picking between architectures. You're picking between two implementations of the same architecture.

At a glance

Numbers for exe.dev are from their public marketing as of April 2026. Numbers for boxd are from our own benchmarks; commits are open at github.com/azin-tech/boxd.

Methodology

We picked the eight capabilities above as the criteria most relevant to agent-shaped workloads (long-running, stateful, sometimes parallel). Other readers will weigh different things — that's fair, and the section below ("Where exe.dev wins") credits exe.dev for the criteria where it's stronger. Pricing reflects each vendor's published rates as of April 2026; if you spot a stale figure, send corrections to hello@boxd.sh.

Where exe.dev wins

Be fair. Three honest wins:

Polished batteries-included DX. exe.dev has been running longer, and it shows. Every dev-pain edge case — TLS certs, GitHub token plumbing, SSH key forwarding, reverse proxy quirks — has a clean answer in their docs. Their FAQ pages rank organically on Google for the actual queries developers type when they're stuck. That's not an accident; that's craft.

Simple flat pricing. The Personal tier is $20 a month, billed monthly, 25 VMs included (as of April 2026). Predictable. Finance people like it. It's a clean answer for I want a personal Linux box for the cost of a streaming subscription and you don't have to model usage to know what you'll pay.

Brand presence in the dev-tooling search graph. exe.dev shows up when people search for SSH tricks, GitHub token problems, and self-hosted GitHub Actions runners. That's a defensible distribution moat that takes years to build and we respect it.

If those three things fit your decision criteria, exe.dev is a fair pick.

Where boxd wins

Five places where the design choices we made line up differently.

1. Fork from running state

exe.dev advertises "fast VM cloning." That's a useful primitive. boxd's fork is a different primitive: copy-on-write of the running machine — memory, disk, in-flight processes — in roughly 60ms. Not a clone of the disk image; a fork of the live state.

Why it matters: a coding agent that wants to try three approaches to a refactor doesn't want three machines that boot from the same image. It wants three machines that branch from the same running state, each running forward independently. That's what a memory-included fork enables, and it's why an agent harness needs more than disk cloning. exe.dev's published cloning primitive doesn't seem to cover the running-process case; boxd's does.

2. Sub-millisecond resume from sleep

exe.dev's marketing talks about cold start (claimed ~1 second). It doesn't talk about resume from hibernation. Most personal-use VMs at exe.dev are running 24/7, which is fine when you're paying $20/month flat on the Personal tier regardless (rate as of April 2026).

boxd's design centres on hibernate-by-default. An idle VM sleeps; cost goes to near-zero. The next SSH connection wakes it in under a millisecond. The semantic feels like the machine never paused. For agent workloads that are bursty by nature, that's the difference between paying for compute that's working and paying for compute that's waiting.

3. Self-host as a real option

exe.dev is managed only. You use their cloud or you don't use exe.dev. For a personal Linux machine that's perfectly reasonable; for a regulated team or an EU-headquartered org, it's a deal-breaker.

boxd is one Rust binary. Drop it on any host with KVM. Run it in your VPC, your bare-metal rack, your country. The same software runs on the managed boxd and on a customer's own datacenter, by design — not as a separate "enterprise edition" that drifts away from the main codebase.

4. Programmatic API for VM management

exe.dev doesn't publish an API for creating, listing, forking, or destroying VMs programmatically. For human use that's fine. For an agent that wants to spawn a sandbox per task, fork it, run it, and tear it down — it isn't.

boxd exposes everything over SSH:

ssh boxd.sh create my-vm --json
ssh boxd.sh fork my-vm --as my-vm-experiment --json
ssh boxd.sh list --json
ssh boxd.sh destroy my-vm-experiment --json

Same protocol you log in with. No SDK. No API tokens beyond your SSH key. Agents that already speak shell speak boxd already.

5. Sleep-to-zero billing

exe.dev's $20/month Personal tier (monthly billing, as of April 2026) is great when you're using it. It's the same $20 when you aren't (same tier and rate, as of April 2026). That tier caps at 25 VMs and 25 GB disk per VM.

boxd is free for individuals — 10 VMs, 2 vCPU, 8 GB RAM, 100 GB disk per VM. The team plan is per-pool, sleep-to-zero. You pay for what runs.

Honest "when to pick exe.dev"

• You want a single personal Linux machine, simple flat pricing, and you'll use it most days.
• You don't need fork-from-running-state.
• You don't need self-host or EU sovereignty.
• You don't need programmatic VM management for agents.
• You like the polished docs and the FAQ-driven onboarding flow.

If those describe you, exe.dev is a clean choice. We'd recommend it before recommending half the cloud.

When boxd is the right exe.dev alternative

• You're running an agent workload that wants to fork from running state.
• You want hibernation that actually bills near zero, not flat-fee-while-idle.
• You need self-host — your VPC, your country, your bare metal.
• You want a programmatic VM API your agent can drive over SSH.
• You want the substrate to be open source so you can audit and contribute.

If those describe you, boxd is the design that pays for itself.

What this comparison is for

Two products in the same lane should be measured by the same criteria. We share a thesis and most of an architecture; we differ in five places that matter for agent-shaped workloads. The comparison is meant to be specific enough that a reader can match it against their actual requirements rather than against marketing language.

If you read this and exe.dev fits better — go there. If boxd's design choices match what you're trying to build — ssh boxd.sh and try it. The other comparison worth reading is boxd vs sprites.dev — same architectural thesis, different operational shape.

Verification details (boxd vs exe.dev, last verified 2026-05-04, last updated 2026-05-04)

• Pricing rows reference exe.dev's Personal tier ($20/month flat as of April 2026, billed monthly, 25 VMs at 2 vCPU / 8 GB RAM / 25 GB disk per VM, as documented at exe.dev), and boxd's Individual tier (free as of April 2026, 10 VMs at 2 vCPU / 8 GB RAM / 100 GB disk per VM) and Team pool plans (per-user, billed monthly) as documented at boxd.sh/pricing.
• Feature claims about exe.dev are sourced from public exe.dev marketing and documentation as of April 2026. The "Per-VM public IP" and "EU sovereignty option" rows reflect what is publicly documented; both items may exist as undocumented capabilities.
• Comparison criteria are the five design choices we believe matter most for agent-shaped workloads (fork-from-running, sub-millisecond resume, self-host, programmatic API, sleep-to-zero billing). Other readers may weigh different criteria; treat this as one team's honest assessment, not a buying guide.
• This is informational, not a contractual statement of either product's capabilities. Send corrections to hello@boxd.sh.