hotcell

hotcell is an Apache-2.0 CLI daemon that provisions isolated sandboxes for AI agents on hardware you already own — a Mac Mini, a Linux VM, or bare metal. It is built and maintained by a single developer (sinameraji on GitHub) and ships as a single npm package that includes the CLI, daemon, and TypeScript SDK, with a Python SDK available separately.

What It Is

hotcell sits in the category of self-hosted agent sandbox infrastructure. Its core job is to run AI coding agents — Claude Code, Codex, OpenCode, Mastra, and others — in isolated environments where the real provider API key never enters the sandbox, spending is hard-capped, and egress can be locked down to a gateway allowlist. The daemon manages a fleet of sandboxes on one host, with admission control that refuses to over-subscribe rather than OOM-ing the machine.

Containment Model

Every outbound model call from a sandbox flows through a single egress gateway on the daemon. The gateway enforces three layers of containment:

• Key isolation: Real provider keys (OpenAI, Anthropic, OpenRouter, GitHub, etc.) live on the daemon. Each sandbox is minted a short-lived, revocable per-sandbox token (hc-…) at creation time. The gateway swaps that token for the real key on the way out. Destroying the sandbox revokes the token in the same step.
• Spend control: Hard USD spend caps per sandbox, model and provider allowlists, sliding-window rate limits, and token TTLs prevent runaway costs.
• Egress lockdown: Default-deny egress is kernel-enforced on Linux containers (host iptables) and enforced by construction on microVMs with no NIC (vsock is the only route out). On macOS Docker Desktop the policy is advisory — the gateway, caps, and metering still apply, but raw packets are not dropped at a host firewall.

Isolation Tiers

hotcell exposes three isolation drivers behind one interface:

• Docker containers — fastest, highest density, shared host kernel.
• Firecracker microVMs — Linux/KVM, VM-grade isolation; warm pools adopt a pre-booted VM in ~7 ms; full-VM snapshots resume in ~80 ms.
• Apple VZ microVMs — macOS, same daemon-level parity; microVM guests have no network device by default, making egress denied by construction.

All three tiers support persistent /workspace volumes, streamed exec with persistent shell sessions, preview URLs via an L4 proxy, stateful code interpreter (Python and JS), pause/resume, backup/restore, and per-sandbox CPU/mem/net metrics with OpenTelemetry export.

Workflow: Fleet Operations

A typical multi-agent workflow uses a single command to spin up N isolated cells, each with the same repo cloned into its own workspace on its own branch, and the chosen agent preinstalled:

hotcell create -n 5 --name feat --branch --egress \
    --repo https://github.com/me/app --setup "npm i -g opencode-ai"
hotcell terminal <id>   # inside: cd app && opencode
hotcell rm --all        # done — 5 cells gone, repo untouched

Git push works keylessly out of the box because each cell's origin is wired through the gateway automatically. The TUI fleet view shows live CPU, memory, and cost per cell.

Update: v0.1.23

The latest release is v0.1.23, published on 2026-07-29. The project was created in June 2026 and has been actively updated, with the last push recorded on 2026-08-01. The homepage notes a hotcell Cloud coordination layer (central key vault, org-wide egress policy, per-team spend quotas, SSO, and audit) is in early-access waitlist stage — the self-hosted daemon remains Apache-2.0 and free with no feature gates.

Deployment Model and Tradeoffs

hotcell is single-tenant by design: anyone who can reach the daemon API controls the sandboxes, so the daemon should be bound to loopback or protected with an API key. It does not protect non-HTTP protocols (Postgres, Redis, MongoDB), AWS SigV4 request-signing schemes, or mTLS/client certificates — credentials for those must be injected directly. SDKs that hardcode their provider host bypass the gateway unless HOTCELL_EGRESS_ENFORCE is set to deny those calls outright.