Three different answers to "how do I get a Linux kernel on this Mac"

All three tools solve the same underlying problem — macOS has no Linux kernel of its own, so running Linux containers means getting one from somewhere — but they solve it differently enough that "which is fastest" undersells the actual differences. Docker Desktop and OrbStack both run every container inside one shared Linux VM; Apple's own tool, reaching a stable 1.0 in June 2026 after its WWDC 2025 introduction, gives each container its own dedicated, lightweight VM instead, built directly on Virtualization.framework — the architecture covered in full in the companion post.

What Apple's tool actually gets right

  • Stronger isolation by default, with no extra setup. Every container getting its own VM instead of sharing one means a kernel-level compromise in one container doesn't automatically reach the others — the same isolation-tier distinction this blog's security deep dive covers for containers vs. VMs generally, except here it comes free with the default configuration rather than requiring you to reach for it.
  • Genuinely fast for what it's built to do. A purpose-built minimal kernel with a small Swift init process is reported to boot in under a second — tuned specifically for spinning up one container quickly, not for general-purpose use.
  • Free and open source, with no commercial-use catch. Apache-licensed, no company-size or revenue threshold that triggers a paid tier the way Docker Desktop's licensing does, no personal-vs-commercial split the way OrbStack's does.
  • OCI-compatible, so existing images and workflows aren't stranded. Docker Hub images run unmodified; anything built with it pushes to any standard registry.

What it's honestly still missing

Worth being direct about this rather than treating a 1.0 release as feature-complete: Apple's tool is Apple Silicon-only, with no path for an Intel Mac. There's no Docker Compose equivalent for orchestrating multi-container setups, and no confirmed native Kubernetes integration — both real gaps if your workflow already depends on either. It's also simply newer, with a far smaller ecosystem of tutorials, Stack Overflow answers, and CI integrations built up around it than Docker has accumulated over a decade. None of that makes it a bad tool; it makes it a young one, in the specific ways young tools are young.

Where Docker Desktop and OrbStack still win

The full comparison covers both in depth, but the short version relevant here: Docker Desktop remains the industry default that every tutorial, CI config, and onboarding doc assumes, with the largest ecosystem by a wide margin and its own newer first-party VM backend (Docker VMM) aimed at closing the performance gap. OrbStack's own published numbers claim substantial filesystem-performance advantages over Docker Desktop's default backend, specifically on small-file and metadata-heavy operations — real numbers worth checking against your own workload rather than assuming they generalize, but a genuine, measured strength of its purpose-built VM implementation. Both also support macOS on Intel; Apple's tool doesn't.

Which one to actually reach for

  • Already deep in Docker's ecosystem — Compose, Kubernetes, CI configs built around it. Stay on Docker Desktop; nothing here is worth the migration friction yet.
  • Want the fastest filesystem performance for a container-heavy local workflow. OrbStack's own benchmarks are worth testing against your specific workload before committing to the subscription.
  • Want free, strong-isolation-by-default containers on Apple Silicon, and your workflow doesn't need Compose or Kubernetes. Apple's container is a genuinely good, no-cost fit — just budget for a smaller ecosystem around it than Docker's.

Related reading: Apple Containers vs. Linux VMs for how Apple's tool relates to a full Velo workspace rather than to other container tools, the full Docker Desktop and OrbStack comparison, and VM vs. container vs. sandbox on macOS for the general isolation primer. Or download Velo Workspaces and try it yourself.