AgentBox Puts a Bare Hetzner VM on the Same Feature Table as E2B and Daytona

Open AgentBox's provider support matrix and Hetzner sits in the same row as E2B and Daytona — full support, live snapshots, native URLs, no asterisk. That's a strange thing to see written down plainly. E2B and Daytona are venture-funded companies whose entire product is "isolated sandbox infrastructure for AI coding agents." AgentBox is an MIT-licensed CLI from a single primary author, 247 GitHub stars, that treats a bare Hetzner box — hardware you rent by the hour with no sandbox-specific product wrapped around it — as an equally first-class target.

That's worth taking seriously, not as a novelty, but as a data point. A community tool already ships a smoother path from "coding agent" to "isolated box on owned hardware" than most of the self-hosted PaaS landscape does today — and it does it with a fraction of the engineering a funded sandbox vendor puts behind the same problem. The rest of this post is a straight technical teardown: what AgentBox's checkpoint and credential mechanisms actually do, what a Cluster-API-managed platform can lift wholesale from them, and — the harder question — what those mechanisms quietly assume that stops working the moment more than one untrusted party shares the fleet.

What AgentBox Actually Is​

Strip away the pitch and AgentBox is a thin, well-designed orchestration layer. Install it, and the whole flow to get a coding agent running on a Hetzner box looks like this:

npm -g i @madarco/agentbox && agentbox install
agentbox hetzner login              # token saved to ~/.agentbox/secrets.env
agentbox prepare --provider hetzner # builds and snapshots the base image
agentbox hetzner claude             # launches Claude Code inside the box

The first run also builds a local agentbox/box:dev image (~1 GB) — a one-time cost regardless of which provider you eventually target. Once that's done, AgentBox "teleports" a project into a dedicated box, local or remote, carrying over shell config, editor settings, and each agent's existing auth so the session inside the box looks like the developer's own machine, not a stripped-down container. It currently drives three agent CLIs — Claude Code, Codex, and OpenCode — and its provider table looks like this:

Read that table next to the news from the same category this quarter: Daytona moved its production codebase closed-source in June 2026, citing AI-assisted vulnerability scanning against public repos as the reason it no longer wants its isolation code readable by everyone — the exact thing AgentBox lists as only "partial" support for. E2B, by contrast, stayed open source and is now the reference point every self-hostable-sandbox comparison measures against. AgentBox didn't build any sandbox infrastructure of its own for either of them — it built an adapter, thin enough that Hetzner slots into the same row without needing a company behind it.

The Sub-Second Checkpoint, Explained​

The headline claim — "sub-<1s startup of new boxes from a previous checkpoint" — is easy to mentally file next to Firecracker microVM snapshots or CRIU process-freeze, the mechanisms E2B and Daytona actually use to pause and resume a live, running sandbox. That's not what AgentBox is doing, and the distinction matters for anyone deciding what to copy.

AgentBox's checkpoint is a Docker layered-filesystem snapshot merged through a FUSE overlay at /workspace, not a memory-state freeze. The upper layer of that overlay captures everything a fresh box would otherwise have to redo from scratch — installed packages, node_modules, project bootstrap steps, carried-over dotfiles — and a new box boots by mounting that cached layer instead of repeating the install. On Hetzner specifically, that same idea extends to warm baseline VM images: the box boots from an image that already has the dependency layer baked in, rather than provisioning bare and running setup scripts on every launch.

That's a meaningfully different (and cheaper) engineering problem than what E2B and Daytona solve. E2B's auto-pause preserves a Firecracker microVM's full memory state so a specific, already-running sandbox can resume mid-execution. AgentBox's checkpoint skips the setup tax for a new session — it's a cold-start-avoidance trick, not a pause/resume primitive. Both land on "sub-second," but one resumes a process, the other just avoids re-running apt install and npm install for the hundredth time. Conflating the two is the easiest way to misjudge what AgentBox's checkpoint model actually buys a platform.

The Credential Isolation Pattern, Explained​

The second mechanism worth studying closely: git credentials never leave the developer's host machine. AgentBox syncs the project workspace into the box — code, config, dependency state — but the box itself never receives a git token or SSH key. When the agent running inside the box wants to push to a remote, AgentBox intercepts that call and forwards an explicit permission request back to the host. Nothing goes out until a human on the host machine approves it.

It's a simple design, and simple is the point: the box can be fully compromised — a malicious dependency, a prompt-injected agent trying to exfiltrate something — and it still has no credential to exfiltrate. The worst it can do is ask to push, through a channel the host controls and can deny.

What Only a Platform Control Plane Can Add​

Both mechanisms are genuinely portable ideas. Neither mechanism, as built, is a platform primitive — and the gap between "clever CLI trick" and "thing a self-hosted PaaS can run for many tenants" is exactly where kubernetes-sigs/agent-sandbox, not AgentBox, is the right thing to build on.

That project — a SIG Apps effort, not a side tool — ships a Sandbox CRD (a stateful pod with a stable identity and persistent storage that survives restarts) plus three extension CRDs: SandboxTemplate for reusable security-context and resource-limit configs, SandboxClaim for provisioning on demand, and SandboxWarmPool for pre-warming a pool of ready pods so a new sandbox request gets assigned in milliseconds instead of waiting on a cold schedule. Pair the Sandbox CRD with gVisor or Kata Containers and you get kernel-level isolation between tenants — a real trust boundary, not just a container namespace.

AgentBox has none of that, because it was never asked to. Its isolation runtime is plain Docker — no gVisor, no Kata, nothing that survives a container-escape bug in an agent-generated dependency. Its credential model assumes exactly one trusted human on exactly one host machine clicking "approve." That's the correct design for a solo developer running their own agent on their own box. It has no answer for the question a platform has to answer on day one: what happens when tenant A's sandbox and tenant B's sandbox share a node, and neither trusts the other, let alone the agent code running inside either one. AgentBox was built to make one operator's laptop-style trust model portable to a VM. It was never built to arbitrate between two operators who don't trust each other — because until now, it never had to.

That gap is also the honest answer to what "missing self-hosted default" means. The self-hosted PaaS landscape has spent 2025 and 2026 competing on one-click app catalogs, git-push deploy flows, and buildpack support — Coolify, CapRover, Cloudron, Elestio all ship some version of "run my app on my hardware" as a polished, first-class flow. None of the mainstream self-hosted PaaS platforms currently ships "spin up an isolated, checkpointed sandbox for a coding agent" as an equivalent first-class deploy target — it's not in any of their public feature tables. bex's own roadmap treats agent-sandbox support as a dependency still being built toward, not a shipped feature. A 247-star CLI from one developer got to "developer-friendly agent sandbox on a bare Hetzner box" faster than any self-hosted PaaS project got there as a platform feature. That's the actual gap AgentBox exposes — not that self-hosting agent sandboxes is impossible, but that nobody building a platform around it has shipped the onboarding UX a solo tool already has.

What This Means for a Cluster-API Fleet​

Put the two halves together and the answer isn't "adopt AgentBox" or "ignore it" — it's "steal the UX, build the trust boundary properly." Concretely, for a Cluster-API-managed fleet building its own agent-sandbox primitive:

• Borrow the checkpoint pattern, not the checkpoint claim. Cache the dependency-install layer per project (or per common base image), not the live process state, and boot new sandbox sessions from that cache. It's cheaper to build than a Firecracker memory-snapshot pipeline, and it solves the actual pain point — waiting on npm install every time an agent spins up a fresh sandbox.
• Borrow the credential permission-gate, unmodified. Keep git tokens on a component the sandbox never touches, and require an explicit approval hop before any push leaves the sandbox. This pattern doesn't need a platform's multi-tenancy story to be valuable — it's correct at any scale.
• Don't borrow the isolation model. Build sandbox isolation on kubernetes-sigs/agent-sandbox's CRDs paired with gVisor or Kata, not plain Docker containers. That's the difference between "safe for one developer's own agent" and "safe when the node is shared across tenants who've never met."
• Use SandboxWarmPool for the thing AgentBox can't do at all: fleet-wide capacity. A single-operator tool has no concept of "how many boxes should sit warm across the whole cluster right now" — that's a scheduling and billing question a platform's control plane owns, not something a CLI running on one laptop was ever positioned to solve.

AgentBox proves the developer experience for git-push-adjacent agent sandboxing on owned hardware is already solved at small scale. The job left for a platform isn't reinventing that UX — it's making the same trust-free credential story and cache-warm startup work when the box next door belongs to someone else.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your platform's agent-sandbox story is still on the roadmap, check out the repo on GitHub and see what a Cluster-API-managed fleet on owned hardware already handles.

Sources​

• AgentBox — Teleport for agents.
• Quickstart — AgentBox.
• GitHub - madarco/agentbox.
• Daytona is going closed source. Here's why..
• GitHub - kubernetes-sigs/agent-sandbox.
• Running Agents on Kubernetes with Agent Sandbox — Kubernetes Blog.
• Agent Sandbox documentation.