Show HN: Lumier – Run macOS VMs in a Docker

[GreenGames]

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!

[mynegation]

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

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

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

[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?

[kristianp]

Looks like your "&&"s might have gotten deleted in the following?

    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

Would you say that if macOS had namespaces and cgroups it would be much more useful and lightweight for this kind of use case?

[frabonacci]

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

[keepamovin]

FWIF i prefer the name Laminar

Think Laminar flow, because this is like super smooth macOS VM running in macOS

[frabonacci]

I like it - but there seems to be already another YC company with the name: https://lmnr.ai

[JayDustheadz]

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?

[frabonacci]

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/

[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

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

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

[roundup]

Would Lumier allow me to virtualize macOS with system integrity protection (SIP) disabled?

[frabonacci]

Yes, it should be possible: https://developer.apple.com/forums/thread/709453

Lumier does not expose the capability but the underlying Lume CLI does.

lume run <VM_NAME> --recovery-mode true: https://github.com/trycua/cua/tree/main/libs/lume#usage

[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

[OsrsNeedsf2P]

Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?

[Fizzadar]

https://github.com/sickcodes/Docker-OSX can do it

[busterarm]

Apple's licensing requires the host machine to be OSX. You cannot do what you're asking and be in license compliance.

[dmitrygr]

x86 macOS can be done (google is your friend). aarch64 macOS will be much harder since macOS relies on nonstandard extensions to aarch64.

[h4ck_th3_pl4n3t]

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.

[frabonacci]

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!