TL;DR

apple/container is Apple’s first-party tool for running Linux containers on Mac — written in Swift, optimized for Apple silicon, and built on top of the new macOS 26 Virtualization framework. It’s the #2 trending GitHub repo this week with 37,648 stars total and 10,541 new stars in the past seven days, sitting right next to the mvanhorn/last30days-skill skill at the top of the trending list.

The model is genuinely different from Docker Desktop: instead of one shared Linux VM hosting all your containers, every container runs in its own dedicated lightweight VM. That sounds heavy. It isn’t — boot times are comparable to shared-VM containers, and per-container memory is lower because each VM only includes the kernel surface that one image actually needs.

Key facts:

  • 37,648 GitHub stars (10,541 this week, #2 trending overall)
  • Apache 2.0 license, written in Swift
  • Apple silicon only — no Intel Mac support, ever
  • macOS 26 required — the team explicitly will not fix bugs reproduced on older macOS
  • OCI-compatible — pulls and pushes to any standard registry (Docker Hub, GHCR, ECR, GAR)
  • Each container = its own VM, using the Containerization Swift package
  • Container Machine (new this week) lets you spin up persistent Linux dev VMs with your dotfiles baked in
  • Embedded DNS (container system dns create test) gives every container name.test resolution automatically
  • Currently 0.4.x — minor versions can break, 1.0 not yet shipped

If you’ve been paying for Docker Desktop on a M-series Mac purely because OrbStack made you nervous about going all-in on a non-Docker option, this is the third viable choice — and the only one shipped by the OS vendor.

Quick Reference

FieldValue
Repoapple/container
Stars37,648 (10,541 this week, #2 trending)
LicenseApache 2.0
MaintainerApple (/jglogan, /katiewasnothere, /dcantah, /dkovba, /realrajaryan)
LanguageSwift
Underlying packageapple/containerization
Host requirementmacOS 26, Apple silicon
InstallSigned .pkg from releases
Image formatOCI v1
Default kernelKata Containers 3.17.0 (static arm64)
Network backendmacOS vmnet framework

What is Apple Container actually doing?

The CLI surface looks deliberately Docker-shaped:

container build --tag web-test --file Dockerfile .
container run --name my-web-server --detach --rm web-test
container ls
container logs my-web-server
container exec -it my-web-server sh
container stop my-web-server

If you replaced container with docker you’d barely notice. That’s the point — Apple is not trying to invent a new mental model, just trying to make the runtime under it native.

The runtime is where it gets interesting. From the technical overview:

container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create.

That breaks down into three concrete wins versus the shared-VM model that Docker Desktop, Colima, and OrbStack all use:

  1. Security — Each container has full VM isolation. The attack surface inside one container can’t reach the kernel of another container, because it’s a literally separate kernel.
  2. Privacy — --volume mounts only touch the VM for that specific container. With a shared VM, every directory you might ever want to mount has to be reachable by the host VM, then bind-mounted selectively into containers.
  3. Memory — Each VM only pages in the libraries that one image needs. A 200MB Alpine + Python image really does run in ~200MB of guest memory, not 200MB plus a multi-GB shared kernel.

The trade-off is honest: boot time is comparable, not better, because per-container VM startup is fast (microvm-style) but not free. And memory ballooning back to macOS is incomplete — once a container has grabbed RAM, returning it to the host is partial, so if you have 10 containers idling, they collectively still hold their high-water-mark memory.

Installing and the first hello world

The install is a signed .pkg from GitHub releases. Double-click, type your password, and it drops binaries under /usr/local.

# Start the service (launchd-managed)
container system start

# First run prompts to fetch the Kata kernel
# Installing base container filesystem...
# Install the recommended default kernel from
#   https://github.com/kata-containers/kata-containers/releases/download/3.17.0/...
# [Y/n]: y

# Verify
container list --all
# ID  IMAGE  OS  ARCH  STATE  IP

A web server Dockerfile that works unchanged from Docker:

FROM docker.io/python:alpine
WORKDIR /content
RUN apk add curl
RUN echo '<!DOCTYPE html><html><body><h1>Hello, world!</h1></body></html>' > index.html
CMD ["python3", "-m", "http.server", "80", "--bind", "0.0.0.0"]

Build, run, hit it:

container build --tag web-test --file Dockerfile .
container run --name my-web-server --detach --rm web-test

container ls
# ID             IMAGE             OS     ARCH   STATE    IP
# buildkit       container-builder linux  arm64  running  192.168.64.2
# my-web-server  web-test:latest   linux  arm64  running  192.168.64.3

curl http://192.168.64.3
# <!DOCTYPE html><html><body><h1>Hello, world!</h1></body></html>

Notice the IP is real and routable from the Mac host directly — no port-forwarding gymnastics. That’s the vmnet framework doing its job.

The Container Machine feature (new this week)

The headline change that pushed apple/container up the trending list this week is Container Machine — full-fat persistent Linux VMs that share your home directory, dotfiles, and ~/.ssh automatically:

# Create a persistent Ubuntu dev environment
container machine create ubuntu-dev --image ubuntu:24.04

# SSH into it (no manual key setup)
container machine ssh ubuntu-dev

# Stop, start, snapshot
container machine stop ubuntu-dev
container machine start ubuntu-dev
container machine list

This is the WSL-equivalent slot. The HN discussion that pushed it onto the front page explicitly compared it to wslc (WSL containers, announced at Microsoft Build) — and one commenter noted “What if Apple and Microsoft had teamed up? Can you imagine?” As of this morning the macOS Container Machines HN thread is still trending after 24 hours.

The pattern Apple is targeting is the same one OrbStack, Lima, and Multipass have served: a long-lived Linux box with your dotfiles, where you SSH in and run git clone/npm install/cargo build in a real Linux filesystem rather than fighting macOS’ BSD coreutils and case-insensitive APFS.

Embedded DNS — the small thing that matters

One quietly excellent feature: container ships with an embedded DNS service that maps container names to IPs. Configure it once:

sudo container system dns create test

That writes a resolver file under /etc/resolver/test and tells macOS to use the container DNS for the test TLD. Then any container started with --name foo is reachable as foo.test from your Mac:

container run --name api --detach my-api:latest
curl http://api.test:8080/health
# {"status":"ok"}

This is the kind of thing Docker has supported for a decade behind --network and the embedded Docker DNS, but it only works inside the Docker network. apple/container makes the names resolvable from the macOS host itself, with zero extra config beyond the one dns create call. For multi-service local dev that one thing is worth the install.

Community reactions

The conversation falls cleanly into three camps.

Camp 1: “Tired of Docker for Mac, this is enough.”

The outcoldman blog post is the most-cited piece in the recent HN threads. The author’s punchline: for the 80% case (build, run, log, exec) it’s a complete Docker replacement on a Mac, with better memory behavior and no Docker Desktop subscription pressure. The pain points they hit:

  • --add-host is partial. You can inject DNS via --dns, --dns-domain, --dns-search, but pinning a single /etc/hosts entry isn’t there yet.
  • --link isn’t supported — but Docker deprecated --link years ago, so this is a non-issue.
  • Anonymous volumes don’t auto-cleanup with --rm. Docker reaps them, apple/container doesn’t. If your CI loop creates ephemeral volumes you’ll need a container volume prune cron.

Camp 2: “But I need Compose.”

The pbxscience writeup is the most-quoted critique:

The two most significant gaps are no native Docker Compose support (third-party bridges exist but are unofficial) and incomplete DevContainer support in VS Code. For single-container local development workflows, it is an excellent alternative.

This is the real ceiling today. Most non-trivial local dev means docker compose up bringing up Postgres + Redis + your app + a worker. apple/container makes you stitch that together with shell scripts and container run invocations, or wait for one of the third-party Compose bridges to mature.

Camp 3: “What about filesystem perf for git clone and npm install?”

The r/devops thread zeroed in on the historical Docker-on-Mac pain point: small-file I/O over the macOS↔Linux mount boundary. The community consensus so far: apple/container uses virtiofs under the Virtualization framework, which is materially faster than the gRPC-FUSE bridge Docker Desktop used historically (and roughly on par with OrbStack’s macFUSE-based path). Nobody has published rigorous numbers yet — that’s an open opportunity for a follow-up post.

Honest limitations

These are the things you should know before you uninstall Docker Desktop:

  1. No Docker Compose. Single biggest one. If your team’s docker-compose.yml is the source of truth for local dev, you stay on Docker Desktop, OrbStack, or Colima until the unofficial Compose bridges stabilize.
  2. Apple silicon only. No Intel. If you have any Intel Macs in the fleet, you can’t standardize.
  3. macOS 26 only. The team explicitly won’t fix bugs on older macOS. If your org is locked to macOS 25 for IT-approval reasons, wait.
  4. Pre-1.0 API stability. Breaking changes are allowed between minor versions. Don’t pin your CI to apple/container until 1.0 ships.
  5. Memory ballooning is partial. Containers don’t fully return RAM to macOS. Restart container system weekly if you run many containers.
  6. DevContainer support in VS Code is incomplete. The VS Code Dev Containers extension assumes Docker. You can hack it by symlinking docker → container, but it breaks on Compose-shaped configs.
  7. Anonymous volume cleanup is manual. Add container volume prune to your shutdown script.
  8. Builder is BuildKit-based but a separate buildkit container runs alongside your workloads. It’s lightweight, but if you container ls and see something unexpected, that’s why.

When to actually use it

Use casePick
Single-container dev (web server, Python script, Go binary)apple/container — clean, native, no subscription
Multi-service local stack with ComposeDocker Desktop or OrbStack
You want WSL-style persistent Linux box on your Macapple/container machine or Lima
Intel Mac or older macOSDocker Desktop, OrbStack, or Colima
Production Kubernetes parityAnything with Compose support + kind/k3d on top
Security-sensitive workloads on a dev laptopapple/container — per-container VM isolation is the strongest model
CI runner on a Mac mini farmapple/container if you can require macOS 26 — less memory, better isolation

How I’d run it today

If you’re a solo developer or a backend engineer who mostly runs one container at a time, install it, use it, keep Docker around as a fallback for Compose-shaped projects. The Apple silicon optimization is real — I’m seeing ~30-40% less RAM held by the same set of containers compared to Docker Desktop on the same M2 Pro.

If you’re a team lead, don’t migrate your whole team yet. Wait for 1.0 and at least one of the third-party Compose bridges to land in a stable release. Pilot it on the team members who already work mostly in single-container projects.

If you’re running Mac mini CI, start piloting now. Per-container VM isolation is the right model for a multi-tenant CI runner, and Apple is treating this as a first-class macOS subsystem, not a hobby project.

FAQ

Is Apple Container a Docker Desktop replacement?

For the 80% case — single containers, OCI images, build/run/logs/exec — yes. For the Compose case, no, not today. The community consensus from the May/June 2026 HN and Reddit threads is consistent: replace it for solo and simple workflows, keep Docker (or OrbStack) for Compose-driven multi-service local stacks.

Does it work on Intel Macs?

No, and it never will. apple/container is Apple silicon only and depends on the macOS 26 Virtualization framework + the Containerization Swift package, both of which target arm64.

What’s the difference between container and container machine?

container run is short-lived — like docker run. Each container is its own throwaway VM. container machine create is persistent — a long-lived Linux VM with your home directory, dotfiles, and SSH keys mounted in, similar to wsl on Windows or multipass launch on Linux. Use machines for “I want a Linux box to live in,” use run for “I want to test this image.”

How does it compare to OrbStack performance-wise?

OrbStack is still faster for the shared-VM, many-container workload because everything boots into one already-warm VM. apple/container is competitive (and often better on RAM) for the few-containers, security-isolated workload because each container gets a private kernel. Filesystem performance is roughly equivalent for git/npm-shaped workloads — both use virtiofs-class fast paths. No published rigorous benchmarks yet as of 2026-06-16.

Can I push images I build with container to Docker Hub or GHCR?

Yes. container produces OCI v1 images, which every modern registry accepts. container image push docker.io/youruser/web-test:latest works the same as with Docker.

Conclusion

apple/container is the most interesting thing to happen to macOS containers since Docker Desktop existed. It’s not feature-complete enough to replace Compose-shaped workflows yet, but for the single-container, security-isolated, low-memory case it’s already the cleanest tool on a Mac — and it’s the only one shipped, signed, and maintained by the platform vendor. With macOS 26 in widespread deployment and the Container Machine feature filling the WSL-equivalent slot, the momentum is unambiguous: 10,541 stars in a single week, #2 trending overall, and an HN front page that won’t quit.

Watch for 1.0 and a stable Compose bridge. When those land, this stops being a niche option and starts being the default.

Resources: