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/

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

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

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

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!

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!

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

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

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.

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

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

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

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

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

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

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.

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.

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.

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

We just released Part 2 of the "Build Your Own Operator on macOS" series, featuring a high-level framework (cua-agent) that simplifies building agents in virtual macOS/Linux environments. It abstracts away much of the complexity while keeping full control when needed. Repo and writeup inside.

This could play very well with building a managed agentic system around computer-use for RPA. Great stuff!

Cua's basically a virtual Mac/Linux box that any LLM can drive, move the mouse, click buttons, type stuff. So it can use any desktop app like human would do, even if there’s no API

Thanks! I'd love to hear more about your use case!

Thank you! If you're looking for a Docker alternative to something like e2b, we're planning to ship a containerized version of c/ua that also handles VNC and model hosting. Right now we're using the Lume CLI (https://github.com/trycua/cua/tree/main/libs/lume) with an API server on the host as a lightweight alternative, but the Docker setup will make it easier to self-host and extend. Would love to hear what kind of workloads or use cases you had in mind!

Thank you, really appreciate that! Curious - did you end up using QEMU for your Linux VMs? And are you running your system locally or in the cloud?

We’re currently focused on macOS but planning to support Linux soon, so I’d love to hear more about your use case. Feel free to reach out at founders@trycua.com - always great to learn from others building in this space.

Glad you love it! Right now, we’re relying more on the Lume CLI and its API server rather than a full Docker setup. However, we’ll soon be shipping a Docker interface that’ll handle VNC and model hosting (through docker model runner). Stay tuned for that!

UI detection’s a big focus - we use visual grounding + structured observations (like icons, OCR, app metadata, window state), so the agent can reason more like a user would. It’s surprisingly robust even with layout shifts or new themes

Thank you!!

100% - ephemeral VMs are on the roadmap. Perfect for CI: spin up, run the agent, nuke it

Appreciate that a lot! Yep - buying fashion drops, limited releases, ticketing, etc. are all great fits. Cua can also bypass CryptoJS-based encryption and other anti-bot measures, so it plays nicely with modern web apps out of the box.