ArcBox: One Runtime, Four Boundaries

Overview

This series examines how ArcBox puts Docker-compatible containers, disposable Firecracker sandboxes, full Linux machines, and macOS guests behind one macOS-first daemon. It follows the System VM, Docker routing, sandbox lifecycle, data and warm starts, machine identity, performance, cleanup, trust, and fleet direction to show where shared tooling helps—and where each tier's isolation, capability, maturity, and host-trust limits remain distinct.

Learning outcomes

ArcBox makes four workload boundaries available through one daemon, but shared tooling does not make them equivalent.
The System VM reduces duplicated infrastructure while concentrating readiness, networking, asset, and recovery dependencies.
Choose containers for Docker compatibility, sandboxes for disposable isolation, Linux machines for kernel or distro ownership, and macOS guests for macOS itself.
Measured speedups and warm starts are path-specific; host trust, hardware limits, cleanup, and beta maturity still constrain the platform.

Keywords

ArcBoxcontainerssandboxesDockerFirecrackervirtualizationLinuxmacOSisolationSystem VM

Chapters

ArcBox Isolation Levels Explained

Match workloads to their OS and lifecycle boundary

9 min · Match workloads to their OS and lifecycle boundary

9 min

ArcBox System VM: Boot and Readiness

Ownership, verified assets, and backend choices

12 min · Ownership, verified assets, and backend choices

12 min

ArcBox Docker Compatibility Path

How the Docker API crosses the VM boundary

11 min · How the Docker API crosses the VM boundary

11 min

ArcBox: Choose the Right Workload Boundary

Interface, isolation, ownership, and lifecycle

9 min · Interface, isolation, ownership, and lifecycle

9 min

ArcBox Sandbox Lifecycle: Pause and Resume

From Firecracker boot to reconnectable execution

11 min · From Firecracker boot to reconnectable execution

11 min

ArcBox Sandbox Workflow: Data and Warm Starts

Networking, snapshots, and bounded transfers

9 min · Networking, snapshots, and bounded transfers

9 min

ArcBox Linux Machines and macOS Guests

Kernel ownership, APFS clones, and host trust

9 min · Kernel ownership, APFS clones, and host trust

9 min

ArcBox Unified Runtime: Benefits and Limits

Performance, trust, cleanup, and fleet reality

16 min · Performance, trust, cleanup, and fleet reality

16 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

What does ArcBox actually unify?

ArcBox unifies its daemon, boot assets, lifecycle, storage records, host networking, readiness, transport, and cleanup; it does not give every workload the same VM, API, or guarantee.

Which ArcBox tier fits a workload?

Choose containers for Docker and Compose compatibility, sandboxes for disposable or untrusted workloads, Linux machines for a persistent kernel or distribution, and macOS guests when the workload must run macOS. Check backend, hardware, storage, and lifecycle constraints before choosing.

Can ArcBox replace Docker Desktop for local development?

ArcBox can support Docker-shaped local workflows through a Unix socket, selective host routing, and guest dockerd. Its documented surfaces include commands, Compose, builds, ports, volumes, interactive execution, and Kubernetes, but compatibility does not promise every Docker Engine detail.

Are ArcBox's performance and security guarantees universal?

No; ArcBox's performance and security guarantees are not universal. Network and filesystem measurements are scoped to documented backends and workloads, while disposable guests can separate jobs from prior state without hiding them from the host. Public-beta status and hardware, cleanup, and remote-support limits remain relevant.