Show HN: Lumier – Run macOS VMs in a Docker
34 comments
·May 14, 2025mynegation
From 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.
frabonacci
Correct. Docker in this case acts more as a delivery and management plane, rather than providing process isolation. Similar to how dockur/windows or qemus/qemu rely on --device=/dev/kvm to spin up VMs on Linux hosts, we use a background service that interfaces with Apple’s Virtualization Framework (Vz) to provision real VMs on the macOS host. The container connects to this service via host.docker.internal, allowing full interop between the Docker-based interface and the host-based virtualization layer
notpushkin
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)
frabonacci
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, streamlining setup for some users.
On a comparison with Tart, UTM, Lima, we actually touch it in this GitHub discussion: https://github.com/trycua/cua/issues/10
riffic
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.
frabonacci
Not yet. Darwin doesn’t support kernel-level containerization like namespaces and cgroups in Linux. Most tooling ends up relying on full VMs (via Apple’s VZ framework) for isolation. Agree though: there's a growing use case Apple could lean into more directly.
Usually they are responsive to these feedbacks, we'll try to mention on a existing GH issue: https://github.com/Developer-Ecosystem-Engineering
nottorp
So, since the host is mac os, you need to run a linux VM to be able to quickly instantiate a mac os VM?
With Apple's RAM prices?
frabonacci
Not quite, there's no need to run a Linux VM on macOS just to spin up macOS VMs.
Since the host is already macOS, we leverage the Apple Virtualization Framework (Vz) directly via a lightweight background service (lume). The Docker container (Lumier) acts purely as a frontend and delivery mechanism for managing and launching VMs — there's no nested virtualization or Linux VM involved.
That said, you're absolutely right that macOS hardware isn’t cheap, and RAM can be a real constraint. If you're running multiple VMs or aiming for production-scale setups, options like Scaleway’s M4 Mac minis or EC2 Mac Metal instances offer more headroom.
Also worth noting: while Lumier supports virtualizing Linux VMs too, if your use case is only Linux, there are far more cost-effective options using KVM on Linux hosts.
notpushkin
Docker uses a Linux VM to run on macOS.
RobMurray
Docker does seem to be an unnecessary overhead considering it's reliance on a Linux VM. What does Docker bring to the table that couldn't easily be replaced with a native Mac app?
nottorp
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?
frabonacci
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
frabonacci
Totally get your point. Docker isn’t about performance here. It’s just used as a management interface to connect to VMs running directly on the macOS host via Apple’s Vz. We went with this approach for Lume because Docker offers a familiar, automation-friendly workflow—great for CI, AI agents, and bundling things like noVNC
helpfulContrib
I already do this with UTM. Whats the difference? Worth converting?
frabonacci
A couple of key differences are that Lumier provides browser-based desktop streaming via noVNC and a Docker‑based, CLI/headless management plane - along with both ephemeral and persistent 'containers', which are especially useful for CI or computer-use AI agent workflows and evals.
OsrsNeedsf2P
Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?
busterarm
Apple's licensing requires the host machine to be OSX. You cannot do what you're asking and be in license compliance.
frabonacci
Correct. Apple's licensing requires macOS to run on Apple hardware, and limits you to 2 concurrent macOS VMs per host. This is enforced by the Apple Vz framework itself. Some KVM-based solutions bypass these checks, but they aren’t compliant for production use.
There’s instead no such limitation when running Linux VMs on a macOS host.
dmitrygr
x86 macOS can be done (google is your friend). aarch64 macOS will be much harder since macOS relies on nonstandard extensions to aarch64.
handfuloflight
Would it be possible to spin up VMs inside of a https://aws.amazon.com/ec2/instance-types/mac/?
frabonacci
Yes, running virtualized workloads at scale is one of our primary use cases. We're already deploying Lumier-based VMs on macOS GitHub runners, AWS EC2 Mac instances, and Scaleway.
Notably, Scaleway is one of the few providers to offer M4-based Mac minis that support nested virtualization. The main caveat is that these are currently only available in EU regions.
kelsey98765431
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.
frabonacci
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
cyberax
Super nice! Do you think it's possible to run XCode and do an app build with this approach?
frabonacci
Yes! That’s actually what https://tuist.dev is doing. They use Lume to spin up ephemeral macOS VMs with Xcode preinstalled, so they can run builds in clean, reproducible environments. It’s great for CI workflows where you want full macOS without managing long-lived hosts
shykes
Is it possible to build and host our own Mac base images? Or is there a mandatory dependency to Cua's hosted registry?
ChocolateGod
So it uses a Docker container (running in a Linux VM) to connect to a VM running on the macOS host.
Seems like pointless overhead.
null
Hey HN, we're excited to share Lumier (https://github.com/trycua/cua/tree/main/libs/lumier), an open-source tool for running macOS and Linux virtual machines in Docker containers on Apple Silicon Macs.
When building virtualized environments for AI agents, we needed a reproducible way to package and distribute macOS VMs. Inspired by projects like dockur/windows (https://github.com/dockur/windows) that pioneered running Windows in Docker, we wanted to create something similar but optimized for Apple Silicon. The existing solutions either didn't support M-series chips or relied on KVM/Intel emulation, which was slow and cumbersome. We realized we could leverage Apple's Virtualization Framework to create a much better experience.
Lumier takes a different approach: it uses Docker as a delivery mechanism (not for isolation) and connects to a lightweight virtualization service (lume) running on your Mac. This creates true hardware-accelerated VMs using Apple's native virtualization capabilities.
With Lumier, you can: - Launch a ready-to-use macOS VM in minutes with zero manual setup - Access your VM through any web browser via VNC - Share files between your host and VM effortlessly - Use persistent storage or ephemeral mode for quick tests - Automate VM startup with custom scripts
All of this works natively on Apple Silicon (M1/M2/M3/M4) - no emulation required.
To get started:
1. Install Docker for Apple Silicon: https://desktop.docker.com/mac/main/arm64/Docker.dmg
2. Install lume background service with our one-liner:
3. Start a VM (ephemeral mode): 4. Open http://localhost:8006/vnc.html in your browser. The container will generate a unique password for each VM instance - you'll see it in the container logs.For persistent storage (so your changes survive container restarts):
mkdir -p storage docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -v $(pwd)/storage:/storage \ -e VM_NAME=lumier-vm \ -e HOST_STORAGE_PATH=$(pwd)/storage \ trycua/lumier:latest
Want to share files with your VM? Just add another volume:
mkdir -p shared docker run ... -v $(pwd)/shared:/shared -e HOST_SHARED_PATH=$(pwd)/shared ...
You can even automate VM startup by placing an on-logon.sh script in shared/lifecycle/.
We're seeing people use Lumier for: - Development and testing environments that need macOS - CI/CD pipelines for Apple platform apps - Disposable macOS instances for security research - Automated UI testing across macOS versions - Running AI agents in isolated environments
Lumier is 100% open-source under the MIT license. We're actively developing it as part of our work on C/ua (https://github.com/trycua/cua), and we'd love your feedback, bug reports, or feature ideas.
We'll be here to answer any technical questions and look forward to your comments!