Show HN: Lumier – Run macOS VMs in a Docker
1 day ago (github.com)
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:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/lume/scripts/install.sh)"
3. Start a VM (ephemeral mode):
docker run -it --rm \
--name lumier-vm \
-p 8006:8006 \
-e VM_NAME=lumier-vm \
-e VERSION=ghcr.io/trycua/macos-sequoia-cua:latest \
-e CPU_CORES=4 \
-e RAM_SIZE=8192 \
trycua/lumier:latest
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!
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.
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
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)
3 replies →
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.
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
Would Lumier allow me to virtualize macOS with system integrity protection (SIP) disabled?
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?
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.
Docker uses a Linux VM to run on macOS.
1 reply →
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?
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
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?
4 replies →
Looks like your "&&"s might have gotten deleted in the following?
Would you say that if macOS had namespaces and cgroups it would be much more useful and lightweight for this kind of use case?
Good catch. Yes, looks like the line breaks ate the &&s.
And absolutely, if macOS supported namespaces and cgroups natively, it’d open the door to more lightweight, container-native workflows. Right now we work around it with Apple’s Virtualization Framework and treat Docker more as a familiar control plane than a true runtime isolation layer
I'll ask again, since I didn't receive an answer up till now: is it capable of running macOS Big Sur on an ( Apple Silicon{M1 or later} + macOS Monterey{or higher} ) host? If so, would I be able to install apps via App Store on this Big Sur?
Yes, Lume supports running macOS Big Sur as a guest on Apple Silicon (M1 or later) hosts running Monterey or newer, as long as you’re using an ARM64 build of Big Sur.
However, App Store sign-in is currently not supported inside macOS VMs due to how Apple handles hardware entitlements and secure boot in virtualized environments.
That said, with macOS Sequoia, Apple has relaxed some constraints — you can now sign into iCloud inside a VM, which enables direct downloads of stable or beta Xcode installers without needing the App Store. More details here:
https://eclecticlight.co/2024/07/12/sequoia-virtualisation-a...
https://developer.apple.com/documentation/virtualization/usi...
https://xcodereleases.com/
Thanks, but the issue is I don't need XCode. It's a weird use case, I know - I need to be able to access App Store to download old versions of Apple's Motion/Final Cut Pro, ones that are only available for Big Sur. If this is somehow possible, then I would really appreciate any tips, thanks!
Would it be possible to spin up VMs inside of a https://aws.amazon.com/ec2/instance-types/mac/?
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.
I already do this with UTM. Whats the difference? Worth converting?
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.
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.
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
Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?
https://github.com/sickcodes/Docker-OSX can do it
Apple's licensing requires the host machine to be OSX. You cannot do what you're asking and be in license compliance.
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.
3 replies →
x86 macOS can be done (google is your friend). aarch64 macOS will be much harder since macOS relies on nonstandard extensions to aarch64.
Exactly, both https://github.com/dockur/macos and https://github.com/sickcodes/Docker-OSX rely on x86 and KVM for HW acceleration
This is not "running macOS VMs in Docker".
This is "running debian noVNC clients in Docker that connect to the same macOS host system".
I mean it's great that you use the Apple Virtualization Framework for that on the host service, but that's a different type of VM than a docker VM which would assume syscalls to be abstracted inside the docker container and not on a host service.
But yeah, just my two cents, I guess.
You're totally right, we're not claiming to run macOS inside Docker. The actual VMs run on the macOS host via the Apple Virtualization.Framework; Docker is just the management and packaging layer, similar to how some KVM setups use Docker to orchestrate VMs on Linux.
The title could’ve been clearer, but it’s already out there and can’t be edited - appreciate you pointing it out and adding the nuance!
Super nice! Do you think it's possible to run XCode and do an app build with this approach?
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
Is it possible to build and host our own Mac base images? Or is there a mandatory dependency to Cua's hosted registry?
3 replies →
[flagged]
[flagged]