macOS Container Machines

418 pointsposted 4 hours ago
by timsneath
(github.com)

127 Comments

timsneath

4 hours ago

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

Onavo

3 hours ago

Ah, the Darwin/BSD Subsystem for Linux.

CGamesPlay

3 hours ago

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.

AlexB138

3 hours ago

Isn't the Windows subsystem for Linux (the reference there) also a VM?

gsnedders

3 hours ago

Only WSL2; WSL1 was an actual subsystem.

selcuka

3 hours ago

So this is Darwin/BSD Subsystem for Linux 2.

rvz

21 minutes ago

Yes.

LoganDark

2 hours ago

WSL1 was so cool, WSL2 made it boring and isolated.

TylerE

2 hours ago

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.

noduerme

an hour ago

Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications.

I never want to deal with that again ;)

[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.

TylerE

an hour ago

The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this

rpeden

an hour ago

You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0.

That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.

TylerE

an hour ago

Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.

_blk

2 hours ago

... Now it's just called git bash

michaelsbradley

2 hours ago

Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.

jayd16

3 hours ago

Mac Subsystem for Linux 2

blahgeek

4 hours ago

OrbStack works really well for me. I wonder how it’s compared to this performance wise

kdrag0n

3 hours ago

(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.

d3v1an7

18 minutes ago

just adding a 'hell yeah: orbstack is so good' to the thread. i mainly avoid containers where i can, but when containers need to happen, orbstack is 'just enough' for me. lovely and well considered ui, stable, performant. don't need much else. thank you for your work and care!

mescalito

2 hours ago

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?

kdrag0n

2 hours ago

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

CGamesPlay

3 hours ago

> 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.

saltamimi

3 hours ago

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.

kdrag0n

3 hours ago

Ahh those were good times, glad you came across it :)

kxxx

3 hours ago

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."

kdrag0n

3 hours ago

Good catch, I tried the example alpine commands and there was no init system. Makes sense if it's based on OCI images

kxxx

3 hours ago

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 :)

trueno

3 hours ago

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!

TheTaytay

2 hours ago

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

kdrag0n

2 hours ago

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

jhancock

3 hours ago

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?

thatxliner

3 hours ago

Having used both, it feels like OrbStack "just works" more than Podman. The main example of this is Supabase.

blackqueeriroh

an hour ago

When are y’all gonna support sandboxing? Preferably Docker Sandboxes?

vsgherzi

3 hours ago

I love orbstack, is there any code I could read on the rust side? Seems very interesting

kxxx

3 hours ago

I really like OrbStack and am also not sure why I'd use Container Machines over it, at the moment...

cpuguy83

2 hours ago

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.

mpeg

an hour ago

I like orbstack in theory, but I find it hard to justify a $96/yr license fee for something that has so many open source, free alternatives. As it is, I’d rather use podman or colima

CSDude

9 minutes ago

I know its not going to be there but wish we had Windows as well.

cogman10

2 hours ago

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.

twoodfin

2 hours ago

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?

cogman10

2 hours ago

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.

MBCook

an hour ago

Yeah. But in exchange it’s a lot of work to keep up with. For GUI stuff you’re now having to have some sort of Wayland layer/driver.

Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.

Wasn’t compatibility what really sunk WSL1?

skissane

8 minutes ago

> Wasn’t compatibility what really sunk WSL1?

Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX

The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.

More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux

vachanmn123

an hour ago

Could this allow us to use proton on mac maybe?

xd1936

23 minutes ago

This is hilarious. Next year, the PC gamers will be saying "The best Windows gaming experience is win32 on Linux on macOS Containers".

aurareturn

6 minutes ago

The fastest (Geekbench 6) Windows laptop in the world is actually an M5 Max Macbook running Parallels running Windows.

Gigachad

13 minutes ago

I mean at this point literally anything works better than Windows.

noobcoder

an hour ago

The costs are startup time and image compatibility: dockerhub images don't work as machine images because container machine expects systemd

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

jaimehrubiks

4 hours ago

Will this be able to replace docker desktop an equivalents, removing the expensive Linux VM that runs alongside them?

usernametaken29

3 hours ago

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

deathanatos

3 hours ago

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.

thejazzman

4 hours ago

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

nozzlegear

2 hours ago

Nice, thanks for this. My plan is to swap over to Apple's containers for local dev, and keep using podman quadlets in production.

deathanatos

3 hours ago

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.

MBCook

an hour ago

CGamesPlay said above its balloon memory so it won’t use all that memory by default, but it can’t release balloon memory yet.

lostlogin

3 hours ago

Others here mention it and I’m a new convert to Colima.

The pain of working around Docker Desktop is bad.

trollbridge

4 hours ago

That sure would be nice. I seem to rm -rf ~/.colima every few days.

llimllib

3 hours ago

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

kdrag0n

3 hours ago

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).

ahknight

2 hours ago

Podman is on macOS, FWIW. Uses the existing container framework to run the machine already. Root-full or not.

osigurdson

3 hours ago

I'm surprised they cared enough to do this. I'd still rather use Linux but MacBook value is incredible.

marssaxman

2 hours ago

I'd always rather use Linux, but sometimes your employer gives you a MacBook. I might use this tool.

rickstanley

2 hours ago

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.

numbsafari

3 hours ago

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.

CGamesPlay

3 hours ago

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).

jayd16

3 hours ago

Maybe I don't understand but why doesn't Gitlabs self hosted setup work?

0xbadcafebee

2 hours ago

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

a1o

3 hours ago

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?

frizlab

3 hours ago

Rosetta should be supported

m132

2 hours ago

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.

TheDong

2 hours ago

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.

m132

an hour ago

OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple.

That being said, my point isn't that Apple should absolutely focus on making a server OS again. It just saddens me how far behind macOS has fallen as they stopped caring about the fundamentals; back in the day, it would be Linux trailing behind macOS. Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard, and what Apple happily shows off on WWDC is a wrapper around Linux. Something functionally equal can be cobbled up together by anyone sufficiently experienced in minutes, using just Bash, OpenSSH, and QEMU.

I really wish macOS would let me have a similar level of control over applications as Linux with namespaces, without me having to do all the heavy lifting.

vehemenz

2 hours ago

No offense, but serious developers don’t think this way at all.

bel8

17 minutes ago

For server side, which I believe is the context here, Linux and open source are king.

Even Microsoft gave up on Windows and just runs Linux most things except niche cases. Heck, even SQL Server which is expensive piece of machinery got ported to Linux and that's the default target now in their docs.

With that said, one can't deny Apple's success on the b2c side of things so it feels wrong to call their strategy a failure.

groundzeros2015

2 hours ago

Just change 30 years of internet history

al_borland

an hour ago

For what it's worth, the first web server was a NeXTcube, and NeXTSTEP was the foundation of macOS.

tw04

2 hours ago

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.

riffic

2 hours ago

> Literally nobody would build to it

because nobody does ci/cd against macOS or iOS apps right?

tw04

2 hours ago

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.

m132

an hour ago

Correct me if I'm wrong, but by the same logic, you could also say this whole containerization framework is of no use either.

If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.

MBCook

an hour ago

Containers are REALLY REALLY popular. This is a a great value add for developers on Mac who need to deal with Linux containers.

Which is a ton of ‘em.

tw04

an hour ago

Supporting the containerization framework lets them sell more laptops to Linux devs that may have otherwise bought a Dell or hp or insert brand to run Linux natively on or windows with WSL.

commandersaki

3 hours ago

Would be cool if you can redirect USB devices to the VM.

kdrag0n

3 hours ago

We just released this in OrbStack :) https://docs.orbstack.dev/features/usb

Blog post soon

blackqueeriroh

an hour ago

What happened to Orbstack for like 9 months until earlier this year? Suddenly everything went silent for a bit and I was pretty concerned. Glad y’all are back!!!!

calebm

2 hours ago

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).

commandersaki

2 hours ago

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)

kdrag0n

2 hours ago

We're working on block device passthrough for the builtin SD reader.

rgovostes

an hour ago

I've successfully tinkered with USB/IP with Apple containers, but it does require loading a custom kernel (which they make pretty easy, thankfully). On the host side, macOS also doesn't make it easy to unload a driver that attaches automatically.

namegulf

4 hours ago

Would be nice if they also support Intel based macs, what prevents?

MBCook

3 hours ago

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.

danhon

3 hours ago

Allocation of a finite amount of engineering resources.

joshuat

3 hours ago

And a legitimate business interest to further incentivize the adoption of Apple Silicon devices. Same with Rosetta deprecation after macOS 27.

JumpCrisscross

3 hours ago

> 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.

crote

2 hours ago

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?

macintux

an hour ago

> Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.

I'm very, very skeptical of this analysis. Certainly "entirely" is hyperbole.

ForOldHack

2 hours ago

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...

weikju

2 hours ago

Rosetta 1 was for emulating PPC not 68k

gigatexal

an hour ago

I saw the video on this this is distrobox basically for Mac. It’s very cool. Seamless with your local files and the container. I’m very keen to try it.

t1234s

2 hours ago

Is this similar to what cygwin was for windows? Could this be an alternative to homebrew?

michaelsbradley

2 hours ago

Can macOS be run as a container machine on macOS?

blackqueeriroh

an hour ago

Yes

MBCook

an hour ago

Yep. For a few years. And they keep enhancing it too.

It’s the only legal way to do so, due to the software license on MacOS.

xiaodai

an hour ago

so basically dockers

riffic

3 hours ago

darwin containers when?

m463

4 hours ago

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):

  FROM apple/macos:10.11.6

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

trollbridge

4 hours ago

Close - but it would be more like this:

  services:
    macos:
      image: dockurr/macos
      container_name: macos
      environment:
        VERSION: "15"
(And indecently slow.)

webXL

4 hours ago

Nice, but expect to page through a few pages of ToS during the build

m463

3 hours ago

lol

  ENV XCODE_FRONTEND=unattended
  ENV XCODE_LICENSES=accept,firstborn,applepay,appleid=sjobs@me.com

windowliker

3 hours ago

It would be wonderful if this ran on older versions of macOS, but according to the README they only support 26.

m463

2 hours ago

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:

  FROM ubuntu:16.04
or

  docker run ubuntu:16.04
and though I haven't tried it, I believe docker can do arm in x86 using an emulator (like rosetta)

MBCook

an hour ago

You can already run older versions of macOS inside a VM on macOS.

So it seems like in theory that should be doable if someone just made the container images right?

jwlake

2 hours ago

haven't we had hypervisor.framework for like years now?

Barbing

3 hours ago

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?