ArcBox's wager: one runtime, four isolation levels

ArcBox is a macOS-first runtime that puts containers, disposable sandboxes, full Linux machines, and macOS guests behind one daemon and command-line experience. This series examines the design question that follows from that ambition: can one runtime make these workloads feel like one local platform without pretending that their operating-system, lifecycle, performance, and security boundaries are the same? The answer matters to anyone who wants Docker-compatible development, safer execution for AI agents or untrusted code, reproducible CI, or a practical way to use a Mac as more than a laptop. The useful outcome is not a feature inventory. It is a model for deciding which boundary a workload actually needs.

More than a Docker replacement

The most familiar way to approach ArcBox is as an open-source alternative to Docker Desktop and OrbStack on macOS. That comparison is meaningful. ArcBox exposes a Docker-compatible socket, supports ordinary Docker commands and Compose workflows, and aims to let existing tools keep working without learning a new container engine. It is written in Rust and releases its runtime under the MIT or Apache-2.0 license, in contrast with the closed-source positioning it attributes to OrbStack. For a developer who only wants to run a web service locally, the visible experience can therefore begin with a familiar command such as docker run.

But the Docker comparison is too small to describe the subject. ArcBox also presents itself as a runtime for workloads that do not fit the ordinary container contract. Its sandbox tier uses disposable microVMs for AI agents, untrusted code, and CI jobs. Its Linux machine tier gives a guest its own kernel, disk, and distribution. Its macOS tier creates throwaway macOS guests from a prepared base image. These are not four names for the same operation. They are four answers to different questions about what should be isolated, what should persist, and which operating system should execute the workload.

That distinction is easy to lose because the same daemon and CLI are responsible for all of them. A common interface can be a genuine reduction in friction, but it can also hide the cost of crossing a boundary. A Docker-compatible container needs the guest engine to accept an API request. A sandbox needs nested virtualization, a microVM, a guest agent, and a cleanup policy. A full machine needs a persistent machine identity and disk. A macOS guest must use Apple's Virtualization.framework and obey platform-specific limits. The fact that ArcBox can expose each through a coherent product does not make the underlying guarantees interchangeable.

Four ways to cross a boundary

The four tiers are best understood by the boundary each one gives the workload.

  • Containers provide the engine-compatible path. ArcBox's guest Docker service handles containers, images, builds, volumes, networks, and interactive operations, while the host-side daemon supplies the socket, lifecycle orchestration, and integration with the Mac. Native Kubernetes is placed beside this path in the same runtime.
  • Sandboxes provide a disposable workload boundary. They are nested Firecracker microVMs inside the Linux System VM. Their purpose is not merely to package a process but to give an agent or untrusted program a short-lived virtual machine that can be created, used, paused, resumed, checkpointed, and removed through a dedicated API.
  • Linux machines provide a complete Linux environment. Each machine has its own kernel, persistent disk, and chosen distribution. SSH and one-shot command execution make it suitable when the user needs an operating system environment rather than the narrower contract of a container engine.
  • macOS guests provide a disposable macOS operating system. They are a separate Machine-tier capability, booted only through Apple's Virtualization.framework from APFS-compatible base images. A clone can be clean for a CI job without requiring a full copy of the base system disk.

These boundaries also imply different relationships with the host. Containers and sandboxes use the Linux System VM as their common substrate. The System VM is the place where the guest Docker service runs and where the sandbox manager creates nested microVMs. Full Linux machines are separate named machines managed by the broader runtime. macOS guests have their own service and boot path; they share the daemon and socket with Linux machines but do not share the Linux guest agent or custom Hypervisor.framework path.

flowchart LR D["ArcBox daemon and CLI"] --> S["Host System VM"] S --> C["Containers and Kubernetes"] S --> B["Nested Firecracker sandboxes"] D --> L["Full Linux machines"] D --> M["Disposable macOS guests"] C --> CB["Docker engine boundary"] B --> BB["Disposable workload boundary"] L --> LB["Linux kernel, disk, distro"] M --> MB["macOS guest OS and VZ"]

The map is intentionally uneven. It does not draw four equal boxes under one abstract “virtualization” label, because ArcBox itself does not implement them as equal boxes. The Linux System VM is the shared center for containers and sandboxes. Linux machines use the runtime's general machine-management path. macOS guests use a VZ-only path with their own identity and networking rules. The common product surface is real, but the technical path is conditional.

For readers, this gives a practical first rule: choose by the boundary, then benefit from the common runtime. If the requirement is to keep Docker tooling unchanged, the container tier is the natural starting point. If the requirement is to run code that should be disposable and strongly separated from the main development environment, the sandbox tier is the relevant one. If the workload depends on a particular Linux kernel or distribution, a full Linux machine is more honest. If the workload itself must run on macOS, only the macOS guest tier answers that requirement.

The question behind the architecture

The central theme of ArcBox is not simply “more kinds of virtual machines.” It is the attempt to share the expensive and failure-prone parts of local virtualization while preserving the meaning of each workload contract. Boot assets, persistent storage, networking, host sockets, guest communication, readiness signals, and cleanup can be organized once at the runtime level. The workload tiers can then reuse that foundation instead of presenting four unrelated products.

The payoff is visible in the developer workflow. A container request can use the Docker CLI. A sandbox can be driven by the same daemon through Python, TypeScript, or Rust SDKs, with an E2B-shaped compatibility surface for some applications. A local sandbox is described as the same primitive that ArcBox Platform intends to use in the cloud. A fleet agent can consume a disposable macOS clone for a CI job. In each case, the common runtime promises that local development and later scale need not begin with completely different abstractions.

Yet reuse creates shared dependencies. A System VM that carries Docker and the sandbox control plane is a useful concentration of infrastructure, but it is also a place where readiness, networking, asset verification, and recovery must work before higher-level operations can succeed. A custom host VMM can improve control over VirtIO devices and the network datapath, but it also owns vCPU execution, MMIO dispatch, interrupt injection, worker shutdown, and memory teardown. A fast CoW clone can make a machine disposable, but it still depends on APFS and the operating system's virtualization rules. The common runtime makes these conditions easier to operate together; it does not remove them.

That is why the repository's maturity language matters. ArcBox describes itself as public beta. Platform and fleet capabilities are still marked as in development, and several future goals—broader Docker Engine coverage, faster x86 translation, Linux host support, and lower idle footprint—remain on its next-step list. The repository also contains measurements with carefully bounded setups rather than a universal performance claim. A custom network path reports very high single-stream throughput in its documented test, while multi-flow scaling reaches a lower combined ceiling. A filesystem optimization materially improves short metadata operations but does not erase the cost of virtualized file I/O. These are useful engineering results, not proof that every tier or workload is already equivalent to its competitors.

Security requires the same discipline. A VM boundary can be valuable against an untrusted job: a disposable sandbox or macOS clone can be destroyed after use, limiting the job's retained state. But a local VM is still managed by its host. The repository's macOS analysis explicitly distinguishes isolating the job from protecting the job's memory against the host. It does not present Apple's Virtualization.framework as a confidential-computing environment, and it warns against describing macOS CI as “complete zero trust.” ArcBox also keeps a privileged helper for narrowly defined host mutations, authenticating release-build peers by code signature rather than allowing a world-connectable socket to authorize arbitrary root actions. “The daemon is not root” and “the host is outside the trust model” are different statements.

The rest of this series follows those distinctions from the inside out. It first examines the System VM and the startup path that turns a daemon into a usable platform. It then follows a Docker request across the compatibility boundary, before opening the nested sandbox lifecycle: execution state, pause and resume, snapshots, files, ports, and warm templates. Full Linux machines and macOS guests show what changes when the operating-system boundary widens. Performance measurements, cleanup behavior, privilege separation, SDKs, and fleet direction then provide the final test of the thesis.

The important judgment is conditional. ArcBox's strongest idea is that one local runtime can make several isolation levels available through shared infrastructure and coherent tooling. Its weakest interpretation would be that one API surface makes all workloads equally isolated, equally fast, equally portable, or equally mature. To understand the subject accurately, the next question is therefore concrete: how does ArcBox build and maintain the shared System VM on which the first two tiers depend?

References