[HN Gopher] Show HN: Lumier - Run macOS VMs in a Docker
___________________________________________________________________
Show HN: Lumier - Run macOS VMs in a Docker
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!
Author : GreenGames
Score : 105 points
Date : 2025-05-14 15:19 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mynegation wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| :-)
| riffic wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Docker uses a Linux VM to run on macOS.
| RobMurray wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| frabonacci wrote:
| 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 wrote:
| Would it be possible to spin up VMs inside of a
| https://aws.amazon.com/ec2/instance-types/mac/?
| frabonacci wrote:
| 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 wrote:
| I already do this with UTM. Whats the difference? Worth
| converting?
| frabonacci wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Super nice! Do you think it's possible to run XCode and do an app
| build with this approach?
| frabonacci wrote:
| 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 wrote:
| Is it possible to build and host our own Mac base images? Or
| is there a mandatory dependency to Cua's hosted registry?
| frabonacci wrote:
| 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 wrote:
| 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) :)
| OsrsNeedsf2P wrote:
| Slightly off topic, does anyone know a good way to run Mac VMs on
| Linux hosts?
| Fizzadar wrote:
| https://github.com/sickcodes/Docker-OSX can do it
| busterarm wrote:
| Apple's licensing requires the host machine to be OSX. You
| cannot do what you're asking and be in license compliance.
| frabonacci wrote:
| 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 wrote:
| 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).
| dmitrygr wrote:
| x86 macOS can be done (google is your friend). aarch64 macOS
| will be much harder since macOS relies on nonstandard
| extensions to aarch64.
___________________________________________________________________
(page generated 2025-05-14 23:01 UTC)