macOS Container Machines

Original Article ↗ Hacker News Discussion ↗

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.