Comment by pxc | Hacker News Reader

Comment by pxc | Hacker News Reader

I hoped for a moment that "Containerization Framework" meant that macOS itself would be getting containers. Running Linux containers and VMs on macOS via virtualization is already pretty easy and has many good options. If you're willing to use proprietary applications to do this, OrbStack is the slickest, but Lima/Colima is fine, and Podman Desktop and Rancher Desktop work well, too.

The thing macOS really painfully lacks is not ergonomic ways to run Linux VMs, but actual, native containers-- macOS containers. And third parties can't really implement this well without Apple's cooperation. There have been some efforts to do this, but the most notable one is now defunct, judging by its busted/empty website[1] and deleted GitHub organization[2]. It required disabling SIP to work, back when it at least sort-of worked. There's one newer effort that seems to be alive, but it's also afflicted with significant limitations for want of macOS features[3].

That would be super useful and fill a real gap, meeting needs that third-party software can't. Instead, as wmf has noted elsewhere in these comments, it seems they've simply "Sherlock'd" OrbStack.

--

1: https://macoscontainers.org/

2: https://github.com/macOScontainers

3: https://github.com/Okerew/osxiec

> The thing macOS really painfully lacks is not ergonomic ways to run Linux VMs, but actual, native containers-- macOS containers

Linux container processes run on the host kernel with extra sandboxing. The container image is an easily sharable and runnable bundle.

macOS .app bundles are kind of like container images.

You can sign them to ensure they are not modified, and put them into the “registry” (App Store).

The Swift ABI ensures it will likely run against future macOS versions, like the Linux system APIs.

There is a sandbox system to restrict file and network access. Any started processes inherit the sandbox, like containers.

One thing missing is fine grained network rules though - I think the sandbox can just define “allow outbound/inbound”.

Obviously “.app”s are not exactly like container images , but they do cover many of the same features.

You're kind of right. But at the same time they are nowhere close. The beauty of Linux containerization is that processes can be wholly ignorant that they are not in fact running as root. The containers get, what appear to them, to be the whole OS to themselves.

You don't get that in macOS. It's more of a jail than a sandbox. For example, as an app you can't, as far as I know, shell out and install homebrew and then invoke homebrew and install, say, postgres, and run it, all without affecting the user's environment. I think that's what people mean when they say macOS lacks native containers.

Good point, apps are missing the docker layered file system to isolate container file writes.

It's not that macoscontainers is empty, it's that the site is https://darwin-containers.github.io

Read more about it here - https://github.com/darwin-containers

The developer is very responsive.

One of Apple's biggest value props to other platforms is environment integrity. This is why their containerization / automation story is worse than e.g. Android.

Ah, that's great! I'd forgotten it moved and struggled to track it down.

Hard same. I wonder if this does anything different to the existing projects that would mean one could use the WSL2 approach where containerd is running in the Linux micro-VM. A key component is the RPC framework - seems to be how orbstack's `macctl` command does it. I see mention of GRPC, sandboxes and containers in the binfmt_misc handling code, which is promising:

https://github.com/apple/containerization/blob/d1a8fae1aff6f...

What would these be useful for?

Same thing containers/jails are useful for on Linux and *BSD, without needing to spin up an entirely separate kernel to run in a VM to handle it.

MacOS apps can already be sandboxed. In fact it's a requirement to publish them to the Mac App Store. I agree it'd be nice to see this extended to userland binaries though.

You can't really sandbox development dependencies in any meaningful way. I want to throw everything and the kitchen sink into one container per project, not install a specific version of Python, Node, Perl or what have you globally/namespaced/whatever. Currently there's no good solution to that problem, save perhaps for a VM.

Hmm have you tried devenv?

https://devenv.sh/

UV is pretty good for python too.

uv doesn't provide strong isolation; a package you install using uv can attempt to delete random files in your home folder when you import it, for example.

People use containers server side in Linux land mostly... Some desktop apps (flatpak is basically a container runtime) but the real draw is server code.

Do you think people would be developing and/or distributing end user apps via macOS containers?

Orchestrating macOS only software, like Xcode, and software that benefits from Environment integrity, like browsers.

Clean build environments for CICD workflows, especially if you're building/deploying many separate projects and repos. Managing Macs as standalone build machines is still a huge headache in 2025.

What's wrong with Cirrus CLI and Tart built on Apple's Virtualization.framework?

https://tart.run

https://github.com/cirruslabs/cirrus-cli

Tart is great! This is probably the best thing available for now, though it runs into some limitations that Apple imposes for VMs. (Those limitations perhaps hint at why Apple hasn't implemented this-- it seems they don't really want people to be able to rent out many slices of Macs.

One clever and cool thing Tart actually does that sort of relates to this discussion is that it uses the OCI format for distributing OS images!

(It's also worth noting that Tart is proprietary. Some users might prefer something that's either open-source, built-in, or both.)

Providing isolated environments for CI machines and other build environments!

If the sandboxing features a native containerization system relied on were also exposed via public APIs, those could could also potentially be leveraged by developer tools that want to have/use better sandboxing on macOS. Docker and BuildKit have native support for Windows containers, for instance. If they could also support macOS the same way, that would be cool for facilitating isolated macOS builds without full fat VMs. Tools like Dagger could then support more reproducible build pipelines on macOS hosts.

It could also potentially provide better experiences for tools like devcontainers on macOS as well, since sharing portions of your filesystem to a VM is usually trickier and slower than just sharing those files with a container that runs under your same kernel.

For many of these use cases, Nix serves very well, giving "just enough" isolation for development tasks, but not too much. (I use devenv for this at work and at home.) But Nix implementations themselves could also benefit from this! Nix internally uses a sandbox to help ensure reproducible builds, but the implementation on macOS is quirky and incomplete compared to the one on Linux. (For reasons I've since forgotten, I keep it turned off on macOS.)

I might misunderstand the project, but I wish there was a secure way for me to execute github projects. Recently, the OS has provided some controls to limit access to files, etc. but I'd really like a "safe boot" version that doesn't allow the program to access the disk or network.

the firewall tools are too clunky (and imho unreliable).

ie: You want to build a binary for macOS from your Linux machine. Right now, it is possible but you still need a macOS license and to go through hoops. If you were able to containerize macOS, then you create a container and then compile your program inside it.

No, that's not at all how that would work. You're not building a macOS binary natively under a Linux kernel.

Reply on news.ycombinator.com