# ArcBox: a Rust container and VM runtime for macOS

> ArcBox is an open-source alternative to Docker Desktop and OrbStack that runs containers, Firecracker microVM sandboxes, Linux VMs and macOS guests from one daemon. It is in public beta, and its sandbox tier needs an M3 or newer Mac.

**arcboxlabs/arcbox** — Run AI agents on real and isolated machines — own kernel, filesystem, and network — with <100ms boot. Local first, OCI compatible, pure Rust.

- Repository: https://github.com/arcboxlabs/arcbox
- Website: https://arcbox.dev
- Stars: 4,277 · Forks: 189
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/arcboxlabs-arcbox

## What ArcBox replaces on a Mac

Docker Desktop and OrbStack both put a Linux environment on macOS and expose a Docker socket. OrbStack is fast and closed-source. ArcBox is an open-source runtime under MIT/Apache-2.0, written from scratch in Rust, with its own VMM, VirtIO devices, filesystem sharing and network datapath. The README states the goal plainly: match OrbStack's speed and overhead, but stay open.

The audience is narrower than "anyone who runs containers". ArcBox targets developers on Apple Silicon who want the Docker CLI and Compose to keep working, and who also need isolated machines for AI agents or untrusted code. The same daemon serves four workload tiers: containers, microVM sandboxes, full Linux machines with their own kernel and disk, and throwaway macOS guests cloned from a base image. A drop-in Docker engine alone would be a crowded pitch. The sandbox tier is the part that is harder to get elsewhere on a laptop.

## One daemon, a guest dockerd, and a real VMM

The architecture is visible in the workspace layout. The `common/` crates hold packet, datapath, conntrack, fakeip and proxy code. The `virt/` crates hold the hypervisor backends (`arcbox-hv`, `arcbox-vz`, `arcbox-hypervisor`), the VMM, and a VirtIO family covering block, console, fs, net, rng, vsock and balloon. Above that sit the RPC crates, then `runtime/`, and the CLI and daemon binaries (`arcbox-daemon`, `arcbox-helper`, `abctl`).

The container path is a proxy, not a reimplementation of the Docker engine. ArcBox exposes a Docker-compatible socket and forwards to a guest `dockerd`. That is why the Docker CLI, scripts and Compose files work unchanged, and why x86-64 images run on Apple Silicon: FEX translates them inside the guest with nothing to configure. The README gives `docker run --platform linux/amd64 alpine uname -m` as the check, printing `x86_64`.

Sandboxes take a different route. Each one is a microVM with its own kernel, booted by Firecracker nested inside the guest. `abctl claude` builds a sandbox from a built-in template and attaches your terminal to Claude Code inside it with permission prompts off, because the microVM is the boundary. Nothing from the host is mounted: `/workspace` starts empty. That design choice is the whole security argument, and it also means the agent cannot read your working tree unless it clones or you copy files in.

## Installing ArcBox and running the first container

Homebrew is the shortest path. The README gives a cask from the project's own tap, and an install script as the alternative.

```bash
brew install --cask arcboxlabs/tap/arcbox
```

After that, start the daemon and switch Docker compatibility on. The second command creates and activates a Docker context named `arcbox`, so the `docker` CLI talks to ArcBox rather than whatever it used before.

```bash
abctl daemon start
abctl docker enable
```

Then run something and hit it over the forwarded port. The README uses nginx on 8080.

```bash
docker run -d -p 8080:80 nginx
curl http://localhost:8080
```

If the socket or the context is wrong, `abctl doctor` reports on the runtime, and `abctl --help` lists every command. `abctl docker setup` installs and manages matching `docker`, `buildx` and `compose` binaries if you would rather not rely on your existing ones. For the agent path, the first `abctl claude` builds the image and later runs start in about a second according to the README; `--id` gives a second independent session, and anything after `--` is passed to the agent.

## Where ArcBox is the wrong tool

The README's own note is the biggest constraint: sandboxes need nested virtualization on Apple Silicon M3 or newer. On an M1 or M2 Mac, or on Intel, the container tier may still be the point, but the sandbox and macOS guest tiers are the reason to pick ArcBox over an established runtime, and those are the tiers that are gated.

The project also calls itself a public beta. That matters more for migration than for a scratch container. `abctl migrate` moves images with every tag, named volumes, user-defined bridge networks and containers, and restarts containers that were running on the source unless you pass `--no-start`. But containers using `--network container:<id>` are reported as blocking and must be removed from the source or migrated by hand before the run proceeds. If your setup leans on that pattern, the migration is not a single command and you should read the plan first.

There is a second, quieter limitation. The host filesystem is not shared into sandboxes by design, so an agent working on your repository has to clone it or receive files through `abctl sandbox cp`. Teams used to bind-mounting a working directory straight into an agent container will find that workflow does not exist here, and that is deliberate rather than unfinished.

## OrbStack and Docker Desktop, and what actually differs

The README names OrbStack as the bar ArcBox aims to match, and Docker Desktop as the other thing it replaces. The difference is not the CLI surface, which is meant to be identical. It is what sits underneath and what you are allowed to see.

OrbStack is closed-source. ArcBox is MIT/Apache-2.0 with the VMM, VirtIO devices, filesystem sharing and network datapath written from scratch, so the isolation boundary is inspectable. Docker Desktop is also closed and, in the tiers ArcBox describes, does not offer the same combination: a Docker-compatible engine plus Firecracker microVMs plus full Linux and macOS guests behind one `abctl`.

The useful comparison is the sandbox tier, not the container tier. If all you need is `docker run` and Compose on a Mac, the three are close enough that migration cost decides, and ArcBox's beta status is a real mark against it. If you need disposable machines with their own kernel for agents or untrusted binaries, the alternatives are a separate toolchain bolted next to your container runtime. ArcBox's claim is that both are the same primitive, and that the sandbox you run locally is what ArcBox Platform runs in the cloud.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09, which is recent. Releases are frequent and versioned: v0.7.0 on 2026-08-15, preceded the day before by v0.6.9 and v0.6.8. A `CHANGELOG.md`, `release-please-config.json` and `.release-please-manifest.json` sit at the top level, so releases are automated rather than hand-cut. The `0.x` version number is the honest signal: the project describes itself as public beta, and minor releases can carry breaking changes.

Licensing is split. The README badge says MIT/Apache-2.0, and the repository carries `LICENSE-MIT`, `LICENSE-APACHE` and `NOTICE.md`. The workspace manifest annotates crate groups with `MIT OR Apache-2.0`, which is the usual dual-licence arrangement for Rust projects and lets you take either. The description field on the repository says Apache-2.0; the files say both. Check the `LICENSE-*` files and `NOTICE.md` for the terms that apply to what you redistribute. That is a description of the files, not legal advice.

Upgrade cost is mostly the guest images. `abctl disk compact` reclaims free blocks from the Docker data image, and `abctl sandbox checkpoint` captures a booted, idle sandbox so the next one restores with near-zero boot. Snapshots are the thing to re-check after an upgrade, since they encode a booted guest state rather than a declarative config.

## Reading container files and live usage from the host

Two host-side features are worth knowing before you decide. The guest's Docker data is mounted read-only at `~/ArcBox`, served over NFSv4 through a vsock relay, so named volumes, container state and image layers are browsable in Finder and readable by ordinary host tools. The README's example greps a volume directly instead of using `docker cp`.

```bash
open ~/ArcBox
grep -r "panic" ~/ArcBox/volumes/my-app-data/_data
```

Because the mount is read-only, this is an inspection path, not a way to edit container data in place. For resource visibility, `abctl top` streams CPU, memory, disk and network for the System VM, and adds a per-container table with CPU, memory against the limit, disk and network rates, and PIDs when containers are running. `abctl disk usage` reports Docker data image usage. The README states that the same samples feed both the API and the desktop app, so `abctl top` is a view onto the same data the UI shows.

## Conclusion

Adopt ArcBox if you run Docker on an Apple Silicon Mac and want an open-source runtime that also gives you disposable microVMs for agents or untrusted code. Skip it if you are on Intel or an M1 or M2 Mac and your work depends on the sandbox and macOS guest tiers, since the README ties sandboxes to nested virtualization on M3 or newer. Before migrating, run `abctl migrate from orbstack --dry-run --json` and read the plan, then check `abctl doctor` on the target machine.

## FAQ

### What is ArcBox?

ArcBox is an open-source container and VM runtime for macOS, written from scratch in Rust. One daemon and one CLI serve four workload tiers: Docker-compatible containers, disposable Firecracker microVM sandboxes, full Linux machines, and throwaway macOS guests.

### Is ArcBox free?

The repository carries MIT and Apache-2.0 licence files, and the README badge says MIT/Apache-2.0. The README does not describe a paid tier for the runtime itself.

### What is ArcBox used for?

The README lists four uses on the same runtime: a drop-in Docker engine with native Kubernetes, disposable microVMs for AI agents and untrusted code, full Linux VMs with their own kernel and disk, and throwaway macOS VMs cloned from a base image.

### What is the difference between Azure and Azure Arc?

The README does not cover Azure or Azure Arc, so this question cannot be answered from the project documentation available here.

## Sources

- [arcboxlabs/arcbox on GitHub](https://github.com/arcboxlabs/arcbox)
- [License: Apache-2.0](https://github.com/arcboxlabs/arcbox/blob/master/LICENSE)
- [Project website](https://arcbox.dev)
- [README](https://github.com/arcboxlabs/arcbox/blob/master/README.md)
- [Releases](https://github.com/arcboxlabs/arcbox/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/arcboxlabs-arcbox