from Hacker News

Containerization is a Swift package for running Linux containers on macOS

by gok on 6/9/25, 8:53 PM with 409 comments

• by commandersaki on 6/9/25, 10:41 PM

  Video about it here: https://developer.apple.com/videos/play/wwdc2025/346/

  Looks like each container gets its own lightweight Linux VM.

  Can take it for a spin by downloading the container tool from here: https://github.com/apple/container/releases (needs macOS 26)

• by sangeeth96 on 6/9/25, 10:22 PM

  The CLI from the press release/WWDC session is at https://github.com/apple/container which I think is what many like myself would be interested in. I was hoping this'd be shipped with the newest Xcode Beta but that doesn't seem to be the case. Prebuilt packages are missing at the moment but they are working on it: https://github.com/apple/container/issues/54

• by candiddevmike on 6/9/25, 9:43 PM

  Wonder how Docker feels about this. I'd assume a decent amount of Docker for Desktop is on Mac...

• by pxc on 6/10/25, 12:06 AM

  This is the most surprising and interesting part, imo:

  > Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information.

  This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc.

  I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers.

  I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted.

  Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.

• by spockz on 6/10/25, 3:06 AM

  At first I thought this sounded like a blend of the virtualisation framework with a firecracker style lightweight kernel.

  This project had its own kernel, but it also seems to be able to use the firecracker one. I wonder what the advantages are. Even smaller? Making use of some apple silicon properties?

  Has anyone tried it already and is it fast? Compared to podman on Linux or Docker Desktop for Mac?

• by julik on 6/10/25, 2:44 PM

  Really curious how this improves the filesystem bridging situation (which with Docker Desktop was basically bouncing from "bad" to "worse" and back over the years). Or whether it changes it at all.

• by sitole on 6/10/25, 12:47 AM

  Has anyone tried turning on nested virt yet? Since the new container CLI spins each container in its own lightweight Linux VM via Virtualization.framework, I’m wondering whether the framework will pass the virtualization extensions through so we can modprobe kvm inside the guest.

  Apple’s docs say nested virtualization is only available on M3-class Macs and newer (VZGenericPlatformConfiguration.isNestedVirtualizationSupported) developer.apple.com, but I don’t see an obvious flag in the container tooling to enable it. Would love to hear if anyone’s managed to get KVM (or even qemu-kvm) running inside one of these VMs.

• by sho_hn on 6/9/25, 11:16 PM

  So both of the other big two desktop OSs now have official mechanisms to run Linux VMs to host Linux-native applications.

  You can make some kind of argument from this that Linux has won; certainly the Linux syscall API is now perhaps the most ubiquitous application API.

• by roberttod on 6/9/25, 10:58 PM

  I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.

• by paxys on 6/9/25, 11:41 PM

  Thinking more about this a bit, one immediate issue I see with adoption is that the idea of launching each container in its own VM to fully isolate it and give it its own IP, while neat, doesn't really translate to Linux or Windows. This means if you have a team of developers and a single one of them doesn't have a mac, your local dev model is already broken. So I can't see a way to easily replace Docker/Compose with this.

• by SamuelAdams on 6/10/25, 1:53 AM

  I wonder if this will dramatically improve gaming on a Mac? Valve has been making games more reliable due to Steam Deck, and gaming on Linux is getting better every year.

  Could games be run inside a virtual Linux environment, rather than Apple’s Metal or similar tool?

  This would also help game developers - now they only need to build for Windows, Linux, and consoles.

• by solomatov on 6/9/25, 10:09 PM

  Does anyone know whether they have optimized memory management, i.e. virt machine not consuming more RAM than required?

• by jbverschoor on 6/9/25, 10:13 PM

  In my opinion this is a step towards the Apple cloud hosting.

  They have Xcode cloud.

  The $4B contract with Amazon ends, and it’s highly profitable.

  Build a container, deploy on Apple, perhaps with access to their CPU’s

• by newman314 on 6/9/25, 9:13 PM

  I wonder how this will affect apps like Orbstack

• by pmarreck on 6/10/25, 2:48 PM

  So the x64 containers will run fine on Apple Silicon?

• by qalmakka on 6/10/25, 9:30 AM

  that's nice and all - but where are the native Darwin containers? Why is it ok for Apple to continue squeezing people with macOS CI jobs to keep buying stupid Mac Minis to put in racks only to avoid a mess? Just pull FreeBSD jails!

• by outcoldman on 6/9/25, 9:32 PM

  Not sure what exactly is happening, but feels very slow. Builds are taking way longer. Tried to run builder with -c and -m to add more CPU and memory.

• by cedws on 6/10/25, 3:25 AM

  Forget Linux containers on Mac, as far as I’m concerned that’s already a solved problem. What about Mac containers? We still don’t have a way to run a macOS app with its own process namespace/filesystem in 2025. And with all this AI stuff, there’s a need to minimise blast radius of a rogue app more than ever.

• by rfoo on 6/9/25, 9:17 PM

  This does not support memory ballooning yet. But they have documented custom kernel support, so, goodbye OrbStack.

• by filleokus on 6/9/25, 10:10 PM

  Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option).

  I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.

  [0]: https://developer.apple.com/videos/play/wwdc2025/346 10:10 and forwards

• by dang on 6/10/25, 4:08 AM

  Related ongoing threads:

  Container: Apple's Linux-Container Runtime - https://news.ycombinator.com/item?id=44229239 - June 2025 (11 comments)

  Apple announces Foundation Models and Containerization frameworks, etc - https://news.ycombinator.com/item?id=44226978 - June 2025 (345 comments)

  (Normally we'd merge them but it seems there are significant if subtle differences)

• by miovoid on 6/10/25, 2:58 AM

  I hope it will support nested virtualization.

• by omeid2 on 6/10/25, 7:36 AM

  This is really bad news for Linux on Desktop.

  Many developers I know don't use MacOS mainly because they depend on containers and virtualisation is slow, but if Apple can pull off efficient virtualisation and good system integration (port mapping, volumes), then it will eat away at a large share of linux systems.

• by sampton on 6/9/25, 10:25 PM

  Apple please expose GPU cores to the VMs.

• by mustache_kimono on 6/10/25, 4:33 AM

  This is great. Also about time, etc.

  But is it also finally time to fix dtrace on MacOS[0]?

  [0]: https://developer.apple.com/forums/thread/735939?answerId=76...

• by mattclarkdotnet on 6/10/25, 3:26 AM

  Spoiler alert: it’s not containers.

  It’s some nice tooling wrapped around lightweight VMs, so basically WSL2

• by m3kw9 on 6/10/25, 12:17 AM

  I’m already running docker on macOS what’s the difference?

• by joshdavham on 6/9/25, 10:53 PM

  Will this likely have any implications for tools like ‘act’ for running local GitHub actions? I’ve had some trouble running act on apple silicon in the past.

• by arianvanp on 6/10/25, 9:23 PM

  Them synthesizing an EXT4 file system from tarball layers instead of something like EROFS is so extremely odd. Really really strange design.

• by sneak on 6/9/25, 10:01 PM

  Surprising to me that this uses swift CLI tools (free software) and make, not Xcode.

• by fralix on 6/10/25, 2:10 PM

  And when native OCI macos container engine native ?!

• by xmorse on 6/10/25, 5:20 PM

  Is this basically the same thing as Orbstack?

• by peterpost2 on 6/10/25, 7:16 AM

  Terrible name. Look like a neat product though!

• by pmarreck on 6/10/25, 2:50 PM

  Prefer the Nix approach unless a container approach is absolutely necessary.

• by sirjaz on 6/10/25, 6:46 PM

  This is just wsl2 from Microsoft, albeit with an Apple spin

• by jamie0 on 6/9/25, 9:59 PM

  disappointing theres still no namespacing in darwin for macos containers. would be great to run xcodebuild in a container

• by IshKebab on 6/9/25, 9:43 PM

  Getting worried about WSL I see!

• by justinzollars on 6/9/25, 9:45 PM

  I'm excited to run Systemd on mac!

• by throwaway1482 on 6/10/25, 3:05 PM

  If they're going this way, why not just replace the macOS kernel (XNU) with Linux? They'll get so much more.

• by tgma on 6/10/25, 3:57 AM

  I'm glad this will kill the Docker Desktop clone business on Mac. Friend company got hit by using one of the free ones and got rug pulled by them.

• by m463 on 6/9/25, 11:48 PM

  I think this is purely a checkbox feature to compare against wsl. Otherwise apple just wouldn't get involved (not engineers, who would do lots of good things, but management that let this out)

• by bdcravens on 6/9/25, 11:16 PM

  Cool, but until someone (Apple or otherwise) implements Docker Compose on top of this, it's unlikely to see much use.

• by rvz on 6/9/25, 9:13 PM

  Requires an Apple Silicon Mac to run.

  > You need an Apple silicon Mac to build and run Containerization.

  > To build the Containerization package, your system needs either:

  > macOS 15 or newer and Xcode 26 Beta

  > macOS 26 Beta 1 or newer

  Those on Intel Macs, this is your last chance to switch to Apple Silicon, (Sequoia was the second last)[0] as macOS Tahoe is the last version to support Intel Macs.

  [0] https://news.ycombinator.com/item?id=41560423