Hacker News

> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:

> - Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.

> - Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.

> -Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.

More details, including technical limitations (they’re looking for bug reports and contributions): “Container: Technical Overview” https://github.com/apple/container/blob/main/docs/technical-...

> ... highly integrated Linux environment that works seamlessly on your Mac. ...

Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?

> filesystem mounting

How is this different to bind mounts

Ah, the Darwin/BSD Subsystem for Linux.

how does that compare to something like, eg, Orbstack?

Still feels like a apple-ified microvm

I built this tool to solve that exact problem: https://github.com/smol-machines/smolvm

Why try to circumvent W^X page protection? Some sort of self-modifying program without extra pointer indirections?

https://github.com/apple/container/blob/main/docs/technical-... read documentation mr. rare breed

Darwin namespaces would be much more interesting and we are in dire need of them in the current security landscape.

I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.

[Replied to wrong comment]

sandbox profiles?

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

I'd like to see a comparison to https://tart.run/ as well.

AFAICT it's pretty similar.

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

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

I just wish bind mounts would be more performant/native. I get that this is probably impossible, and probably also sucks on Linux, haven't tried.

But like having containers that need file watchers like vite dev server, or frankenphp in watch mode will overload OrbStack real quick since It seems to fallback to polling instead of listening to fs events.

So I'm stuck running vite dev servers and the like on the host.

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.

Thank you for mentioning this, I have been suffering under the yoke of docker.

Note that orbstack supports audio and usb pass through, which is super nice

Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. In that case not exposing $HOME is just a small thing on your config to-do list.

[1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...

the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to.

i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.

No, the whole point of machines is their external interfaces? A Linux VM with no interfaces is just a closed box wasting power doing math.

And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..

No, the point of using such a thing is to be able to run Linux workloads. For example, I recently used Containerization to generate trace logs from the tup test suite so that I could bring it up to relative parity on macOS. If it had complete isolation, I would have difficulty getting the modified source code into the container and difficulty getting the trace logs back out of the container. Sure, you can paper over this with bind mounts or whatever the fuck but that's annoying

Isn't it wasteful? I know it's a "tiny" vm but still is a vm

Yes, that article states that as well under limitations: "Deprecation status: While functional, Apple discourages its direct use in favor of App Sandbox for developers."

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

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

Linux VMs on doesn't have to be expensive!

This explicitly provides a Linux VM, which seems hard to do without providing a Linux VM.

The use case is actually the opposite of what you seem to want (i.e. running Linux containers on macOS without a Linux VM); this uses a Linux-based container implementation of macOS to provide a long-lived Linux VM that looks more like a VM itself than a container.

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

The pain of working around Docker Desktop is bad.

this is more like toolbox/distrobox equivalent for MacOs, but running in individual VMs.

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

QEMU has worse performance than Apple's native virtualization framework on macOS, for one thing. That said, Lima supports the latter as well.

From a layman's POV ("I just want to run my containers I need for dev work"), there's no point in switching to this for now. It's just cool that Apple cares enough about containers and might come up with an Apple-like built-in solution some day, this is the groundwork.

I'd stick to Colima, or Orbstack if you trust them enough to not do a rug-pull once their users are reliant on them enough to pay any amount.

I’d argue they both admin that Linux servers are the target for a lot of applications to run on. Not to develop on.

Linux also can't openly admit that it's no match for macOS/Windows on the desktop, which is why we have this hybrid situation - macOS/Windows desktops running Linux VMs

Not really, this means the complete defeat of The Year of Linux Desktop.

Linux games depend on Windows ecosystem as their content source.

By having Linux nicely packaged in containers, they get to keep the 90% combined market share, almost no one bothers to support the market of Linux OEMs selling pre-installed Linux desktops and laptops.

The other "distros" used by consumers are Android, WebOs and going forward Googlebooks as Chromebooks evolution.

Meaning in the end a Pyrrhic victory, when Apple Linux, Microsoft Linux, Google Linux, Asus Linux, LG Linux, is all that the general public cares about, and hence no incentive for IT departments to support Linux laptops.

Enterprises would do anything to develop on Linux except using an actual Linux distro.

A lot of devs needs to use linux but they still use it just as a VM (Mac) or in some kind emulation (WSL). How pathetic.

Signed in just to say LoL at the dentist comment.

> Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it?

Yes’n’t: https://github.com/apple/container/blob/main/docs/technical-...

> container relies on the new features and enhancements present in macOS 26. You can run container on macOS 15, but you will need to be aware of some user experience and functional limitations. There is no plan to address issues found with macOS 15 that cannot be reproduced on macOS 26.

The issues are around networking.

It seems macOS Golden Gate (the upcoming version) fixes quite a few of the problems with Tahoe, so you might consider skipping Tahoe entirely.

>those of us holding out on Sequoia who can't stand the broken glass UI or what's called

Maybe hold 1 release back, but other than that, I don't think "holding out" on macOS releases has ever been a winning strategy.

In the end, macOS model presupposes users moving to the latest release sooner rather than later.

I turned off what "glass" UI I could with config, and it's not too different than Sequoia, got used to it pretty quick. Obviously the things not supported on an old OS will keep increasing, until eventually it is EOL'd.

Yeah I use Tahoe and I can't stand the liquid glass.

It looks like Golden Gate fixes this design a lot.

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.

Did you use their volumes for node_modules or a shared dir? I mounted the whole project directory (with node_modules) inside the container and it seems to work fine (MBA M1 8 GB RAM).

> dockerhub images don't work as machine images because container machine expects systemd

Are you sure about that? A few comments above a commenter states that they don’t run inits at all (because they ran alpine), multiple people replied that it works fine if you give it an image with an init, and they acknowledged their error.

Apple does have an OCI variant of this: https://github.com/apple/container

Doesn’t seem to have Compose support though, but it’s probably not impossible to build upon.

And of course, it also uses VMs, though unlike Docker, it’s one (micro-?) VM per container: https://github.com/apple/container/blob/main/docs/technical-...

> moved completely to systemd isolation

On MacOS?

FreeBSD has Linuxlator because there is a lot of binary only software that was never and never will be ported to BSD, so it's necessary for them in order to avoid bleeding users away. Conversely, macOS has basically all software ported natively to it, so when you _need_ a Linux environment 95% of the time it isn't because you need $XYZ that only run Linux, but because you need a proper Linux environment with systemd, cgroups etc. Implementing that stuff on top of XNU would probably be extremely expensive and it would arguably defeat the point of having their own kernel in the first place.

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?

Might consider https://github.com/smol-machines/smolvm

It's a full vm

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

Isn't that just expected for modern macOS devices? They have been on arm64 for 6 years now.

it differs by lacking all the cool options that makes vmware and virtualbox good products, but apple users will praise it as a benefit

"bind mounts? I'm better without it"

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?

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

I don't think so. This is a VM, closer to WSL2.

Proton is based on Wine which translates Windows instructions to Linux.

Besides there's already Wine for mac.

But I would love to be wrong here.

Also works with UTM.

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.

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.

Isn't docker on mac os still a large preallocated linux VM that runs the containers inside itself? With this maybe you can separate them.

You can run amd64 binaries inside an aarch64 Linux virtual machine. Although they're not supporting Rosetta for macOS apps from macOS 27, the Rosetta support in Virtualization Framework will remain.

What’s the performance when you do that?

Rosetta should be supported

Interesting, what devices would you want to pass through?

Considering that this project was published less than 24 hours ago I’m guessing you assume it’s a different project.

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

Blog post soon

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.

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

Isn't multiphase is Ubuntu only?

Install Windows 11 ARM under the macOS "UTM" App. This lets you run x86 Windows programs on Apple silicon.

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.

Allocation of a finite amount of engineering resources.

The underlying Virtualization Framework works on Intel Macs, but they'll miss out on new features landing in macOS 27 and beyond.

There _is_ Podman Desktop extension for Apple Containers, however its socktainer version is ancient.

A native replacement for docker came last year with Apple Containers- this extends that.

On the one hand yes, on the other hand there are already multiple lighter alternatives to docker on mac.

Yes

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

> FROM apple/macos:10.11.6

Yeah I was working on that, created a prototype. I don't see a business in it, so abandoned.

Close - but it would be more like this:

  services:
    macos:
      image: dockurr/macos
      container_name: macos
      environment:
        VERSION: "15"

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

i wish!

try unplugging your keyboard and then plugging it back in