←back to thread

159 points GreenGames | 5 comments | | HN request time: 1.156s | source

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!

Show context
mynegation ◴[] No.43986022[source]
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.
replies(2): >>43986263 #>>43987526 #
1. frabonacci ◴[] No.43986263[source]
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
replies(1): >>43986494 #
2. notpushkin ◴[] No.43986494[source]
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)

replies(1): >>43986774 #
3. frabonacci ◴[] No.43986774[source]
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

replies(1): >>43987489 #
4. notpushkin ◴[] No.43987489{3}[source]
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 :-)

replies(1): >>43990940 #
5. frabonacci ◴[] No.43990940{4}[source]
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