To clarify a few comments here: this is not only OCI containers: container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS. More details here: https://developer.apple.com/videos/play/wwdc2026/389
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
I was wondering if it's possible to have the container volume change to, say, an external drive. I currently use QMEU with qcow2 images to achieve this, works well enough.
(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers.
Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
Super happy orbstack customer. Just curious on your statement:
> I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
The linked md document says:
> Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.
Was that not the case when you used container machines?
That's my bad, I used the example alpine commands and the official alpine doesn't have init. It's supported if you build an image with systemd installed
> Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.
Apple says that `systemctl` is supported... hmm am I missing something?
"Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."
Just tested it on on an OCI image with systemd and it works well. I can see the appeal of OrbStack regarding memory reallocation and will stick with it in the time being :)
I wanted to make its VM/machine our default secure agent sandbox, but I couldn’t figure out how to isolate this VM from the host properly. This thread prompted me to find the issue though, and I saw this was recently implemented!
https://github.com/orbstack/orbstack/issues/169
Yep! Still refining it but isolated machines now have fine-grained settings for filesystem mounts, network isolation, SSH agent forwarding, and CPU/memory/disk limits
just dropping in to say orbstack super owns and i use it every day. huge respect to rethinking this experience, for a minute there i thought docker was just going to be the only path. i dont think ive looked back for docker since. orbstack just feels right, and damn its so fast and good with resources, and the UI is just insanely straight forward. props!
I know this is off topic, but I do thank you for your Android work, the idea and elegance of fastboot.js and that SafetyNet workaround trick was truly really cool.
I’ve been using podman on Mac. It’s been a nice fit as the container build files are identical to what I use on my fedora server. I have noticed my 2 virtual core 4 gb Linode vps runs apps faster in the same container as when run on my MacBook Air M2 16 gb. I expected some performance overhead but didn’t think it would be noticeable as it is. Overall happy with podman. How might OrbStack differ?
Not a full docker env, I aimed this as doing builds though you can run dockerd as an option, https://github.com/cpuguy83/crucible uses the containerization framework to run either build kitd or dockerd and wire it up to docker/buildx cli (or whatever client tooling you want to use).
The Containerization framework is a library that sits as a layer on top of the virtualization framework.
So each container is its own VM.
Machine is tooling above the containerization framework to run multiple things in a container in a vm.
Is there any reason why macOS doesn't try a WSL1 style approach? I get why that didn't fully work out for windows, but it seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac. It seems like it should be possible to run most linux applications natively on macOS with few additional new APIs.
Potentially faster application execution along much lower memory requirements. In the case of docker, even a possibility of shared library loading further reducing runtime costs (For example, containers based on the same base image could load glibc into memory only once).
There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.
My first thought as well, docker desktop overhead is pretty bad, would be awesome to see this land natively in DD. By my estimate this could happen, seeing as Docker has historically tried to improve performance but quickly had to accept platform limitations… would only be natural to settle DD over to containers
Well, you can avoid the Docker Desktop tax by not running Docker Desktop. colima is a perfectly usable implementation of Docker for macOS, without the bloat of Docker Desktop.
That said, colima still has the expensive VM that upthread is mentioning.
That's the most expensive part of the whole transaction, b/c AFAIK, RAM is then dedicated to the VM. It can be swapped out, I suppose, but that's not great.
Every time I see Apple flaunting Linux containers I can hardly consider it as anything but admitting defeat. It could easily be Darwin, if they still had the capacity.
Apple set itself up for defeat in the server and developer marketplace as soon as they decided macOS was proprietary code.
Why would any serious developer use closed-source code they can't debug and modify? Especially for a production server?
It's the same reason no serious developers or hackers use macOS, like part of the point of being a developer is being able to dig into the code at any layer and debug and fix things.
And what is the revenue stream tied to that ci/cd pipeline they aren’t capturing today? Apple would sell less hardware in order to…?
There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with no apparent upside beyond “goodwill” which they’ve never been overly concerned about.
Curious if you've tried OrbStack? There's always more work to do (test workloads appreciated!) but we've put a lot of effort into optimizing for small files and other common developer workloads in OrbStack's customized filesystem sharing protocol (not standard virtiofs).
Wouldn’t it be nice if services like Codespaces or Coder or Gitlab would allow you to target running on their hosted/integrated platform, or let you launch that same container completely locally? Sometimes I wanna take my “remote” dev environment off-line but still benefit from the integrated UX.
If you can express that operation in Terraform, then Coder would let you do that. First problems I can think of are connectivity from the Coder provisioner to your local machine (Tailscale? Local?), and migrating disk images if you want to actually switch a workspace between environments (local provisioner could do this, but no matter what it’ll be slow and janky).
Anyone know why you would use this instead of QEMU+Lima+Colima+Docker/containerd? The latter works on multiple OSes, has a very large ecosystem of tools, images, documentation, and lets you replace pieces as needed
With colima I can run AMD64 (x86) Linux containers in my Arm64 too. I think this is strictly for Arm64 Linux VMs, or is there some way to run x86 with this too?
Thank you for sharing this - I looked into OrbStack a few months ago, and this was the reason I didn't use it (as my primary purpose was to have an external wifi adapter for wifi pwnage).
I found it hard to believe I didn’t have a simple way of staying safe by installing an arbitrary application in a sandbox on macOS. (Restoring using Time Machine doesn’t count! :) )
This is a step in the right direction but requires any given developer’s buy-in first, right?
Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing machines, but (especially with the new MacBook Neo) what's going to happen when a large portion of the market for high-end MBPs disappears because it turned from the default no-brainer into a liability?
> a legitimate business interest to further incentivize the adoption of Apple Silicon devices
Apple has never been about supporting legacy platforms with new features. And with over a quarter of revenue and two fifths of Apple's gross profits coming from services, one could argue the incentives run either way.
Rosetta 2. Rosetta was for Intel to emulate 68k, now if you could get Rosetta 2 to run under Rosetta, then you could run 68k, on an ARM, and if you could get the apple ][ emulator...
Daily driver is a 6yo, 32Mb mbp and it might not scream like an M5 or have the miraculous power draw of an M5, it gets my job done.
One nice thing is x86 containers run natively: I run most of my $work landscape which is 40 or 50 k8s pods on top of Kind, which is itself a plain container. That mirrors my prod. That plus slack, zoom, ff with scores of tabs, etc. all while building rust and playing music.
To clarify a few comments here: this is not only OCI containers: container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS. More details here: https://developer.apple.com/videos/play/wwdc2026/389
Ah, the Darwin/BSD Subsystem for Linux.
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
Isn't the Windows subsystem for Linux (the reference there) also a VM?
Only WSL2; WSL1 was an actual subsystem.
So this is Darwin/BSD Subsystem for Linux 2.
WSL1 was so cool, WSL2 made it boring and isolated.
Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
... Now it's just called git bash
Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.
Mac Subsystem for Linux 2
Apple containers are great for providing a sandbox to your AI coding agents
I have made it a MCP so that it's easily discoverable by all the coding agents
https://github.com/instavm/coderunner
I was wondering if it's possible to have the container volume change to, say, an external drive. I currently use QMEU with qcow2 images to achieve this, works well enough.
OrbStack works really well for me. I wonder how it’s compared to this performance wise
(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers.
Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
Super happy orbstack customer. Just curious on your statement:
> I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
The linked md document says:
> Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.
Was that not the case when you used container machines?
That's my bad, I used the example alpine commands and the official alpine doesn't have init. It's supported if you build an image with systemd installed
> Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.
Apple says that `systemctl` is supported... hmm am I missing something?
"Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."
Good catch, I tried the example alpine commands and there was no init system. Makes sense if it's based on OCI images
Just tested it on on an OCI image with systemd and it works well. I can see the appeal of OrbStack regarding memory reallocation and will stick with it in the time being :)
Thanks for the info kdrag0n! Big fan of OrbStack; good call out on dynamic memory.
If the guest image has /sbin/init, we use that.
We'd recommend using a base image for the guest that includes systemd. ie: https://github.com/apple/container/blob/main/docs/container-...
We love OrbStack too! Thank you for it,
I wanted to make its VM/machine our default secure agent sandbox, but I couldn’t figure out how to isolate this VM from the host properly. This thread prompted me to find the issue though, and I saw this was recently implemented! https://github.com/orbstack/orbstack/issues/169
Yep! Still refining it but isolated machines now have fine-grained settings for filesystem mounts, network isolation, SSH agent forwarding, and CPU/memory/disk limits
just dropping in to say orbstack super owns and i use it every day. huge respect to rethinking this experience, for a minute there i thought docker was just going to be the only path. i dont think ive looked back for docker since. orbstack just feels right, and damn its so fast and good with resources, and the UI is just insanely straight forward. props!
I know this is off topic, but I do thank you for your Android work, the idea and elegance of fastboot.js and that SafetyNet workaround trick was truly really cool.
Ahh those were good times, glad you came across it :)
I’ve been using podman on Mac. It’s been a nice fit as the container build files are identical to what I use on my fedora server. I have noticed my 2 virtual core 4 gb Linode vps runs apps faster in the same container as when run on my MacBook Air M2 16 gb. I expected some performance overhead but didn’t think it would be noticeable as it is. Overall happy with podman. How might OrbStack differ?
Having used both, it feels like OrbStack "just works" more than Podman. The main example of this is Supabase.
I love orbstack, is there any code I could read on the rust side? Seems very interesting
I'd like to see a comparison to https://tart.run/ as well.
AFAICT it's pretty similar.
Not a full docker env, I aimed this as doing builds though you can run dockerd as an option, https://github.com/cpuguy83/crucible uses the containerization framework to run either build kitd or dockerd and wire it up to docker/buildx cli (or whatever client tooling you want to use).
The Containerization framework is a library that sits as a layer on top of the virtualization framework. So each container is its own VM.
Machine is tooling above the containerization framework to run multiple things in a container in a vm.
I really like OrbStack and am also not sure why I'd use Container Machines over it, at the moment...
Do these containers share a common kernel? Or are they each ran in a separate VM?
Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...
Is there any reason why macOS doesn't try a WSL1 style approach? I get why that didn't fully work out for windows, but it seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac. It seems like it should be possible to run most linux applications natively on macOS with few additional new APIs.
BSD actually has this already.
What would be the advantages over a VM infrastructure Apple needs anyway and that has a much simpler, more stable “ABI” compared to the Linux kernel?
Potentially faster application execution along much lower memory requirements. In the case of docker, even a possibility of shared library loading further reducing runtime costs (For example, containers based on the same base image could load glibc into memory only once).
There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.
Will this be able to replace docker desktop an equivalents, removing the expensive Linux VM that runs alongside them?
My first thought as well, docker desktop overhead is pretty bad, would be awesome to see this land natively in DD. By my estimate this could happen, seeing as Docker has historically tried to improve performance but quickly had to accept platform limitations… would only be natural to settle DD over to containers
Well, you can avoid the Docker Desktop tax by not running Docker Desktop. colima is a perfectly usable implementation of Docker for macOS, without the bloat of Docker Desktop.
That said, colima still has the expensive VM that upthread is mentioning.
OrbStack is great also
It mostly removes the big shared background VM and replaces it with smaller, more isolated Apple-native VMs.
I did an experiment migrating my Podman workload to Apple's container @ https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
TL;DR reduces ram/storage usage; minimizes it's existence
Nice, thanks for this. My plan is to swap over to Apple's containers for local dev, and keep using podman quadlets in production.
How does that work, realistically?
> Memory defaults to half of host memory
That's the most expensive part of the whole transaction, b/c AFAIK, RAM is then dedicated to the VM. It can be swapped out, I suppose, but that's not great.
Others here mention it and I’m a new convert to Colima.
The pain of working around Docker Desktop is bad.
That sure would be nice. I seem to rm -rf ~/.colima every few days.
Every time I see Apple flaunting Linux containers I can hardly consider it as anything but admitting defeat. It could easily be Darwin, if they still had the capacity.
Apple set itself up for defeat in the server and developer marketplace as soon as they decided macOS was proprietary code.
Why would any serious developer use closed-source code they can't debug and modify? Especially for a production server?
It's the same reason no serious developers or hackers use macOS, like part of the point of being a developer is being able to dig into the code at any layer and debug and fix things.
Just change 30 years of internet history
What is the alternative? They gave up the server market a decade ago and before that they barely actually supported it.
If they were to support darwin containers, what would be the point? Literally nobody would build to it, Linux won.
> Literally nobody would build to it
because nobody does ci/cd against macOS or iOS apps right?
And what is the revenue stream tied to that ci/cd pipeline they aren’t capturing today? Apple would sell less hardware in order to…?
There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with no apparent upside beyond “goodwill” which they’ve never been overly concerned about.
I'm surprised they cared enough to do this. I'd still rather use Linux but MacBook value is incredible.
I'd always rather use Linux, but sometimes your employer gives you a MacBook. I might use this tool.
Is this new? I thought we had this already
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
Curious if you've tried OrbStack? There's always more work to do (test workloads appreciated!) but we've put a lot of effort into optimizing for small files and other common developer workloads in OrbStack's customized filesystem sharing protocol (not standard virtiofs).
Podman is on macOS, FWIW. Uses the existing container framework to run the machine already. Root-full or not.
We have WSL at home.
Wouldn’t it be nice if services like Codespaces or Coder or Gitlab would allow you to target running on their hosted/integrated platform, or let you launch that same container completely locally? Sometimes I wanna take my “remote” dev environment off-line but still benefit from the integrated UX.
This exists. It's called devcontainers and there is a cli for managing it locally.
https://github.com/devcontainers/ https://containers.dev/
If you can express that operation in Terraform, then Coder would let you do that. First problems I can think of are connectivity from the Coder provisioner to your local machine (Tailscale? Local?), and migrating disk images if you want to actually switch a workspace between environments (local provisioner could do this, but no matter what it’ll be slow and janky).
Maybe I don't understand but why doesn't Gitlabs self hosted setup work?
Anyone know why you would use this instead of QEMU+Lima+Colima+Docker/containerd? The latter works on multiple OSes, has a very large ecosystem of tools, images, documentation, and lets you replace pieces as needed
With colima I can run AMD64 (x86) Linux containers in my Arm64 too. I think this is strictly for Arm64 Linux VMs, or is there some way to run x86 with this too?
Rosetta should be supported
Would be cool if you can redirect USB devices to the VM.
We just released this in OrbStack :) https://docs.orbstack.dev/features/usb
Blog post soon
Thank you for sharing this - I looked into OrbStack a few months ago, and this was the reason I didn't use it (as my primary purpose was to have an external wifi adapter for wifi pwnage).
Yeah I find this useful for redirecting storage/sdcard*, so you can format linux filesystems or use other tools.
* need a usb sdcard reader for macbook pro cause the builtin is not usb)
We're working on block device passthrough for the builtin SD reader.
Agreed! There's some good improvements around Accessory Access in virtualization framework this year also - checkout: https://developer.apple.com/videos/play/wwdc2026/224/?time=2...
I wonder if the custom virtio can be used to support attaching the built-in sdcard readers on macs which aren't exposed as usb.
Can macOS be run as a container machine on macOS?
WWDC presentation video:
Discover container machines
https://developer.apple.com/videos/play/wwdc2026/389/
Is this similar to what cygwin was for windows? Could this be an alternative to homebrew?
I found it hard to believe I didn’t have a simple way of staying safe by installing an arbitrary application in a sandbox on macOS. (Restoring using Time Machine doesn’t count! :) )
This is a step in the right direction but requires any given developer’s buy-in first, right?
haven't we had hypervisor.framework for like years now?
WSL-like implementation on macOS?
Would be nice if they also support Intel based macs, what prevents?
Allocation of a finite amount of engineering resources.
And a legitimate business interest to further incentivize the adoption of Apple Silicon devices. Same with Rosetta deprecation after macOS 27.
Sure, but to what extent?
Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing machines, but (especially with the new MacBook Neo) what's going to happen when a large portion of the market for high-end MBPs disappears because it turned from the default no-brainer into a liability?
> a legitimate business interest to further incentivize the adoption of Apple Silicon devices
Apple has never been about supporting legacy platforms with new features. And with over a quarter of revenue and two fifths of Apple's gross profits coming from services, one could argue the incentives run either way.
Rosetta 2. Rosetta was for Intel to emulate 68k, now if you could get Rosetta 2 to run under Rosetta, then you could run 68k, on an ARM, and if you could get the apple ][ emulator...
Apple won’t support them with MacOS 27, and it seems they announced this tool as part of this year’s WWDC.
Basically: they’ve moved on.
Intel Macs are cringe.
Edit: I grow stronger with each downvote
I'll defend, not cringe for everyone.
Daily driver is a 6yo, 32Mb mbp and it might not scream like an M5 or have the miraculous power draw of an M5, it gets my job done.
One nice thing is x86 containers run natively: I run most of my $work landscape which is 40 or 50 k8s pods on top of Kind, which is itself a plain container. That mirrors my prod. That plus slack, zoom, ff with scores of tabs, etc. all while building rust and playing music.
More power to ya!
cringe is cringe
darwin containers when?
looks like apple wrote a native docker in swift
you can now run linux containers on your mac
... but it could be better.
what about (totally contrived):
Close - but it would be more like this:
(And indecently slow.)Nice, but expect to page through a few pages of ToS during the build
lol
It would be wonderful if this ran on older versions of macOS, but according to the README they only support 26.
you do not understand... Not run on, run IN :)
I'm saying the older version of macos could build/run INSIDE the container
just like on a ubuntu 24.04 system you can do:
or and though I haven't tried it, I believe docker can do arm in x86 using an emulator (like rosetta)i wish!