OrbStack vs Apple Containers vs Docker on macOS: How They Really Differ Under the Hood

on your Mac matters a lot. Over the last few years, I’ve bounced between three worlds:

• “Plain” Docker (the engine we all started with, not just Docker Desktop),
• OrbStack, which is my current daily driver,
• and, more recently, Apple’s new container tool (“Apple containers”), which I’m genuinely considering switching to.

This isn’t a benchmark post (yet), and it’s not about Docker Desktop’s UI. It’s about how these three approaches actually work under the hood on macOS – and why that makes Docker feel heavy, OrbStack feel light, and Apple containers surprisingly snappy in some workflows.

Why I Stopped Using Docker Itself on macOS

On Linux, Docker feels almost invisible: it’s “just” a daemon managing Linux processes and namespaces.

On macOS, things are very different.

Docker’s architecture on a Mac

Docker containers are Linux processes. macOS is not Linux. So to run Docker on a Mac, you have to put a Linux VM in the middle. Roughly, the stack looks like this:

1. A Linux VM in the middle
Docker Desktop (or similar setups) boots a lightweight Linux virtual machine on top of macOS. The Docker Engine daemon runs inside that VM.
2. CLI on macOS → daemon in the VM
Your docker / docker compose commands talk over a socket into the VM. The UX feels native, but all the real work happens in that Linux guest.
3. File sharing bridge
Your source code lives on macOS, but containers run in Linux. To make /Users/... available inside containers, Docker uses a filesystem bridge (historically osxfs, then newer approaches like gRPC-based file sharing or virtiofs).
No matter how you slice it, there’s overhead: reads and writes bounce through extra layers, which you really start to feel with big repos or monorepos.
4. Performance side effects

• A background VM consuming RAM and CPU.
  • Slow bind mounts for large projects.
  • Fans spinning up on big builds, even when you’re “just” doing dev work.

People have built workarounds (syncing code into the VM, relying heavily on named volumes, etc.), but the fundamental constraint is the same: on macOS, Docker is always running inside a VM, and that VM is not cheap.

That’s the main reason I, personally, backed away from using Docker itself on my Mac as my primary solution. It works. It’s ubiquitous. But it feels heavier than it should.

OrbStack: My Fast, Docker-Compatible Daily Driver

Enter OrbStack – the tool I’ve been living in for most of my day-to-day development.

OrbStack positions itself as “the fast, light, and easy way to run Docker containers and Linux machines” and a “supercharged alternative to Docker Desktop and WSL”.

In practice, that’s mostly how it feels.

What OrbStack actually does under the hood

OrbStack also runs containers inside a VM – there’s no magic way around that on macOS. But the way it’s architected is noticeably more tuned:

• Lightweight VM, optimized for Apple Silicon OrbStack runs containers and Linux machines inside a highly optimized VM with low resource usage and tight integration with macOS.
• Native Swift app The macOS app itself is written in Swift and feels like a real native app instead of a generic cross-platform wrapper.
• Optimized file sharing and networking OrbStack includes custom file-sharing and networking layers designed specifically to avoid the classic “bind mounts are slow on Docker for Mac” problem. This is one of the most significant differences you actually feel day to day.
• Fast startup and low idle overhead Startup is fast, idle CPU is low, and battery usage is noticeably better than the traditional Docker setup on macOS.

Most importantly: OrbStack implements the Docker API, so your existing Docker tooling basically just works. You keep using:

• docker,
• docker compose,
• your existing images and registries,
• your docker-compose.yml and scripts.

All your muscle memory and your current workflows carry over with almost no changes.

How OrbStack feels in real workflows

In real life, OrbStack shines when I’m:

• Running multiple docker compose up stacks at once,
• Working in large codebases with bind mounts,
• Doing tight docker build loops for dev images.

Things that would previously throttle I/O or peg the CPU with Docker’s default stack now feel… normal. It’s not sci-fi magic, it’s just what I wish Docker had felt like on macOS from the start.

That’s why OrbStack became my default:

Docker compatibility + tuned VM + better file sharing = “it just works, and it’s fast enough”.

Apple Containers: A Different Take on Containers on macOS

Then Apple launched something interesting: the container tool and the underlying Containerization Swift package.

This is not “Docker from Apple.” It’s a different take on running Linux containers on macOS, designed specifically for Apple Silicon and built on top of Apple’s own Virtualization framework.

What Apple’s container actually is

Apple’s container project is:

• A CLI tool written in Swift, open source,
• Optimized for Apple Silicon,
• Designed to consume and produce OCI-compatible images (so you can still pull from Docker Hub or any other standard registry).

The key architectural twist is how it uses virtualization.

Micro-VMs instead of one big component VM

While Docker and OrbStack run many containers inside a single Linux VM, Apple’s approach is different:

• The container CLI uses the Containerization framework to spin up lightweight virtual machines for each container.
• You can think of these as micro-VMs: tiny, fast-booting VMs that run one container each, with strong isolation and tight integration with macOS.

So instead of one big VM doing everything, you get multiple minimal VMs, each focused on a single container.

OS requirements and maturity

Currently, the story looks like this:

• Native container support is rolling into newer macOS releases, with more first-class integration coming in future versions.
• You can already use the container CLI on recent macOS releases, but the ecosystem and UX are still evolving.

So we’re in this early but exciting phase where:

• The tooling is real and usable,
• But it’s clearly aimed at a future where containers are a first-class citizen of macOS itself.

How Apple containers feel in practice (so far)

I’ve been trying to mirror my OrbStack workflows with Apple containers as much as possible:

• Image handling is smooth Because it’s OCI-native, standard images from Docker Hub or GHCR just work. Pull, run, push – nothing exotic needed.
• Startup feels very fast Those per-container lightweight VMs start quickly. For simple services and one-off containers, Apple container often feels as fast or even faster than OrbStack.
• Tooling is still young The CLI and surrounding ecosystem aren’t as mature as the Docker ecosystem or OrbStack’s UX. You don’t get a polished desktop app or a “drop-in Docker replacement” experience yet. You’re closer to the primitives.

And here’s the important warning:

I haven’t done proper benchmarks yet – just subjective comparisons from daily use. I do plan to measure builds, I/O-heavy workloads, and startup times properly, but for now, it’s mostly “how it feels”.

OrbStack vs Apple Containers vs Docker: Architecture & Workflow Differences

From a technical and workflow perspective, here’s how I see the differences right now.

Virtualization model

Docker on macOS

• Runs a single Linux VM (often based on LinuxKit).
• Docker Engine runs inside that VM.
• All containers live in that same VM.

OrbStack

• Also uses a single, highly optimized VM for containers and Linux machines.
• Focus is on performance and Mac integration rather than just “make it work”.

Apple container

• Uses multiple lightweight VMs – one per container.
• Each container is effectively its own tiny virtual machine, managed by the Containerization framework.

This micro-VM model explains why Apple containers can feel so quick for isolated workloads: each container gets its small, focused environment instead of competing inside one big VM.

File system & I/O

Docker on macOS

• Uses various file-sharing mechanisms to expose macOS directories into the Linux VM.
• These bridges introduce latency and overhead, especially with large trees and many small files.

OrbStack

• Still has to bridge macOS and the VM, but with custom, highly optimized file-sharing layers.
• In practice, bind mounts and day-to-day I/O feel much better than stock Docker on macOS.

Apple container

• Built around Apple’s Virtualization framework from day one, with micro-VMs tuned for fast boot and efficient disk access.
• In some workflows, this translates into rapid startup and snappy file access, especially when you’re not juggling a huge number of containers.

Compatibility & ergonomics

Docker

• Maximum ecosystem compatibility.
• Everything assumes a Docker daemon is available.

OrbStack

• Implements the Docker API.
• For most real-world use cases, it’s a drop-in replacement for Docker Desktop on macOS.
• You can keep your existing docker commands, scripts, and configs.

Apple container

• Not a Docker daemon. It’s OCI-compatible, but the interaction model and UX are different.
• You may need to adjust scripts and workflows instead of expecting Docker-style commands to map 1:1.

So… Should You Switch?

Here’s where I land right now.

My current stance

• OrbStack is still my main recommendation today. If you want Docker compatibility with a fast, light, Mac-optimized experience, OrbStack is hard to beat right now. It respects your battery, your fans, and your time, while letting you keep your existing Docker workflows.

• Apple containers are the thing to watch.
  Apple’s container tool plus the Containerization framework feel like the future direction of containerization on macOS:

  • First-party, OS-integrated container story,
  • Designed for Apple Silicon and Virtualization.framework,
  • Already usable, and likely to get better with each macOS release.

In some workflows I’m already seeing Apple containers feel faster than OrbStack, which is impressive given how optimized OrbStack already is. That’s enough for me to plan proper benchmarks and keep experimenting.

My recommendation

If I had to compress it into one sentence:

Use OrbStack today for a great Docker-compatible experience on macOS, but keep a close eye on Apple containers — they might become the definitive container solution for the Mac in the following years.

For now, I’m happily running OrbStack as my daily driver and experimenting with Apple container on the side. As Apple keeps improving the tooling and the OS-level integration, I wouldn’t be surprised if, a couple of macOS releases from now, the “default” dev story on Mac shifts from “install Docker Desktop” to “turn on native containers”.