I can create docker-images with docker compose, or use something like colima, which this seems to be close to (that should have some advantages over docker, although my hope of circumventing W^X page protection did not pan out).

I was perplexed that the repository does not put these container machines in context. The seem to be close to colima? When should I use which option (docker, collima, container machines ?)

Maybe others wonder too but are ashamed to ask. I have no shame ;)

Thanks for any pointers

Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...

I wrote about that angle here: https://igorstechnoclub.com/sandbox-exec/

Feels like the spiritual successor to sandbox-exec, but with VM-level isolation.

Discover container machines

https://developer.apple.com/videos/play/wwdc2026/389/

There's some clever advertising in it for Linux, if Linux was advertising.

I have made it a MCP so that it's easily discoverable by all the coding agents

https://github.com/instavm/coderunner

UX wise it looks kinda neat though!

In my testing (iirc) filesystem performance was not good enough to be usable with node/rust dev where lots of small files get stat-ed

update: what's new is the `container machine` subcommand. I went to test it out, but container failed to run at all for me: https://github.com/apple/container/issues/1681

I am trying it on but its brekaing on homebrew 1.0.0. The formula puts plugins at opt/container/libexec/container-plugins/ and the apiserver looks in libexec/container/plugins/

This can be solved through a symlink or smth

BSD actually has this already.

By the way, is it headless or can it run a full Linux desktop? Use case: buy a Mac, uninistall whatever can be uninstalled, run the Linux VM as primary desktop forgetting MacOS and without going through Asahi and the incomplete hardware support.

However, unlike Lima, an Apple Container is not a full VM, so you cannot SSH to it, or forward SSH-agent signatures into a machine.

So it's more of a devcontainer story, which is also a great use case. Nice to see Apple creating tooling around their VZ framework.

Edit: referential clarity.

I would really love if apple could give inexpensive way to run amd64 containers for situations when dev wants to use their own hardware. We've used LIMA for now, was too much of a hussle. But if there's a more native experience – would give it another try.

Which for many folks is good enough for what they are doing, thus the status quo of desktop platforms will hardly change for current form factors.

I started using Colima a couple of years ago because I got bored of how bad Docker Desktop was and just started using the CLI / the "Services" tool window in whatever Jetbrains IDE I was using at the time anyway. I can't see myself moving away from it any time - having multiple profiles is an absolute winner of a feature for me there, but maybe the next time I set up a Mac from scratch I'll have a play with this.

I usually run like a db, redis, maybe something like rabbitmq/zeromq and have a app that uses these services (makefile/docker-compose).

I would love to switch if this in fact is a lightweight replacement.

They've now added a WSL-style virtual machine layer, but there's no x86 container story (Apple's killing Rosetta) so I imagine some qemu shimming will be required.

There's still no equivalent to VPNKit or GVisor for networking so you'll be bridging I think. See: https://cacm.acm.org/research/a-decade-of-docker-containers/ for how Docker for Mac does this

I can't spot any support for dynamic memory ballooning to prevent the hypervisor from gobbling up too much memory. We've had this in Xen since forever! https://xenproject.org/blog/ballooning-rebooting-and-the-fea...

And, most obviously: NO SUPPORT FOR MACOS. This is the single feature that only Apple can do, and they're choosing not to implement it deliberately, and it's so stupid given the pains we all have to go through to implement CI for macOS. In the land of OCaml, we were forced to implement a custom ZFS snapshotter to get reasonably cost effective macOS CI for our package repository: https://tarides.com/blog/2023-08-02-obuilder-on-macos/. This was fun to build, but it sucks to have to maintain it.

Also, I'm really curious what the GPU passthrough story here is for LLMs, since the Apple Silicon -> Linux kernel support is gated on Asahi's support, but that's been lagging beyond M2 due to the efforts of reverse engineering.

Do better for your developers, Apple. This is a half-baked sweep across third-party software without addressing the core needs around your own operating system.

In production though, I've moved completely to systemd isolation of apps, rather than Docker-like containers; essentially blackboxes and present a supply chain threat. There's also a DRY principle here. Verification of a host presents a much smaller surface area.

(you remote into a system and part of your environment comes with you; that's very Plan9-like.)

LE: nevermind, it is already on MacOS. Did not read everything.

you can now run linux containers on your mac

... but it could be better.

what about (totally contrived):

  FROM apple/macos:10.11.6

  RUN xcodebuild -project myapp.xcodeproj -scheme MyScheme -configuration Release

This is a step in the right direction but requires any given developer’s buy-in first, right?