You're both right - Apple's official zero-touch setup requires MDM + DEP, which needs Apple Business Manager (and yes, a DUNS number).
But for VMs specifically, DEP doesn't work anyway - VMs don't have real serial numbers that can be enrolled in Device Enrollment Program.
VNC-based setup automation is the only practical option - it's what the ecosystem has converged on for macOS VMs. Lume connects to the VM's VNC server and programmatically tabs, clicks, types through Setup Assistant.
I wish the virtualization framework would allow you to simulate your own MDM stuff. Would be very useful for integration testing MDM implementations themselves...
The key difference: dockur/macos uses QEMU+KVM, which only works on Linux hosts. It can't run on macOS hardware since Apple doesn't expose KVM. See: https://github.com/dockur/macos/issues/256
I tried to set up a macOS VM recently so I could run an old version of iTunes to manage my iPods. I found it nearly impossible to even download an installer for older versions of the OS, and could never get it working. Where can one acquire an IPSW for, say, macOS Mojave? My understanding is this is not the same thing as the “Install macOS.app”?
For a version of macOS that old, you’d probably want a dmg, which you can create with createinstallmedia if you have the Install macOS.app. Not sure if it’s supported with Lume as it’s the first time I’ve heard of it.
LoganDark is right. I've personally never tried, and don't think it'd be easy for any macOS predating Apple Virtualization Framework. For that you'd need something like UTM since they're relying on QEMU - these configs might help: https://github.com/adespoton/utmconfigs
I was trying to do something similar last year and gave up because it felt futile. That said, it was the push I needed to try Rockbox, and I haven't looked back. Managing things via the file system is really nice.
I started on my Linux box and despite many apps claiming to support iPods, none would actually work. I ended up getting an old Mac mini running again and I’m using that for now. I’ve never given Rockbox a good look, I should check it out.
Nice, thanks for sharing! It'd be interesting to integrate MIST into lume's ipsw command - right now Apple's native features in Apple Vz only provides download links for the latest supported version of the host, so grabbing older versions requires workarounds like this.
I believe this is using Virtualization.framework and not Containerization API from Tahoe, right?
Is there a limit on number of instances you can have per physical mac? i recall there was a hard limit of 2 because of EULA, unless Apple has changed it. (Cupertino really likes to sell you their Macs)
We haven't observed any networking degradation with Lume on Tahoe so far - things have been working smoothly in our testing. Give it a try and let us know if you run into any issues!
"We built a VNC + OCR system that clicks through macOS Setup Assistant automatically" - that is both awesome and annoying. I guess I assumed that Apple supported some form of unattended setup.
Yeah, Apple intentionally provides no unattended setup. Plus any process trying to control the UI programmatically needs explicit accessibility permissions, which defeats the purpose.
So we just click through like a human would via VNC. Version-specific but works with their security model rather than against it.
Both use Apple's Virtualization Framework, so core VM performance is similar. Main differences are around agent-first design (HTTP API, MCP server), unattended setup via VNC + OCR, and registry support for VM images.
We've also built a broader ecosystem on top - the Cua computer and agent framework for building computer-use agents: https://cua.ai/docs
Not seeing any reference to Tart at that link. Tart also has registry support for VM images it treats them very much like Docker images, is that what you are doing too?
Is it worth putting a comparison up somewhere other than a Github thread? Seems to be a frequently asked question at this point.
Also worth drawing attention to Tart being source available not open source.
Thanks much appreciated, the "Registry Support" section is weird though. Isn't GHCR an instance of an OCI registry? The when to choose Loom in the Tart section should also mention licensing, it is relevant at the choosing point.
Good changes, like the new theme too, I'd still match the two boxes if it were me (both should read OCI registry and optionally include GHCR but they should be identical)
> Lume automates the macOS Setup Assistant via VNC and OCR, creating ready-to-use VMs without manual clicking. Tart relies on Packer plugins for automation.
This feels disingenuous. Tart has unattended setup support as well, and it's based on the same VNC + OCR technique as Lume. In fact Tart had it first, and your approach seems to be heavily inspired by it. In addition the boot command instructions you're using came from https://github.com/cirruslabs/macos-image-templates/
The only material difference is whether it's built-in or integrated via Packer.
Looked at Lume before and it was already very impressive then. For this unattended use case this looks amazing.
Slight tangent - do the VMs have decent graphics performance? I live in fear of one day accidentally pressing the Update button and being forced into the GUI mess that is Tahoe. Knowing I could just use a VM with Sequioa as my primary desktop would dramatically lower my anxiety.
Thanks! On graphics - currently it's paravirtualized via Apple's Virtualization Framework, so basic 2D acceleration but no GPU passthrough. Fine for desktop use, web browsing, coding, productivity apps. Wouldn't recommend it for anything GPU-intensive though.
Good news is there are hints of GPU passthrough coming (_VZPCIDeviceConfiguration symbol appeared in Tahoe's Virtualization framework), so that might land in a future macOS release. We're keeping an eye on it.
> We built a VNC + OCR system that clicks through macOS Setup Assistant automatically.
You can automate at least some of this with `defaults write` commands or copying files to the right places. If you look at what some existing MDM platforms do you should be able to do this a lot more efficiently.
MDM platforms can skip Setup Assistant, but they require the device to be pre-enrolled in Apple Business Manager before first boot - VMs can't be enrolled in ABM, so those hooks aren't available.
defaults write only works after you have shell access, which means Setup Assistant is already done.
There are tools that modify marker files like .AppleSetupDone via Recovery Mode, but that's mainly for bypassing MDM enrollment on physical Macs - you'd still need to create a valid user account with proper Directory Services entries, keychain, etc.
The VNC + OCR approach is less elegant but works reliably without needing to reverse-engineer macOS internals or rely on undocumented behaviors that might break between versions.
whinvik | a month ago
[OP] frabonacci | a month ago
- macOS GUI apps (Xcode, Numbers, Safari, etc.) - macOS desktop automation (screenshots, mouse/keyboard input, accessibility APIs) - macOS CI/CD (building iOS/macOS apps, running XCTest)
...you need an actual macOS VM, which is what Lume provides.
fishtacos | a month ago
The unattended setup is a large improvement, which also begs the question: Mac OS doesn't have an unattended.xml alternative for its installer?
happyopossum | a month ago
easton | a month ago
I thought this was a silly way to do it too, but upon reflection I don’t know if you can zero touch setup a Mac without registering a device in DEP.
[OP] frabonacci | a month ago
You're both right - Apple's official zero-touch setup requires MDM + DEP, which needs Apple Business Manager (and yes, a DUNS number).
But for VMs specifically, DEP doesn't work anyway - VMs don't have real serial numbers that can be enrolled in Device Enrollment Program.
VNC-based setup automation is the only practical option - it's what the ecosystem has converged on for macOS VMs. Lume connects to the VM's VNC server and programmatically tabs, clicks, types through Setup Assistant.
arianvanp | a month ago
[OP] frabonacci | a month ago
A closer comparison here is Lumier, which provides a "Docker-like" interface to spin up VMs with a noVNC server: https://cua.ai/docs/lume/guide/advanced/lumier/docker
The key difference: dockur/macos uses QEMU+KVM, which only works on Linux hosts. It can't run on macOS hardware since Apple doesn't expose KVM. See: https://github.com/dockur/macos/issues/256
cmckn | a month ago
samtheprogram | a month ago
LoganDark | a month ago
[OP] frabonacci | a month ago
cmckn | a month ago
illithid0 | a month ago
cmckn | a month ago
CharlesW | a month ago
Apple also provides instructions for downloading many older macOS versions via your terminal: https://support.apple.com/en-us/102662#terminal
[OP] frabonacci | a month ago
ahmadyan | a month ago
Is there a limit on number of instances you can have per physical mac? i recall there was a hard limit of 2 because of EULA, unless Apple has changed it. (Cupertino really likes to sell you their Macs)
[OP] frabonacci | a month ago
There's a kernel-level check in the Hypervisor framework that enforces the 2 VM limit, and bypassing it violates Apple's EULA.
Nice technical deep-dive on the how here: https://khronokernel.com/macos/2023/08/08/AS-VM.html
eptcyka | a month ago
[OP] frabonacci | a month ago
fkorotkov | a month ago
abrookewood | a month ago
[OP] frabonacci | a month ago
So we just click through like a human would via VNC. Version-specific but works with their security model rather than against it.
fartfeatures | a month ago
[OP] frabonacci | a month ago
We've also built a broader ecosystem on top - the Cua computer and agent framework for building computer-use agents: https://cua.ai/docs
We went through the comparison with Tart, Lima etc here: https://github.com/trycua/cua/issues/10
fartfeatures | a month ago
Not seeing any reference to Tart at that link. Tart also has registry support for VM images it treats them very much like Docker images, is that what you are doing too?
Is it worth putting a comparison up somewhere other than a Github thread? Seems to be a frequently asked question at this point.
Also worth drawing attention to Tart being source available not open source.
[OP] frabonacci | a month ago
We just put one together (with some help from Claude Code, naturally): https://cua.ai/docs/lume/guide/getting-started/comparison
fartfeatures | a month ago
[OP] frabonacci | a month ago
Fixed the registry description—you're right, GHCR is an OCI registry. Both tools use OCI-compatible registries, we just default to GHCR/GCS.
Added licensing to the "when to choose" sections.
fartfeatures | a month ago
torarnv | a month ago
This feels disingenuous. Tart has unattended setup support as well, and it's based on the same VNC + OCR technique as Lume. In fact Tart had it first, and your approach seems to be heavily inspired by it. In addition the boot command instructions you're using came from https://github.com/cirruslabs/macos-image-templates/
The only material difference is whether it's built-in or integrated via Packer.
JSR_FDED | a month ago
Slight tangent - do the VMs have decent graphics performance? I live in fear of one day accidentally pressing the Update button and being forced into the GUI mess that is Tahoe. Knowing I could just use a VM with Sequioa as my primary desktop would dramatically lower my anxiety.
[OP] frabonacci | a month ago
Good news is there are hints of GPU passthrough coming (_VZPCIDeviceConfiguration symbol appeared in Tahoe's Virtualization framework), so that might land in a future macOS release. We're keeping an eye on it.
JimDabell | a month ago
You can automate at least some of this with `defaults write` commands or copying files to the right places. If you look at what some existing MDM platforms do you should be able to do this a lot more efficiently.
[OP] frabonacci | a month ago
defaults write only works after you have shell access, which means Setup Assistant is already done.
There are tools that modify marker files like .AppleSetupDone via Recovery Mode, but that's mainly for bypassing MDM enrollment on physical Macs - you'd still need to create a valid user account with proper Directory Services entries, keychain, etc.
The VNC + OCR approach is less elegant but works reliably without needing to reverse-engineer macOS internals or rely on undocumented behaviors that might break between versions.
saagarjha | a month ago
pjmlp | a month ago