how does the docker guest orchestrate a completely different virtualization system? is the guest container in docker given access to the host system to then spin up the apple vm guest? to me this seems very risky in terms of security.
Show HN: Lumier – Run macOS VMs in a Docker
21–30 of 59 posts
Re: Show HN: Lumier – Run macOS VMs in a Docker
#22Super nice! Do you think it's possible to run XCode and do an app build with this approach?
Re: Show HN: Lumier – Run macOS VMs in a Docker
#23Earlier quoted context omitted.
The title is a bit misleading then :) What’s the difference between this vs just using your lume CLI? Right now it feels like a worse interface to lume, but maybe I’m not getting a use case for this. Also, any thoughts on https://github.com/cirruslabs/tart ? (alas, not open source)
You’re right, Lumier might seem similar to Lume CLI, but it adds browser-based desktop streaming via noVNC and integrates with Docker for easier management, which is a familiar interface for many developers. Since our parent project C/ua will use KVM-based containers on x86/x64 hosts, aligning to a container interface here seems a natural step for us. Docker also allows packaging noVNC as a self-contained dependency,…
There’s no mention of Tart in there, but I’ve looked into Lume CLI some more and it seems it’s basically a superset of Tart in functionality. (And both use container registries as the VM image store, neat!)
> aligning to a container interface here seems a natural step for us
It might be tricky since you do have to escape from the container to run the actual VM, though I guess you can figure something out here. I still think it’s the wrong layer to build your abstractions upon, but let’s see how it goes! Just don’t discontinue the CLI, it’s really cool :-)
Re: Show HN: Lumier – Run macOS VMs in a Docker
#24From what I understand VM does _not_ run in docker. The management interface does and connects to the VM running on macOS ARM host via Apple Virtualization Framework.
been a while since it's come up but does Darwin support kernel level containerization yet?
Apple should recognize the use case or utility and run with it.
Re: Show HN: Lumier – Run macOS VMs in a Docker
#25Earlier quoted context omitted.
That was my point, and that was the Linux VM dependency that the OP doesn't realize exists. Also there's some permanently running service. What's the point, to save 30 milliseconds out of the time to set up a VM which is certainly measured in tens of seconds?
The primary benefit here is automation and ease of management, especially for CI or AI agent workflows, rather than saving tiny amounts of time on VM setup. Docker's role is to offer a consistent and familiar management interface, which can be useful for automation and scaling, not for shaving milliseconds off VM boot times
What I think you’re not addressing is the question about the Linux VM that Docker requires on a Mac. I don’t think there is a question about the benefits of Docker from a management point of view. The question is — is it worth keeping around a running Linux VM just to get those management benefits. Since you’re not actually using Docker (the daemon) to run Macs in a container, how much of that micro Linux VM is necessary? Is that overhead worth it?
(This is coming from someone who keeps colima running all the time on my Mac)
Re: Show HN: Lumier – Run macOS VMs in a Docker
#26Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?
Re: Show HN: Lumier – Run macOS VMs in a Docker
#27Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?
https://github.com/sickcodes/Docker-OSX can do it
Re: Show HN: Lumier – Run macOS VMs in a Docker
#28Earlier quoted context omitted.
The primary benefit here is automation and ease of management, especially for CI or AI agent workflows, rather than saving tiny amounts of time on VM setup. Docker's role is to offer a consistent and familiar management interface, which can be useful for automation and scaling, not for shaving milliseconds off VM boot times
What I think you’re not addressing is the question about the Linux VM that Docker requires on a Mac. I don’t think there is a question about the benefits of Docker from a management point of view. The question is — is it worth keeping around a running Linux VM just to get those management benefits. Since you’re not actually using Docker (the daemon) to run Macs in a container, how much of that micro Linux VM is neces…
Great question, and totally fair.
You're right that Docker on macOS runs inside a lightweight Linux VM (via Docker Desktop or Colima). We’re not using that VM to run the macOS guests - those run directly on the host via Apple’s Vz — but we do use Docker as a packaging and management layer (e.g. bundling noVNC, CLI tools, and configs).
So is it strictly necessary? Not really. But for teams already using Docker in CI/CD or automated workflows, it's often a tradeoff they're already making - and it means one less new tool/interface to adopt.
That said, we’re also looking into potentially using nested virtualization within the Docker daemon (which relies on Apple Vz under the hood) on M3+ chips, so as to remove the background service on the host entirely
Re: Show HN: Lumier – Run macOS VMs in a Docker
#29Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?
Apple's licensing requires the host machine to be OSX. You cannot do what you're asking and be in license compliance.
Re: Show HN: Lumier – Run macOS VMs in a Docker
#30how does the docker guest orchestrate a completely different virtualization system? is the guest container in docker given access to the host system to then spin up the apple vm guest? to me this seems very risky in terms of security.
It actually works more like a frontend talking to an API than 'inside' touches 'outside'. The container just reaches out over host.docker.internal to the Lume daemon running on your Mac. Lume is the only thing talking to Apple's Vz API and spinning up VMs. The container itself never gets direct low‑level access to the host's virtualization stack, so you're not giving Docker root powers over your Mac's hypervisor, just a handy layer that calls into a service with the right privileges