Apple’s new “container machines” extend its earlier containerization work into something closer to a lightweight, long-lived Linux dev box on macOS. Under the hood it is still virtualization. Each container runs in its own small Linux VM rather than sharing one big Linux VM like Docker Desktop or Colima often do. Apple pitches that as a better balance of isolation, privacy, and startup time, with support for persistence, filesystem mounts, and even systemd when the guest image includes it. That framing mattered because many readers initially assumed this was just another OCI runtime or a native Darwin container system. It is neither. It is an Apple-managed way to run Linux workloads on a Mac with less visible VM friction.
The reaction was enthusiastic about Apple finally taking this use case seriously, but not convinced the new tool is ready to displace what people already use. The strongest consensus was that this is basically “
WSL2 for macOS,” which is useful because modern development targets Linux far more than generic
POSIX. That also explains why Apple chose virtualization instead of chasing a
WSL1-style syscall compatibility layer. Several comments argued that once developers need
cgroups,
namespaces, systemd, and exact Linux kernel behavior, emulation becomes a maintenance trap and a source of weird breakage. A tiny VM gets you the real thing.
Where the conversation got practical was around tradeoffs versus existing tools. OrbStack came up constantly because many people already see it as the best Mac container experience. Its developer said OrbStack uses a custom virtualization stack and custom filesystem sharing, with the biggest advantage being dynamic memory that can be returned to macOS. Apple’s stack can grow guest memory with
ballooning but cannot shrink it back yet, and sparse disks do not shrink conveniently either. That turned memory pressure into the clearest functional gap, especially for laptop users who leave dev environments running all day. Filesystem performance was the other recurring pain point. Readers noted that Mac host-to-Linux guest mounts have historically been slow enough to break Node and other small-file-heavy workflows. Apple uses
virtiofs for host mounts, but several people doubted this alone changes the underlying reality much.
The other major theme was that Apple built the one Linux feature everyone can approximate, while still not building the one thing only Apple could uniquely provide: strong native macOS containers or jails. That complaint was especially sharp from people running macOS
CI for iOS or Mac builds, where Apple still forces real Macs, limits VM use, and leaves teams stitching together expensive workarounds. So the new feature was seen as valuable for Linux-on-Mac development, but also as an implicit admission that macOS is not where modern server-side workflows live.
Overall mood was positive about the direction and skeptical about version one. People expect it to become a solid platform primitive that
Podman, Docker-adjacent tools, and agent sandboxes can build on. Right now, though, existing users of OrbStack,
Lima, Colima, Multipass, or Podman mostly saw no urgent reason to switch unless Apple closes gaps around memory reclamation, networking, USB and
GPU passthrough,
DNS reliability, and higher-level workflow support like
Compose-style multi-service setups.