apple/container: Linux VMs on Mac

Overview

`apple/container` separates a portable OCI image from the Mac-side environment that executes it. Its control plane stores durable intent, while a per-container runtime assembles a lightweight Linux VM, process, network, filesystem, and logs. The series follows that path from Dockerfile and BuildKit through layered isolation, explicit host and peer bridges, resource and storage budgets, and the shift to persistent machines or experimental local Kubernetes. It explains what travels with an image, what is recreated on each host, which crossings change trust, and how to diagnose failures by ownership. The judgment is conditional: current materials name macOS 26 as the supported target while macOS 15 is a build floor with documented limitations, and branch or release status can change feature behavior.

Learning outcomes

`apple/container` keeps OCI images portable while supplying a Mac-specific Linux VM and host integration at runtime.
Creation, guest bootstrap, and process start are separate states, so image, VM, process, and control-plane failures need different diagnoses.
Networks, mounts, sockets, SSH forwarding, and virtualization are explicit bridges that change reachability, persistence, or trust.
Application containers, container machines, and experimental local Kubernetes reuse the foundation but preserve different lifecycles and resource costs.

Keywords

apple/containerOCILinuxVMBuildKitvmnetisolationnetworkingstorageKubernetes

Chapters

apple/container: One VM per Container

Why isolation, portability, and host sharing diverge

11 min · Why isolation, portability, and host sharing diverge

11 min

apple/container: Who Owns a Container?

Follow CLI requests through XPC to the guest

10 min · Follow CLI requests through XPC to the guest

10 min

apple/container: Dockerfile to Running Process

Separate image build, VM boot, and PID 1

12 min · Separate image build, VM boot, and PID 1

12 min

apple/container: Isolation Beyond the VM

Capabilities, paths, and deliberate host bridges

11 min · Capabilities, paths, and deliberate host bridges

11 min

apple/container: How the Runtime Fits Together

Classify what travels, crosses, or depends on the host

12 min · Classify what travels, crosses, or depends on the host

12 min

apple/container: Network Paths and Reachability

Guest, host, and DNS paths across vmnet

11 min · Guest, host, and DNS paths across vmnet

11 min

apple/container: Storage and Resource Budgets

Separate guest limits, host pressure, and data lifetime

11 min · Separate guest limits, host pressure, and data lifetime

11 min

apple/container: Machines and Local Kubernetes

Match persistence and orchestration to the workload

9 min · Match persistence and orchestration to the workload

9 min

apple/container: Is the VM Boundary Worth It?

Balance portability, isolation, integration, and overhead

10 min · Balance portability, isolation, integration, and overhead

10 min

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

Plans

Ch.1-3 FreeCh.4-9 Premium

FAQ

What is apple/container?

`apple/container` is Apple’s Swift command-line platform for creating and running Linux containers in a lightweight VM per container on Apple-silicon Macs. It uses OCI-compatible images while keeping kernels, networking, storage, and host access in the Mac-side runtime.

Are apple/container images portable to other runtimes?

Images built or used by `apple/container` are portable to other OCI-compatible runtimes, but their Mac-specific execution environment is not. Host mounts, ports, DNS, kernel behavior, and resource settings are recreated by the destination runtime.

How does networking work in apple/container?

`apple/container` provides vmnet-backed guest networking with separate paths for guest-to-guest, host-to-guest, and guest-to-host traffic. IPs and published ports are live runtime state, DNS needs configuration on the relevant side, and custom networks or peer discovery have macOS-version limits.

When should I choose a machine or local Kubernetes in apple/container?

Choose a container machine when a persistent Linux environment and its services must survive stop and start; choose local Kubernetes when cluster behavior is what you need to test. Use an application container for one process, and note that local Kubernetes is experimental and intended for development and testing.