ArcBox is a container and virtual-machine runtime for macOS, written in Rust with its own virtual machine monitor, VirtIO devices, filesystem sharing, and network datapath. One daemon and one command-line tool, abctl, run four kinds of workload: Docker-compatible containers with native Kubernetes, disposable microVM sandboxes for AI agents and untrusted code, full Linux virtual machines, and throwaway macOS guests cloned from a base image.
As a container engine it exposes a Docker-compatible socket and proxies to a guest dockerd, so the Docker command-line tool, scripts, and Compose files run unchanged — containers, images, BuildKit builds, Compose, port forwarding, bind mounts, named volumes, and interactive exec. linux/amd64 images run on Apple Silicon through the FEX emulator with nothing to configure, a daemon-managed k3s cluster covers Kubernetes, and the guest's Docker data is exported read-only to the host at ~/ArcBox over NFSv4 so volumes and image layers are readable by any host tool.
Sandboxes are microVMs with their own kernel, booted by Firecracker nested inside the guest. The abctl claude command builds one from a built-in template and attaches your terminal to Claude Code inside it, with the agent's permission prompts turned off because the microVM is the isolation boundary; nothing from the host is mounted, so the workspace starts empty and results are copied back out. Sandboxes can also be built from a Docker image or a Dockerfile, checkpointed while idle and restored to skip a cold boot, and driven over gRPC on the daemon socket. They require nested virtualisation — Apple Silicon M3 or newer on macOS 15 or later.
Two hypervisor backends are selectable: ArcBox's own monitor on Hypervisor.framework with manual vCPU execution, and a Virtualization.framework backend through a Swift shim. The userspace network datapath handles DHCP, DNS forwarding, NAT and connection tracking, and terminates TCP in userspace onto real host sockets rather than using pf NAT or a utun device. Measured single-stream host-to-guest throughput is 22.7 Gbps on the custom backend, with multi-flow saturation currently at 10–12 Gbps combined.
| Metric | ArcBox target | OrbStack |
|---|---|---|
| Cold boot | <1.5 s | ~2 s |
| Warm boot | <500 ms | <1 s |
| Idle memory | <150 MB | ~200 MB |
| File I/O (vs native) | >90% | 75–95% |
| Network throughput | >50 Gbps | ~45 Gbps |
Features
- Docker-compatible engine: a Docker socket and guest dockerd run existing CLI, Compose, and build workflows unchanged
- Native Kubernetes: a daemon-managed k3s cluster, with kubectl installation and kubeconfig merging
- Agent sandboxes: disposable Firecracker microVMs with their own kernel for agents, untrusted code, and CI jobs
- Snapshot and restore: a booted idle sandbox is checkpointed and restored so the next one skips a cold boot
- Linux machines: full VMs with their own kernel, persistent disk, directory mounts, shells, and one-shot commands
- macOS guests: copy-on-write clones of a pulled base image, capped at two guests per host
- x86 translation: linux/amd64 images run on Apple Silicon through FEX
- Migration: images with every tag, named volumes, bridge networks, and containers move over from Docker Desktop or OrbStack
- Host file access: guest Docker data is mounted read-only at ~/ArcBox over an NFSv4 export
- gRPC control plane: every CLI action is a daemon call, with server reflection so external tooling can drive sandboxes
- Resource monitoring: streaming CPU, memory, disk, and network samples per VM and per container
- Desktop app: a SwiftUI application for Docker and Kubernetes resources, log streaming, a terminal, and a file browser
