Overview

ArcBox's tiers are contracts, not interchangeable VM sizes. This checkpoint separates interface needs from isolation and ownership, then maps Docker-compatible containers, nested sandboxes, full Linux machines, and macOS guests to concrete workload requirements. It also explains why persistence, API similarity, and stronger boundaries do not remove each tier's distinct lifecycle and cleanup constraints.

Learning outcomes

ArcBox is unified at the substrate and operating model, while each workload tier keeps its own interface and guarantee.
Choose by the complete requirement: Docker workflow, disposable isolation, Linux kernel or distro ownership, or macOS itself.
A usable sandbox must add nested virtualization, guest control, explicit state, exposure, and cleanup—not just another process or bare VM.

Keywords

ArcBoxcontainerssandboxesLinuxmacOSpersistence

Checkpoint: choosing the right boundary

ArcBox's design can now be reduced to one operational question: which boundary does a workload actually need? The daemon, System VM, Docker-compatible proxy, and four workload tiers are not separate features to be memorized; they are interacting contracts for API compatibility, process isolation, kernel ownership, operating-system identity, and resource lifetime. This checkpoint connects those contracts so the reader can choose a tier for a real requirement and see why the next question is not merely how to start a sandbox, but what the sandbox must add to the shared runtime.

A runtime is a stack of contracts

ArcBox's unifying idea is easy to state but easy to misread. One daemon can coordinate several kinds of virtualized work because it owns common infrastructure: host sockets, boot assets, lifecycle state, network integration, storage records, and the path into guest services. That does not mean every workload shares the same VM, the same API, or the same guarantee. The unification is in the substrate and the operating model; the contract presented to a workload remains tier-specific.

The container path makes this visible. The Docker CLI speaks to a local-looking socket, while ArcBox's router decides which host-sensitive operations it must handle and which ordinary requests can pass through to dockerd in the System VM. The guest engine owns most Docker semantics. ArcBox owns the effects that cross into the Mac: readiness, transport, host listeners, DNS state, and cleanup. API familiarity is the contract being preserved; the guest engine and host integration are the machinery that makes it possible.

The sandbox path begins from the same System VM but changes the boundary of the workload. Instead of asking the guest Docker engine to run a process, the guest-side sandbox manager creates a nested Firecracker microVM and reaches a separate agent inside it. The full Linux machine path changes the boundary again by giving a named VM its own kernel, disk, and distribution. The macOS guest path goes further in operating-system identity: it uses a separate Virtualization.framework service and boots a cloned macOS image. These differences are not implementation decoration. They are the answer to different requirements.

A useful way to retain the model is to separate two axes. The first is interface: does the user need Docker and Compose compatibility, a sandbox lifecycle API, SSH into a machine, or a macOS-specific machine surface? The second is isolation and ownership: is the workload sharing a guest engine, receiving a disposable microVM, owning a Linux kernel, or running as a macOS guest? Two tiers can expose a command that sounds similar while giving very different control over the operating system and very different cleanup behavior.

That is also why the VM driver abstraction matters. ArcBox can describe a VM through common operations—boot, observe, stop—and expose optional capabilities only when the selected driver and specification support them. A snapshot-capable jailed Firecracker VM and a managed VZ VM may both be “VMs,” but a higher layer should not assume that their checkpoint, staging, vsock, or adoption behavior is identical. The abstraction preserves a common vocabulary without flattening the implementation.

classDiagram class SharedRuntime { boot assets host networking lifecycle state transport and cleanup } class ContainerContract { Docker API guest dockerd engine compatibility } class SandboxContract { nested microVM disposable workload sandbox lifecycle API } class LinuxMachineContract { own kernel persistent disk chosen distro } class MacOSGuestContract { macOS guest OS VZ-only boot APFS clone } SharedRuntime --> ContainerContract : supports SharedRuntime --> SandboxContract : supports SharedRuntime --> LinuxMachineContract : manages SharedRuntime --> MacOSGuestContract : manages ContainerContract --> SandboxContract : different boundary SandboxContract --> LinuxMachineContract : wider OS boundary LinuxMachineContract --> MacOSGuestContract : different guest OS

The arrows from the shared runtime are not inheritance arrows. They mean that ArcBox supplies common orchestration around each contract.

Published by DeepMox

FAQ

Why does ArcBox separate interface from isolation?

ArcBox separates them because Docker and Compose, a sandbox lifecycle API, SSH, and a macOS machine surface describe interaction, while the underlying boundary determines engine sharing, disposable microVMs, kernel ownership, or guest OS identity.

What does persistence mean across ArcBox tiers?

Persistence applies to different layers: Docker data can survive a System VM restart, a sandbox can retain an overlay and checkpoint, a Linux machine keeps its disk, and a macOS clone can be destroyed while its base image remains. Live processes do not necessarily survive.

What must an ArcBox sandbox add beyond the System VM?

An ArcBox sandbox must coordinate a nested VMM, guest agent, root filesystem, network lease, readiness, execution state, exposure, and cleanup so a stronger workload boundary remains usable.

Previous11 minArcBox Docker Compatibility Path

Next11 minArcBox Sandbox Lifecycle: Pause and Resume

ArcBox: Choose the Right Workload Boundary

Checkpoint: choosing the right boundary

A runtime is a stack of contracts

FAQ