Containers & virtual machines

Every container on a Mac runs inside a Linux virtual machine — macOS has no Linux kernel. What differs between tools is how many VMs, how fast the file sharing is, how much memory sits idle, and what it costs. 2026 added a genuinely new option: Apple's own container tool, which runs one lightweight VM per container. This chapter picks a default, explains the trade-offs, and covers full VMs for Linux and Windows.

The landscape in September 2026#

Recommendation: OrbStack for students and solo developers (free) and for anyone whose company will pay $8/mo. Keep the docker CLI you already know; everything in every tutorial works unchanged. Add Apple container as a side tool to learn and for isolated single containers; watch it for Compose support. Use Docker Desktop when an employer supplies a licence or you need its enterprise features. Use Colima if you want zero GUI.

OrbStack setup#

brew install --cask orbstack
orb                      # first run creates the VM and installs docker/kubectl CLIs into /usr/local/bin & ~/.orbstack
docker run --rm -it alpine uname -m      # aarch64 — you're native
docker context ls        # "orbstack" is default

Settings (menu bar → Settings): Resources: leave memory at dynamic (OrbStack grows and shrinks; cap at half your RAM if you like); Docker → Rosetta: on (so linux/amd64 images run at near-native speed via Rosetta for Linux, which is unaffected by the macOS 28 Rosetta removal); Network: enable Access container domains so every container is reachable at http://<container>.orb.local with automatic HTTPS; Kubernetes: turn on when needed (a single-node cluster in seconds, kubectl context orbstack).

Linux machines (orb create ubuntu, orb create -a amd64 debian) give you full distros with shared home directory, ssh, and a mac command to call back into macOS. This is the easiest Linux environment on a Mac for a systems course — lighter than a VM, more complete than a container.

Docker Desktop setup (if you use it)#

brew install --cask docker-desktop. Settings: Resources → Memory: 6–8 GB on a 16–24 GB Mac (containers get this memory, not the host's), CPUs: half your cores, Swap: 1 GB, Disk image size: 64 GB+; General: Use Virtualization framework (default), VirtioFS file sharing (default), Use Rosetta for x86_64/amd64 emulation on Apple Silicon: on; Kubernetes: off unless used; Software updates: on. Quit Docker Desktop when you're not developing — it holds its memory reservation.

Apple container (Tahoe+)#

brew install container                # or the signed .pkg from github.com/apple/container/releases
container system start                # installs a Linux kernel image on first run
container run --rm -it alpine sh
container build -t myapp .            # OCI images; Dockerfiles work
container run -d --name web -p 8080:80 nginx
container list                        # ps
container logs web
container system stop

Each container is its own lightweight VM booting a minimal Linux (sub-second), which gives kernel-level isolation between containers — a real advantage when you run untrusted or security-sensitive code. Images are standard OCI (pull from Docker Hub/GHCR; push too). Limits in mid-2026: no compose, no Kubernetes, CLI only, macOS 26+ for full networking (container-to-container IPs), Apple silicon only, and bind-mount performance is less benchmarked than OrbStack's. Apple ships releases every few weeks; check the README for what's landed.

Multi-architecture: arm64 vs amd64#

Your Mac runs linux/arm64 containers natively. Most official images (Postgres, Redis, nginx, Node, Python, Go, Debian, Ubuntu, Alpine) are multi-arch and just work. When an image is amd64-only (some vendor images, older internal ones), Docker/OrbStack run it under Rosetta or QEMU — slower and occasionally buggy (segfaults in JIT-heavy runtimes, qemu: uncaught target signal).

• Check: docker image inspect img --format '{{.Architecture}}' or docker manifest inspect img.
• Force: docker run --platform linux/amd64 img for a one-off; in Compose, platform: linux/amd64 on the service.
• Build for production servers (usually amd64) from your Mac: docker buildx build --platform linux/amd64,linux/arm64 -t you/app:tag --push . — buildx uses QEMU (installed automatically) or, better, a remote/native builder. For Go/Rust, cross-compile the binary natively and copy it into a scratch image instead of emulating the compiler.
• Dev containers and CI parity: if your CI is amd64 and you develop arm64, pin base images by digest and run the test suite in both; native-extension packages (Python wheels, Node .node files) differ per arch — never copy a node_modules or .venv into an image, install inside it.

Docker Compose patterns for local development#

A typical project's compose.yaml (the modern filename; docker-compose.yml still works):

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: app_dev
    ports: ["5432:5432"]
    volumes: ["pgdata:/var/lib/postgresql/data"]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
  redis:
    image: redis:7-alpine
    ports: ["6379:6379"]
  app:
    build: .
    command: pnpm dev
    volumes:
      - .:/app                       # bind mount source for hot reload
      - /app/node_modules            # …but keep node_modules inside the container (arch!)
    ports: ["3000:3000"]
    environment:
      DATABASE_URL: postgres://app:app@db:5432/app_dev
    depends_on:
      db: { condition: service_healthy }
volumes:
  pgdata:

docker compose up -d, docker compose logs -f app, docker compose exec app sh, docker compose down -v (also deletes volumes). Use docker compose watch for file sync/rebuild rules. Many developers run only the databases in Compose and the app natively via mise — faster iteration, native debugger, no bind-mount overhead (Chapter 15).

Dev Containers (.devcontainer/devcontainer.json, VS Code / Cursor / JetBrains / GitHub Codespaces) package the whole toolchain in a container so a course or team gets an identical environment on any OS. OrbStack and Docker Desktop both work as the backend.

Housekeeping#

Images and build cache grow silently. Monthly:

docker system df                       # what's using space
docker system prune -a --volumes       # everything unused (asks first; volumes too — be sure)
docker builder prune                   # build cache only
docker image prune -a                  # dangling + unused images

OrbStack shows its total in the menu bar; Docker Desktop's VM disk image lives at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw and only shrinks on prune. Exclude these VM images from Time Machine (Chapter 17).

Kubernetes locally#

• OrbStack: toggle Kubernetes in settings — a real single-node cluster, kubectl config use-context orbstack.
• kind (brew install kind): multi-node clusters in Docker; what most Kubernetes courses use.
• minikube (brew install minikube) with the docker or vfkit driver; k3d for k3s-in-Docker; Rancher Desktop for a GUI.
• Tools: kubectl (brew install kubectl), k9s (TUI), helm, kubectx/kubens, stern (multi-pod logs), kustomize, skaffold/tilt for dev loops. Lens or Headlamp for a desktop GUI.

Full virtual machines#

For a whole Linux desktop, a different kernel, Windows, or an x86 OS, you want a VM, not a container.

Windows on Apple silicon: Windows 11 ARM is the only Windows that runs; it's a full Windows with excellent x86/x64 app emulation (Prism), and Microsoft officially licenses it in Parallels/VMware. Get the ISO from Microsoft's site (Windows 11 Arm64 ISO) or let Parallels download it. Performance is very good for Office, Visual Studio, and most dev tools; games with anti-cheat and some drivers don't work. A Windows licence key is needed for activation (students often get one via Azure Dev Tools for Teaching).

x86 Linux (for an assembly course, a binary that only exists as x86, or matching a server exactly): UTM with QEMU emulation works but is ~5–10× slower than native. For anything sustained, use the department's servers, a cheap cloud VM, or OrbStack's -a amd64 machines (Rosetta-accelerated user-space; the kernel is arm64, which is fine for user programs but not for kernel courses).

Asahi Linux (bare-metal Fedora on Apple silicon) supports M1 and M2 only — not M3/M4/M5/M6. For everyone else, Linux in a VM or OrbStack machine is the answer.

Nix and reproducible dev shells#

Worth a mention for the reproducibility-minded: the Determinate Nix installer (curl … | sh -s -- install) installs Nix cleanly on macOS with a separate APFS volume; nix develop / devenv / flox give per-project shells with pinned compilers and libraries — an alternative to both containers and mise for native development. Steep curve; enormous payoff if a whole team adopts it. Don't start here as a first-year.

Choosing, by scenario#

• Web/backend student, coursework uses Docker: OrbStack. Done.
• Security or systems course, want strong isolation: Apple container for individual services; UTM for full Linux.
• Kubernetes course: OrbStack Kubernetes or kind; k9s.
• Need Windows for one course (Visual Studio, .NET Framework, Office macros): VMware Fusion (free) or Parallels (student price) with Windows 11 ARM.
• x86 assembly or a kernel course: UTM QEMU x86 VM (slow but correct) or the university's Linux servers over SSH.
• Company policy says Docker Desktop: Docker Desktop with Rosetta on and the memory cap set.
• Want to test dotfiles on a fresh macOS: tart macOS VM.