ArcBox: a Rust container and microVM runtime for macOS, aimed at Docker Desktop and OrbStack
Run AI agents on real and isolated machines — own kernel, filesystem, and network — with <100ms boot. Local first, OCI compatible, pure Rust.
At a glance
- What is it?
- ArcBox is an open-source macOS runtime that puts containers, Firecracker microVM sandboxes, Linux VMs and macOS guests behind one daemon and one CLI. Its sandbox tier is the part worth evaluating closely, and it needs Apple Silicon M3 or newer.
- Who is it for?
- Adopt ArcBox if you are on Apple Silicon M3 or newer, you want an open-source Docker Desktop replacement, and the sandbox tier is the reason you are looking. Do not adopt it if you are on Intel Macs or M1/M2 hardware and sandboxes are your goal, or if you need a runtime with a long production track record, since the README calls this a public beta.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The macOS gap ArcBox is trying to close, and who feels it
Docker Desktop is the default way to run Linux containers on a Mac, and OrbStack is the faster alternative most engineers switch to. The README states the case plainly: OrbStack "set the bar for running Docker on a Mac quickly and with little overhead, but it is closed-source." ArcBox is the response to that, 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 stated aim is to match OrbStack, not to beat it on features OrbStack lacks.
The audience is narrower than "Mac developers." The interesting tier is sandboxes: disposable microVMs for AI agents and untrusted code, with `abctl claude` as the finished ergonomics around that primitive. If you are running coding agents on your laptop and want them off your host filesystem, that is the problem ArcBox addresses. The container tier exists so you do not have to run two tools. The README also notes that the sandbox you run locally is the same primitive ArcBox Platform runs in the cloud, which matters if you intend to move the same workload to a fleet later without rewriting it.
Four workload tiers behind one daemon
ArcBox presents one daemon and one CLI serving four kinds of workload. Containers are a drop-in Docker engine plus a local k3s cluster. Sandboxes are disposable microVMs. Linux machines are full VMs with their own kernel, disk and distro. macOS guests are throwaway macOS VMs cloned from a base image. The CLI entry points are `docker …` and `abctl k8s` for containers, `abctl claude` and `abctl sandbox` for sandboxes, `abctl machine` for Linux VMs, and `abctl macos` for macOS guests.
That is a lot of surface area for one project, and the README does not describe how the tiers share the VMM or whether the macOS guest tier depends on Apple's Virtualization framework rather than ArcBox's own. What it does describe is the nesting: sandboxes are Firecracker microVMs booted inside the guest. So the isolation boundary for an agent is not the outer macOS VM, it is a second VM inside it. The README states that `abctl claude` switches off the agent's permission prompts "because the microVM is the isolation boundary instead." That is a design position, not a convenience feature, and it is the reason the sandbox tier is worth taking seriously rather than treating as a wrapper script.
How Docker compatibility is actually wired
ArcBox does not reimplement the Docker engine. The README says it "exposes a Docker-compatible socket and proxies to a guest `dockerd`." So the Docker CLI, your scripts and your Compose files talk to a socket on the host, and the work happens in a guest daemon. `abctl docker enable` creates and activates a Docker context named "arcbox", which is how the CLI gets redirected without you editing anything by hand.
The documented working set is specific: containers, images, builds through BuildKit/Buildx, Compose, port forwarding, bind mounts, named volumes and interactive `exec`. `abctl docker setup` installs and manages matching `docker`, `buildx` and `compose` binaries. For `linux/amd64` images on Apple Silicon, x86-64 is translated inside the guest by FEX, an open-source emulator, with nothing to configure; the README's example is `docker run --platform linux/amd64 alpine uname -m` printing `x86_64`. Because a guest `dockerd` is doing the work, Docker semantics should track upstream more closely than a hand-written container implementation would. The cost is that you are running a real Docker daemon inside a VM, and the README does not discuss what happens to that daemon's state on upgrade.
Getting it running, and what the commands assume
Installation is two documented paths: `brew install --cask arcboxlabs/tap/arcbox`, or `curl -fsSL https://get.arcbox.dev | bash`. Then `abctl daemon start` brings the daemon up, `abctl docker enable` turns on Docker compatibility, and `docker run -d -p 8080:80 nginx` followed by `curl http://localhost:8080` is the smoke test. `abctl doctor` checks the runtime and `abctl --help` lists commands.
For the sandbox tier the setup is `export ANTHROPIC_API_KEY=sk-...` then `abctl claude`. The README says the first run builds the image and later runs start in about one second. Sessions are named with `--id review`, and anything after `--` goes to the agent, for example `abctl claude -- --model opus`. Sandboxes can be built from a template, an existing Docker image, or a Dockerfile: `abctl sandbox create --from-image myapp:latest --memory 512 --ttl 3600`. Files move with `abctl sandbox cp <id>:/tmp/out.tgz .`, ports with `abctl sandbox expose <id> 8080`, and a booted idle sandbox can be captured with `abctl sandbox checkpoint <id> --name clean` and brought back with `abctl sandbox restore <snapshot-id>`.
The constraint that governs everything is in a blockquote at the end of that section: sandboxes need nested virtualization, which the README limits to Apple Silicon M3 or newer. The text is truncated there, so whether Intel Macs and M1/M2 machines retain the container and VM tiers is not something I can confirm from this material. Check `abctl doctor` before assuming the sandbox commands will work.
The host filesystem at ~/ArcBox, and why it is read-only
One of the more unusual choices is that the guest's Docker data is mounted on the host at `~/ArcBox`, served over NFSv4 through a vsock relay. Named volumes, container state and image layers become browsable in Finder and readable by ordinary host tools. The README's example is `open ~/ArcBox` and then `grep -r "panic" ~/ArcBox/volumes/my-app-data/_data`, which is a real workflow improvement over `docker cp` when you are hunting through logs or volume contents.
The mount is read-only. That is the correct default for a view into a VM's disk, and it also means you cannot use this path to write files into a container. It is an inspection surface, not a transfer mechanism. For writes you still go through the Docker CLI or, for sandboxes, `abctl sandbox cp`. Worth noting that the NFSv4-over-vsock relay is another piece of the datapath ArcBox implements itself, so it is another place where behaviour can differ from a stock Docker Desktop setup.
Migration is scripted, with one documented blocker
ArcBox ships an import path for both competitors: `abctl migrate from orbstack` and `abctl migrate from docker-desktop`. Images with every tag, named volumes, user-defined bridge networks and containers come across, and containers that were running on the source are started again at the end. `--no-start` leaves them stopped. `--dry-run` shows the plan without changing anything, and `--json` combined with `--dry-run` produces a machine-readable plan, which is what you want if you intend to gate the migration in CI or review it before committing.
The README is honest about a failure case: containers using `--network container:<id>` are reported as blocking and must be removed from the source, or migrated by hand, before the run proceeds. That is a small but real category, and it is the kind of thing that only surfaces when the migration refuses to start. Running the dry run first is the documented way to find out. Because the migration reads from a live source runtime, the plan you get today may not match the state tomorrow; the README does not describe how it handles a source that changes mid-run.
Where ArcBox is the wrong tool
The clearest boundary is hardware. Sandboxes require nested virtualization and the README limits that to Apple Silicon M3 or newer. If you are on an M1, M2 or an Intel Mac and the reason you are reading about ArcBox is `abctl claude`, this is not the tool for you, regardless of how the rest of the project looks. The material does not state whether those machines can still run the container and VM tiers, so that question needs checking against the docs rather than assumed.
The second boundary is maturity. The README calls ArcBox a public beta. The release cadence in the repository listing is dense, with v0.6.8, v0.6.9 and v0.7.0 all landing within about a month, which is what you expect from a project still filling in its surface. A drop-in Docker engine that proxies to a guest daemon is a large amount of behaviour to get right, and a beta label on a tool that sits between your laptop and your containers is a real operational consideration if your team depends on it daily.
The third boundary is the sandbox model itself. Nothing on the host is mounted into a sandbox. `/workspace` starts empty, the agent clones what it needs, and you copy results back out. That is a deliberate isolation choice and it is the right one for untrusted code, but it is friction for anyone whose agent workflow assumes it can read a local repository directly. You will be moving code in and out rather than pointing the agent at a directory.
Alternatives and the actual difference in approach
The comparison the README makes is OrbStack, and the difference it names is licensing rather than behaviour: OrbStack is closed-source, ArcBox is MIT/Apache-2.0 and written from scratch in Rust. That distinction matters if you need to read the VMM, patch the network datapath, or ship the runtime inside a product. It does not matter if you only need containers to work and you are happy with the binary you have. The README says ArcBox "aims to match" OrbStack, which is an explicit statement that it is not claiming to be ahead.
Docker Desktop is the other named alternative, and the migration command exists for both. The structural difference between ArcBox and Docker Desktop is the same as with OrbStack: ArcBox owns the VMM, the VirtIO devices, the filesystem sharing and the network datapath rather than assembling them from components it does not control. That is more code to maintain and more places for bugs, but it is also why the sandbox tier can nest Firecracker inside the guest at all.
Against a plain cloud sandbox service, the difference is locality. ArcBox runs on your machine, and the README says the local sandbox is the same primitive the cloud platform runs. That claim is the one to test if portability between local and remote is why you are evaluating it, because the material does not show what the cloud side's interface looks like.
Licence, upgrade cost and what to verify first
The repository lists Apache-2.0 while the README's badge and text say MIT/Apache-2.0 and link to a LICENSE-MIT file. Those are two different statements about the same project, and it is worth resolving before you depend on it, particularly if you plan to redistribute the runtime or embed it. This is a factual discrepancy, not a legal question, and I am not giving legal advice: read the actual licence files in the repository rather than either summary.
On upgrade cost, the material supports only a limited reading. The release cadence is fast, and the Docker tier proxies to a guest `dockerd` whose state lives inside a VM image. The README does not describe how that guest image is versioned or what happens to existing containers, volumes and images when you upgrade the runtime. That is the question to ask before running ArcBox on a machine where you keep state you care about. The migration tooling implies the project expects people to move data around, but it is documented for imports from other runtimes, not for ArcBox's own version-to-version upgrades.
What to verify first is short and concrete. Run `abctl doctor` and confirm nested virtualization is reported as available on your hardware. Run `abctl migrate from orbstack --dry-run --json` (or the docker-desktop equivalent) and read the plan for blocking entries. Then run `abctl sandbox create --from-image` against a throwaway image and confirm the `--ttl` expiry behaves the way you expect, since a sandbox that outlives its TTL is a different security posture than one that does not.
Editorial conclusion
Adopt ArcBox if you are on Apple Silicon M3 or newer, you want an open-source Docker Desktop replacement, and the sandbox tier is the reason you are looking. Do not adopt it if you are on Intel Macs or M1/M2 hardware and sandboxes are your goal, or if you need a runtime with a long production track record, since the README calls this a public beta. Before installing, verify two things on your own machine: that `abctl doctor` reports nested virtualization as available, and that `abctl migrate from orbstack --dry-run --json` reports no containers using `--network container:<id>`, because those are documented as blocking and must be removed from the source or migrated by hand.
Community notes