dd — VM-less native JIT containers for Mac

If you run containers on a Mac, you've probably made quiet peace with a background Linux VM. Docker Desktop boots one. So do Colima and OrbStack. It starts when your Mac wakes, holds onto a few gigabytes of RAM whether you're using it or not, and keeps ticking on the train while you're not running anything at all.

None of those tools is doing it wrong — a VM has been the only practical way to run Linux containers on macOS. But it's a tax you pay all day, not just when you're working. I got tired of paying it, so I spent a while building dd to try a different approach:

A container is just a process with a different view of the system. So run it as one — not inside a virtual machine.

This is a short writeup of why I think the VM is worth dropping, how dd drops it without breaking what makes a container a container, and the numbers I measured — including the parts where it loses.

What the VM costs you every day

Most of the small daily annoyances of containers-on-a-Mac trace back to one thing: the always-on VM in the middle.

Remove the VM and that list doesn't get shorter — it goes away. A container becomes a normal macOS process: no RAM held when idle (it's freed on exit), nothing to boot, bind mounts straight to the real filesystem, ports straight to host sockets. And because it's a plain process, it shows up in Activity Monitor like anything else.

How it works

The trick, in one sentence: a container doesn't need Linux, it needs the Linux kernel interface. The code in an image is just normal compute. The only thing that makes it "Linux" is that, now and then, it asks the kernel for something — open a file, bind a socket, fork. Those are syscalls.

So dd runs the container's compute as native Apple-Silicon code, and answers every syscall in userspace with code that is the kernel — namespaces, image layers, the network stack are just data structures in a normal Mac program. (If that sounds familiar, it's the gVisor / PRoot lineage, aimed at the desktop instead of the server.)

arm64 images run as native code. x86-64 images go through a JIT that rewrites x86 into arm64 the first time a block runs and reuses it after — the same idea as a language VM, applied to machine code. Most of the work is in the details: chaining hot blocks so they never return to the dispatcher, mapping guest returns onto the CPU's real return predictor, and serving the syscalls a container hammers (stat, path lookups, clock_gettime) inline so they never cross to the host.

Is it actually fast?

Ten workloads, the same static binary timed two ways, median of 7. For x86-64 images the fair comparison is the same binary emulated by qemu inside a VM — what VM-based Docker falls back to for cross-arch images. dd's JIT wins 9 of 10, hugely on floating-point:

For arm64 images there's no emulation to beat — it's native either way, so the bar is a native Linux VM, the hardest one. dd is at or above parity on compute and the honest losses are allocation/syscall-heavy work:

The remaining gaps are SQLite (~1.5×) and qsort (~1.3×) — a userspace kernel pays for indirect-branch dispatch and every syscall. Recent passes (return-prediction off + stealing two host registers) already took SQLite from ~1.9× to ~1.5×; closing the rest is the frontier I'm on (a throughput-bound server like redis still loses ~3× today). I'd rather show it than hide it.

Numbers measured, median of 7 on Apple Silicon; reproduce with make bench. Every workload is sized to run ≥0.45s, so the harness's small per-run bridge tax is negligible.

What you get today

It’s a single native macOS app. It runs the daemon in the background, shows your containers, images, networks and volumes at a glance, and lets you point Docker at dd from inside the app — no config files, no sudo.

After that, it’s the Docker you already know:

• Pick the Docker context — choose dd right in the app, and your CLI talks to the no-VM runtime.
• docker works as usual — docker run / ps / build / compose and your existing images, unchanged. dd is just a docker context, not a new tool to learn — and startup is a process spawn (~0.02s), not a boot. Run x86 images too with --platform linux/amd64.
• ddcli for the terminal — install the CLI for scripts and CI; ddcli mac even drops you into a real isolated macOS shell — the kernel is just userspace code, not only a Linux one, so JVM / Node / .NET that JIT at runtime work too.

▶

▶

▶

‹ ›

The honest trade-off

A userspace kernel is only as complete as the syscalls it implements, and by default dd runs the guest in one process — a great fit for code you trust (your dev environment, CI, your own tools). For untrusted code there's now an opt-in sentry split (DDJIT_UNTRUSTED): the guest runs in a deny-default Seatbelt sandbox with no host fs/net authority, while a trusted sentry process owns the real resources and serves its syscalls across a shared-memory ring — the gVisor shape, on the desktop. It's early — the core file syscalls (read/write/open/close/lseek) forward today; sockets/exec/fork are landing — so I won't pretend it matches a VM yet: for fully hostile code a VM still exposes a narrower attack surface. (Default path is unchanged: gate off, byte-identical to before.) And it's all still alpha — some images are flaky run-to-run.

Thanks for reading. If you try it and something breaks (it will), I'd genuinely like to hear about it — email me or open an issue on GitHub.

— Richard Hutta

← More from the dd blog