When a container is not enough: Linux machines and macOS guests
ArcBox's machine tiers answer requirements that the container and sandbox contracts deliberately do not: ownership of a complete operating system, a persistent machine identity, or a guest OS that is itself macOS. This chapter compares full Linux machines with disposable macOS guests, focusing on kernel and disk ownership, image provisioning, network identity, hardware constraints, and trust. The goal is not to crown a universal “strongest” tier, but to identify the requirement that makes each boundary the honest choice.
The Linux machine boundary
A Docker-compatible container is organized around an engine contract. The user asks dockerd to create and manage a workload, and ArcBox's System VM supplies the Linux environment in which that engine runs. A sandbox moves the workload into a nested Firecracker microVM, but its main object is still a disposable workload with an explicit lifecycle. A full Linux machine changes the object under discussion: the machine itself has its own kernel, persistent disk, and chosen distribution.
That distinction matters whenever the application depends on operating-system behavior rather than only on a container image. A kernel feature, a distribution-specific userland, a boot configuration, or a long-lived machine filesystem can be part of the test or development environment. Putting the process in a container does not give it a different guest kernel. Putting it in a sandbox gives a stronger disposable boundary, but it does not automatically make the sandbox the right place to manage a persistent Linux installation. A machine tier makes those requirements explicit in the machine record and its disk.
The user-facing operations follow from that identity. ArcBox can create and manage a named Linux VM, start and stop it, inspect its state, mount a host directory, open an interactive SSH session, or execute a one-shot command. The repository identifies Ubuntu and Alpine as working distributions for this surface. These operations are not merely a larger version of docker exec: the machine has a lifecycle independent of any one workload, and its persistent disk is part of what the user chose to retain.
The broader runtime still supplies common machinery. The machine manager keeps records and coordinates the VM manager; the selected backend constructs the guest with a kernel, block devices, networking, and optional vsock or shared directories. But the machine's state is not hidden behind the Docker proxy. A user starts the named machine because the machine is the object they want, whereas the System VM starts automatically to make container operations available. That difference affects failure handling and cost: a container request can wait on the shared System VM, while a full machine may remain stopped until its owner starts it.
A full machine is therefore not automatically “more isolated” in every practical sense. It has a VM boundary and its own kernel, but its disk may be persistent, its directory mounts may intentionally connect it to the host, and the daemon still controls its lifecycle. A sandbox is more directly optimized for short-lived untrusted code: its state can be given a TTL or idle policy, its network exposure is controlled by a dedicated API, and its workload record is separate from the client connection. The choice depends on whether the primary risk is shared engine state, untrusted execution, missing kernel control, or the need for a durable operating-system environment.