# boxd vs Blaxel

> Blaxel sandboxes suspend within seconds and resume fast, with the filesystem held in memory. A boxd machine is a full computer with a 100 GB disk, plain SSH and coding agents installed.

Checked 2026-10-30. Every Blaxel claim links to Blaxel's own docs or pricing. Web page: https://boxd.sh/compare/blaxel/

## At a glance

|  | boxd | Blaxel |
| --- | --- | --- |
| **Where boxd is ahead** |  |  |
| SSH | Native, own port per machine | CLI terminal; SSH via Tailscale |
| Coding agents installed | Claude Code, Codex, OpenCode | Opt-in Claude Code and Codex images |
| Root, systemd, Docker | Yes, plus nested virtualization | Root; Docker via a dedicated image |
| Wakes on a request | Yes, HTTPS or SSH · app answers in 156 ms | Implied, not documented |
| Starts from a snapshot, app running | Yes · app answers in 1.19 s | Private preview (Carbon) |
| **Where Blaxel is ahead** |  |  |
| CPU test (runs/s) | 12.6 (our run) | 18.03 |
| Built-in integrations | 100+, credentials kept out | ~30, as MCP servers |
| Regions | Frankfurt (US waitlist) | Oregon, Virginia, London, Frankfurt |
| SOC 2 | SOC 2 in progress | SOC 2 Type II |

## Use boxd when

- You need a durable disk on the machine itself
- You want plain SSH and a full Linux
- You want agents installed in the default image

## Use Blaxel when

- You want the fastest resume for very short sessions
- You need US regions
- You also want them to host your agents and MCP servers

## Where boxd stands out

### A real disk

Every boxd machine has a 100 GB disk that persists through sleep, stop and start. A Blaxel sandbox keeps its filesystem in RAM, about half of its memory, and needs a separate volume for anything durable.

### Plain SSH

Every machine has its own SSH port. `ssh my-machine.boxd` works from any terminal, editor or agent, with no CLI tunnel and no token to refresh.

### Claude Code, Codex and OpenCode are already there

Every machine boots with all three installed, plus headless Chrome, a desktop you can open in the browser, Docker and the boxd CLI. Your API keys stay outside the machine: the guest holds a placeholder and our proxy swaps in the real value.

### A full Linux you control

Root, systemd, Docker and nested virtualization on the default image. On Blaxel, Docker needs a dedicated image and processes are managed through its sandbox API.

boxd's timings were measured on its production cluster on 2026-10-29, ten runs each, from a client in the same datacenter: a hibernated machine's app answered an HTTPS request in 156 ms median; a new machine from a snapshot answered 1.19 s after the create command.

## Side by side

|  | boxd | Blaxel |
| --- | --- | --- |
| **The machine** |  |  |
| Full VM, own kernel | Yes, every machine | Yes, microVM ([source](https://docs.blaxel.ai/Sandboxes/Overview.md)) |
| Default size | 2 vCPU · 8 GiB · 100 GB | Not published ([source](https://docs.blaxel.ai/api-reference/compute/create-sandbox.md)) |
| Largest, self-serve | 8 vCPU · 32 GiB | Per tier, shown in console ([source](https://docs.blaxel.ai/Security/Quotas.md)) |
| Root, systemd, Docker | Yes, plus nested virtualization | Root; Docker via a dedicated image ([source](https://docs.blaxel.ai/Tutorials/Docker.md)) |
| CPU test (runs/s) | 12.6 (our run) | 18.03 ([source](https://github.com/starslingdev/hpc-sandbox-benchmarks/blob/main/LEADERBOARD.md)) |
| **Composable** |  |  |
| Ready machine described in code | Machine specs, built on one another | Images, branchable ([source](https://docs.blaxel.ai/Sandboxes/Templates.md)) |
| Machines create machines | Yes, signed in as the machine | SDK signs in on Blaxel ([source](https://docs.blaxel.ai/sdk-reference/introduction.md)) |
| Built-in integrations | 100+, credentials kept out | ~30, as MCP servers ([source](https://docs.blaxel.ai/Integrations.md)) |
| Schedules and event triggers | Cron and events; sleeps between runs | Schedules, job triggers ([source](https://docs.blaxel.ai/Sandboxes/Schedules.md)) |
| Standalone disks | Yes, outlive the machine | Volumes, one sandbox at a time ([source](https://docs.blaxel.ai/Volumes/Overview.md)) |
| Private network between machines | Org network, split by tags | Not published ([source](https://docs.blaxel.ai/Sandboxes/Proxy.md)) |
| Tailscale or NetBird | Both, built in | Tailscale image, your key ([source](https://docs.blaxel.ai/Tutorials/Tailscale.md)) |
| Agent skills or MCP | Agent skills; no MCP server | Skills and MCP servers ([source](https://docs.blaxel.ai/skills-mcp.md)) |
| **Ready when you are** |  |  |
| Sleeps with processes kept | Yes, standby and hibernate | Yes, standby ([source](https://docs.blaxel.ai/Sandboxes/Overview.md)) |
| Wakes on a request | Yes, HTTPS or SSH · app answers in 156 ms | Implied, not documented ([source](https://docs.blaxel.ai/Sandboxes/Standby-control.md)) |
| Starts from a snapshot, app running | Yes · app answers in 1.19 s | Private preview (Carbon) ([source](https://docs.blaxel.ai/Sandboxes/Fork.md)) |
| Session limit | None | None stated |
| **Built for agents** |  |  |
| Coding agents installed | Claude Code, Codex, OpenCode | Opt-in Claude Code and Codex images ([source](https://docs.blaxel.ai/Sandboxes/Templates.md)) |
| SSH | Native, own port per machine | CLI terminal; SSH via Tailscale ([source](https://docs.blaxel.ai/Tutorials/Tailscale.md)) |
| HTTPS URL per port | Yes, plus custom domains | Yes ([source](https://docs.blaxel.ai/Sandboxes/Preview-url.md)) |
| Raw TCP inbound | Yes, 3 ports per machine | Not documented ([source](https://docs.blaxel.ai/Sandboxes/Ports.md)) |
| Secrets kept out | Yes, swapped in at the proxy | Yes, proxy injection ([source](https://docs.blaxel.ai/Sandboxes/Proxy-secrets-injection.md)) |
| **Price** |  |  |
| vCPU-hour | $0.047, CPU used | Included in RAM price ([source](https://blaxel.ai/pricing)) |
| RAM GiB-hour | $0.014, memory in use | ≈$0.041 per GB-hour ([source](https://blaxel.ai/pricing)) |
| While asleep | Hibernated: disk only | Standby: snapshot storage ([source](https://blaxel.ai/pricing)) |
| **Also worth knowing** |  |  |
| GPUs | No | Not published ([source](https://blaxel.ai/pricing)) |
| Regions | Frankfurt (US waitlist) | Oregon, Virginia, London, Frankfurt ([source](https://docs.blaxel.ai/Infrastructure/Regions.md)) |
| SOC 2 | SOC 2 in progress | SOC 2 Type II ([source](https://blaxel.ai)) |
| SAML SSO | No | Yes ([source](https://docs.blaxel.ai/Security/SSO-Directory-sync.md)) |
| Egress allowlist | Yes | Yes ([source](https://docs.blaxel.ai/Sandboxes/Proxy-domains.md)) |
| Self-host | Yes, free to 16 vCPUs | Your metal, their control plane ([source](https://blaxel.ai/pricing)) |

## Where Blaxel is stronger

- **Resume speed.** Blaxel suspends sandboxes seconds after they go idle and resumes them in about 25 ms by its own figures.
- **A kit of its own.** Blaxel is as composable as boxd: about 30 integrations as MCP servers, schedules and job triggers, agent skills, and it hosts your agents and MCP servers next to the sandboxes.
- **CPU on this test.** Blaxel scored 18.03 on the StarSling CPU test; boxd scored 12.6.
- **Regions.** Oregon, Virginia, London and Frankfurt.
- **Compliance.** SOC 2 Type II, ISO 27001 and HIPAA, plus SAML SSO.

## Questions

### Where do my files live on Blaxel?

In memory: by Blaxel's docs the sandbox filesystem takes about half of the sandbox's RAM, and durable data goes on a volume. A boxd machine has a 100 GB disk that survives sleep, stop and start.

### Which resumes faster?

Blaxel quotes about 25 ms to resume. We measured the whole request instead: an HTTPS request to a hibernated boxd machine got the app's answer in 156 ms median, from inside the datacenter.

## How we measured

### Wake from hibernation

A small Python HTTP server on a default 2 vCPU machine, published on its HTTPS URL. Ten times: hibernate the machine, confirm it reports hibernated, then send one HTTPS request on a new connection from a client machine in the same datacenter. Median 156 ms until the app answered (104–213 ms); a warm request takes about 73 ms, so waking adds about 80 ms. The app's process ID was the same after every wake.

### New machine from a snapshot

A snapshot of that machine with the server running. Ten times: run `boxd new --from-snapshot`, then request the new machine's HTTPS URL until the app answers. Median 1.19 s from the create command to the app's first response (1.14–1.24 s). The first request succeeded every time; nothing was started after boot.

### CPU

The Node.js web tooling test from StarSling's open sandbox benchmark (Phoronix Test Suite 10.8.4, pts/node-web-tooling-1.0.1, Node 22.23.1, two passes per run), on a 4 vCPU machine. Three runs: 12.65, 12.86 and 12.19 runs/s. The other providers' numbers are from StarSling's own published leaderboard, which runs 4 vCPU / 8 GiB; boxd's 4 vCPU size has 16 GiB, which this test doesn't use.

### What these numbers don't include

Your own network distance. Every timing was taken from a client in the same Frankfurt datacenter; from the US, add your round trip on top. A larger app has more memory to bring back, so it takes longer than a small server.

## More comparisons

- [boxd vs E2B](https://boxd.sh/compare/e2b/index.md)
- [boxd vs Daytona](https://boxd.sh/compare/daytona/index.md)
- [boxd vs Modal](https://boxd.sh/compare/modal/index.md)
- [boxd vs Vercel Sandbox](https://boxd.sh/compare/vercel-sandbox/index.md)
- [boxd vs Cloudflare Sandbox](https://boxd.sh/compare/cloudflare-sandbox/index.md)
- [Moving off Runloop](https://boxd.sh/compare/runloop/index.md)
- [boxd vs exe.dev](https://boxd.sh/blog/boxd-vs-exe-dev/)
- [boxd vs sprites.dev](https://boxd.sh/blog/boxd-vs-sprites/)
- [All comparisons](https://boxd.sh/compare/index.md)