Show HN: Lumier – Run macOS VMs in a Docker

https://github.com/trycua/cua/tree/main/libs/lumier

159•GreenGames•8mo ago

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!

Comments

mynegation•8mo 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.

frabonacci•8mo ago

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•8mo ago

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•8mo ago

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

notpushkin•8mo ago

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 :-)

frabonacci•8mo ago

Thank you for the support! One idea we’ve been exploring is reusing the same Apple VZ backend that Docker itself uses to run a nested macOS VM from inside the container. That would avoid the need for a background service on the host, but it would require patching parts of Docker and only work on M3+ chips, since earlier Apple Silicon doesn’t support nested virtualization

riffic•8mo 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.

frabonacci•8mo ago

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•8mo ago

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•8mo 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•8mo ago

Docker uses a Linux VM to run on macOS.

RobMurray•8mo 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?

nottorp•8mo 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?

frabonacci•8mo ago

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

mbreese•8mo ago

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)

frabonacci•8mo ago

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

nottorp•7mo ago

> inside a lightweight Linux VM

Docker VMM, the latest virtualization option for Apple Silicon Macs, requires a minimum of 4GB of memory to be allocated to the Docker Linux VM.

Or so says an "AI", I'm not installing Docker on this laptop to check, I have limited RAM :)

frabonacci•8mo 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

handfuloflight•8mo ago

Would it be possible to spin up VMs inside of a https://aws.amazon.com/ec2/instance-types/mac/?

frabonacci•8mo ago

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•8mo ago

I already do this with UTM. Whats the difference? Worth converting?

frabonacci•8mo ago

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.

kelsey98765431•8mo ago

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•8mo ago

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•8mo ago

Super nice! Do you think it's possible to run XCode and do an app build with this approach?

frabonacci•8mo ago

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•8mo ago

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

frabonacci•8mo ago

Yes, you can build and host your own Mac base images directly using the lume CLI. See the usage guide at: https://github.com/trycua/cua/tree/main/libs/lume#usage

Currently, lume supports pushing to GitHub Container Registry (GHCR). However, it’s feasible to extend support to any OCI-compatible registry in the future.

Steps to build and push a custom image:

1. Start by creating a new VM or pulling an existing image. Launch the VM, make your desired modifications, and use it as your golden image.

2. Generate a classic access token on GitHub. Then: export GITHUB_USERNAME=<your_github_username> export GITHUB_TOKEN=<your_github_token>

3. Push your custom image: lume push "<VM_NAME_TO_PUSH>" "<IMAGE_NAME>:<TAG>" --registry ghcr.io --organization "<your_org_id>" --additional-tags "<optional_additional_tags>"

Example: lume push "lume_vm" "macos-sequoia-cua:latest" --registry ghcr.io --organization "trycua" --additional-tags "15.2"

Pull your image later with: lume pull "macos-sequoia-cua:latest" --registry ghcr.io --organization "trycua"

There is no mandatory dependency on the Cua-hosted registry - you are free to maintain your own image registry using GHCR or another OCI-compatible alternative (with some extension work).

shykes•8mo ago

Thanks! Do you rely on bleeding edge OCI features like artifacts, or on the original features? I'm asking to get a sense of how many registries would work out of the box with this.

I'm excited to play with lume! My use case is adding native Mac execution to Dagger (https://dagger.io) :)

frabonacci•8mo ago

We stick to standard OCI features: just basic manifests, layers, and configs - without relying on newer or experimental functionality like OCI artifacts. That means it should work out of the box with most registries, including Docker Hub, GitHub Container Registry, and any other OCI-compliant registry.

The relevant code is here: https://github.com/trycua/cua/blob/main/libs/lume/src/Contai...

And thanks again - really appreciate the interest. I’ll follow up via email, would love to hear more about the Dagger use case and how native Mac execution fits in!

OsrsNeedsf2P•8mo ago

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

Fizzadar•8mo ago

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

busterarm•8mo ago

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

frabonacci•8mo ago

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.

jamesy0ung•8mo ago

I'm pretty sure the requirement is that the hardware is an Apple Mac, I don't remember macOS being your Hypervisor a requirement. ESXI supports running macOS on Apple Hardware (it extracts the key from the SMC).

busterarm•7mo ago

That's not correct.

See Sequoia's license. Search for 'virtualization'.

    D. Virtualization. For each copy of the Apple Software subject to a lease under this Section 3, either a Lessor or a Lessee (but not both) may install, use and run additional copies or instances of the Apple Software within virtual operating system environments in accordance with Section 2B(iii), provided that a Lessor may only virtualize a single instance or copy of the Apple Software as a provisioning tool for the purpose of providing a Lessee with access to and use of the Apple Software pursuant to this Section 3. 

    (Section 2B) (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.

The key phrase is "on each Apple-branded computer you own or control that is already running the Apple Software". It needs to be both an Apple host machine and already running the Apple OS that you're virtualizing.

fragmede•7mo ago

I've read that three times, and it doesn't seem to prohibit running it on a LinuxVM, as long as the hypervisor is also macOS. Specifically, you'd use macOS as the hypervisor, run a Linux guest, then use nested virtualization (which is supported recently on M3+ mac's) to run macOS on top of that Linux guest.

Why you might ask? Because your existing tooling is already on Linux, so it's easier to manage (for whatever reason) with a semi-homogeneous control plane.

dmitrygr•8mo ago

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

frabonacci•8mo ago

Exactly, both https://github.com/dockur/macos and https://github.com/sickcodes/Docker-OSX rely on x86 and KVM for HW acceleration

h4ck_th3_pl4n3t•8mo ago

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•8mo ago

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!

kristianp•8mo ago

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•8mo ago

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

JayDustheadz•7mo 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?

frabonacci•7mo ago

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/

JayDustheadz•7mo ago

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!

roundup•7mo ago

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

frabonacci•7mo ago

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

keepamovin•7mo ago

FWIF i prefer the name Laminar

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

frabonacci•7mo ago

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

keepamovin•7mo ago

Never stopped anyone before!

frabonacci•7mo ago

that's also true :)

“Erdos problem #728 was solved more or less autonomously by AI”

Flock Hardcoded the Password for America's Surveillance Infrastructure 53 Times

JavaScript Demos in 140 Characters

RTX 5090 and Raspberry Pi: Can it game?

Robotopia: A 3D, first-person, talking simulator

Show HN: Rocket Launch and Orbit Simulator

How Markdown took over the world

How will the miracle happen today?

Show HN: Scroll Wikipedia like TikTok

Scientists discover oldest poison, on 60k-year-old arrows

Cloudflare CEO on the Italy fines

Greenland sharks maintain vision for centuries through DNA repair mechanism

My article on why AI is great (or terrible) or how to use it

Show HN: Miditui – a terminal app/UI for MIDI composing, mixing, and playback

Deno has made its PyPI distribution official

Show HN: I made a memory game to teach you to play piano by ear

Turn a single image into a navigable 3D Gaussian Splat with depth

Kagi releases alpha version of Orion for Linux

Favorite Tech Museums

Show HN: Yellopages – New tab Chrome extension

Show HN: A website that auctions itself daily

QtNat – Open you port with Qt UPnP

Show HN: Similarity = cosine(your_GitHub_stars, Karpathy) Client-side

How to store a chess position in 26 bytes (2022)

Amiga Pointer Archive

Replit (YC W18) Is Hiring

The (likely?) cheapest home-made Michelson interferometer

The Vietnam government has banned rooted phones from using any banking app

See it with your lying ears

How to code Claude Code in 200 lines of code

“Erdos problem #728 was solved more or less autonomously by AI”

Flock Hardcoded the Password for America's Surveillance Infrastructure 53 Times

JavaScript Demos in 140 Characters

RTX 5090 and Raspberry Pi: Can it game?

Robotopia: A 3D, first-person, talking simulator

Show HN: Rocket Launch and Orbit Simulator

How Markdown took over the world

How will the miracle happen today?

Show HN: Scroll Wikipedia like TikTok

Scientists discover oldest poison, on 60k-year-old arrows

Cloudflare CEO on the Italy fines

Greenland sharks maintain vision for centuries through DNA repair mechanism

My article on why AI is great (or terrible) or how to use it

Show HN: Miditui – a terminal app/UI for MIDI composing, mixing, and playback

Deno has made its PyPI distribution official

Show HN: I made a memory game to teach you to play piano by ear

Turn a single image into a navigable 3D Gaussian Splat with depth

Kagi releases alpha version of Orion for Linux

Favorite Tech Museums

Show HN: Yellopages – New tab Chrome extension

Show HN: A website that auctions itself daily

QtNat – Open you port with Qt UPnP

Show HN: Similarity = cosine(your_GitHub_stars, Karpathy) Client-side

How to store a chess position in 26 bytes (2022)

Amiga Pointer Archive

Replit (YC W18) Is Hiring

The (likely?) cheapest home-made Michelson interferometer

The Vietnam government has banned rooted phones from using any banking app

See it with your lying ears

How to code Claude Code in 200 lines of code

Show HN: Lumier – Run macOS VMs in a Docker

Comments