Show HN: Lumier – Run macOS VMs in a Docker

Show HN: Lumier – Run macOS VMs in a Docker github.com/trycua/cua/tre...

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!

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 · 10 months ago

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 · 10 months ago

Docker uses a Linux VM to run on macOS.

RobMurray · 10 months ago

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?

frabonacci · 10 months ago

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

nottorp · 10 months ago

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?

mynegation · 10 months ago

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)

riffic · 10 months ago

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

kristianp · 10 months ago

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

keepamovin · 10 months ago

FWIF i prefer the name Laminar

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

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

Never stopped anyone before!

JayDustheadz · 10 months ago

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!

cyberax · 10 months ago

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

shykes · 10 months ago

Is it possible to build and host our own Mac base images? Or is there a mandatory dependency to Cua's hosted registry?

handfuloflight · 10 months ago

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.

helpfulContrib · 10 months ago

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.