Containerization is a Swift package for running Linux containers on macOS

Original Article ↗ Hacker News Discussion ↗

Platform and hardware context

  • Runs only on Apple Silicon and recent macOS (15+; full feature set on 26), reinforcing the end-of-life for Intel Macs.
  • Some see this as another nudge to move to M‑series Macs; others talk about repurposing Intel Macs with Linux/BSD (including T2-focused distros) to avoid e‑waste.
  • Used/refurb M1/M2/M3/M4 hardware is viewed as very good value, but Apple’s storage/RAM pricing and base 256GB SSD are heavily criticized.

Relationship to Docker, OrbStack, Podman

  • This is a low-level Swift framework plus a CLI (container) that can run OCI images; conceptually closer to what Docker Desktop sits on top of.
  • Many expect Docker Desktop and third‑party tools (OrbStack, Rancher, Colima, Podman Desktop) could swap their underlying VM layer to Apple’s, keeping their existing UX and Docker socket compatibility.
  • Some hope it will “kill” proprietary Docker Desktop clones on Mac; others argue Docker’s ecosystem, Compose, and socket semantics still make it sticky.

Architecture and performance characteristics

  • Each container runs in its own lightweight Linux VM via Virtualization.framework, with a minimal kernel config and custom init (vminitd).
  • This is explicitly a “one container per VM” model (similar in spirit to Kata/Firecracker), trading resource sharing for stronger isolation.
  • Concerns: RAM overhead (per‑kernel page caches), no true memory ballooning/reclaim yet, and potentially large overhead when many containers are used.
  • At least one report of builds being much slower than Docker for Mac, especially at the image export step.

Developer experience & missing features

  • No systemd inside containers; a custom init is used.
  • No GPU acceleration for Linux guests via Virtualization.framework, limiting ML/gaming scenarios.
  • Docker Compose and broad Docker‑socket compatibility are not there yet; people see an implementation of the Docker API as essential for adoption.
  • Some ask for macOS/Darwin containers for CI and desktop sandboxing; today only full macOS VMs are possible and are constrained by licensing and overhead.

Security, networking, and filesystem

  • One‑VM‑per‑container plus one‑IP‑per‑container is praised as Kubernetes‑like and good for isolation, but raises efficiency questions.
  • Filesystem sharing is expected to leverage existing Virtualization.framework shared-directory mechanisms; people are waiting to see if it improves over Docker Desktop’s historically poor FS performance.

Broader ecosystem implications

  • Many compare this to WSL2: both major desktop OS vendors now ship first‑party Linux-VM-based container stories.
  • Some see this as strengthening macOS as a dev platform for Linux workloads and potentially eroding one of desktop Linux’s key advantages.
  • Speculation about Apple cloud hosting or using this internally (e.g., AI “private cloud compute”), but others call that a stretch based on current info.

Open source stance and community reaction

  • The project (and CLI) are Apache‑licensed and explicitly welcome contributions, which several note as unusually collaborative for Apple outside Swift/WebKit/LLVM.
  • Some FOSS‑leaning developers on macOS view this positively as a sign Apple is engaging more with open ecosystems, even while skepticism about Apple‑specific tooling and long‑term priorities remains.