macOS Container Machines

What Apple’s “container machines” are

• Built on Apple’s Containerization / Virtualization frameworks; each container is actually its own lightweight Linux VM (micro‑VM).
• Closer to WSL2, toolbox/distrobox, or “LXC via VMs” than to classic shared‑kernel containers.
• Adds persistence and host filesystem mounting on top of the existing container CLI.
• Uses virtiofs for host mounts; default Linux kernel is from Kata Containers.
• Supports systemd and “real Linux services” if the base image includes an init system.

Comparison with Docker/Podman/Colima/OrbStack

• Intended as a native alternative to Docker Desktop’s single big VM; per‑container VMs improve isolation and privacy.
• Still needs a Linux VM, so it does not eliminate the VM layer the way some people hoped.
• Colima/Podman/Lima remain viable, with broader ecosystem and Docker Compose support.
• OrbStack is frequently praised: custom Rust-based virtualization, dynamic memory reclaim, optimized filesystem sharing, USB/audio passthrough, isolated machines.
• Several commenters say they’ll stick with OrbStack/Colima for now; Apple’s tooling feels less integrated and less feature‑rich.

Performance, resources, and filesystem behavior

• Memory defaults to half of host RAM, with ballooning to grow but not yet shrink; sparse disk images also don’t shrink easily.
• Concern that this can be RAM‑heavy compared to traditional containers; some argue micro‑VMs are still lighter than full VMs.
• Prior versions of Apple containers had slow filesystem performance for workloads with many small files (Node/Rust); unclear if this is now fully resolved.
• QEMU is considered slower than Apple’s native virtualization, but Lima can target the native framework too.

Platform support and limitations

• Optimized for Apple Silicon and macOS 26 (“Tahoe”); works on macOS 15 with networking limitations and no backport fixes planned.
• Underlying virtualization exists on Intel, but new features will target Apple Silicon and newer macOS only.
• Linux guests only; no macOS-in-container support despite strong demand for macOS CI and “Darwin jails.”
• Rosetta in the virtualization stack lets aarch64 Linux VMs run amd64 binaries; Rosetta for Linux is expected to stay even as mac app Rosetta is removed.

Use cases and workflows

• Main target: local Linux dev environments on macOS—databases, background services, devcontainers‑style setups.
• Some see it as a good sandbox for untrusted code and AI coding agents, a spiritual successor to sandbox-exec but with VM isolation.
• People ask how to replicate multi‑service Docker Compose setups; no first‑class Compose story yet, though tooling could be built atop the OCI pieces.
• Interest in using it for AOSP builds, GPU/LLM workloads, and as a more “invisible” Linux layer like WSL; GPU passthrough and x86 story beyond Rosetta are unclear.

Security, isolation, and UX debates

• Per‑VM containers are seen as stronger isolation than shared‑kernel containers, but some argue containers in general are not a primary security boundary.
• Default auto‑mount of $HOME divides opinion: convenient for most dev workflows, undesirable for those aiming at strict supply‑chain isolation.
• Some want easy toggles for no host mounts and more fine‑grained isolation knobs.

Missing pieces and recurring wishes

• No Darwin namespaces / macOS containers; many view this as a deliberate business decision to preserve Mac hardware sales for CI and build farms.
• No official bridge networking, VPNKit/gVisor‑like network stack, or USB passthrough from Apple’s side; third‑party tools are ahead here.
• People request better docs on when to choose Apple’s solution vs Docker/Colima/OrbStack, and benchmarks comparing all options.