DEV Community: Lucid Fabrics

How Dreo Fans Actually Pair Over Bluetooth

Lucid Fabrics — Fri, 31 Jul 2026 05:02:26 +0000

I spent two days implementing Dreo's Bluetooth pairing protocol from decompiled Android source. I wrote unit tests for it. I felt pretty good about it. Then I pointed it at an actual fan, and the fan ignored every single byte I sent.

The code wasn't buggy. It was just for a completely different product.

This was my first time reverse-engineering anything. I'd never decompiled an app, never hooked a running process, never looked at a BLE capture in my life. I mention that partly as a disclaimer and partly as encouragement, because the thing I was most scared of turned out to be the easy part, and the thing that actually cost me days was ordinary stubbornness about a wrong assumption.

So below is the protocol that really works: the service UUIDs, the message types, and the ordering rule that ate an entire evening before I worked out what was going on. As far as I can tell nobody had written this down anywhere. If you have a Dreo fan and you'd like to get it onto your WiFi without using their phone app, this should be everything you need.

Where it went wrong

The whole thing started because I wanted to turn a fan on from my keyboard. That was it, that was the entire ambition. So I started building a little macOS menu bar app for it, called Windbar, and assumed the hard part would be the UI.

The cloud side turned out to be straightforward. You log in over REST, you get a token, you open a WebSocket, and you send commands down it. Fine. The interesting part was setting up a brand new fan, because that happens over Bluetooth, directly between your phone and the fan, and nobody had documented any of it.

So I did the obvious thing and pulled the Android APK apart to read what it does.

It told me a very clear story. GATT service FFB4, WiFi password RSA-encrypted into a fixed byte layout, every field neatly accounted for. I implemented the whole thing, wrote tests around the byte layout, and went to bed happy.

The real fan advertised service FFFF and had no interest in anything I sent it.

Here's the annoying part: the FFB4 code was real. It just belongs to a different Bluetooth SDK that the same app also ships, for other Dreo product lines. Nothing in the decompiled source says "by the way, this path is dead for the fan sitting on your desk." Static analysis will happily hand you a complete, internally consistent, and totally wrong picture of the world, and your unit tests will nod along, because all they're really checking is that your code matches your assumption.

That's what got me. Not that I was wrong, but that everything available to me said I was right.

What actually worked

Eventually I stopped reading and started watching. I patched the Android app with a Frida gadget, hooked its Bluetooth calls, and paired a fan for real while listening in.

Ten minutes of that was worth more than the two days of reading.

There's no RSA anywhere. There's no FFB4. The protocol is CBOR messages going over one write characteristic and one notify characteristic, and the WiFi password crosses in cleartext. Bluetooth's own link encryption is the only thing protecting it, which is worth sitting with for a second if you've ever typed your home WiFi password into a fan.

Worth being precise about how bad that is, since "cleartext WiFi password" sounds worse than it is. To capture it you'd need to be within Bluetooth range during the handful of seconds that a fan is actually being paired, on a channel-hopping link you'd have to be sniffing already. It isn't remotely exploitable and it isn't sitting there waiting for you. It's still the kind of thing you'd rather see wrapped in application-level encryption, which is presumably what the unused RSA code in the other SDK was for.

The tools, for anyone else doing this for the first time

There are really only two jobs here, and it took me a while to understand they're different jobs.

Reading the app is static analysis. You take the APK, decompile it, and read what the code says it does. This is the part that looks like real reverse engineering in films, and it's genuinely useful for orientation: it's how I found the class names, the message type strings, and the general shape of things. It is also, as covered above, perfectly capable of lying to you with total confidence.

Watching the app is dynamic analysis, and it's what actually solves the problem. I used Frida, which lets you inject a bit of JavaScript into a running process and intercept function calls as they happen. The important detail for a beginner: you don't need a rooted phone. Frida ships a "gadget" you can repack into the APK itself, so the app carries the instrumentation with it and runs on an ordinary device.

(I'd fought with Bluetooth once before, from completely the other end, getting it working inside a Proxmox VM. Different problem, same feeling of the stack quietly lying to you.)

Once it's in, the hook itself is almost disappointingly small. Android only has so many ways to push bytes over BLE, so you wrap the write call and the notification callback, log the payloads as hex, and then go pair a fan normally with your own phone. The log that comes out the other side is the conversation, in order, exactly as the real app has it. Every answer in this post came from reading that log.

Two things nobody told me:

Capture the whole session from the very first byte. I initially hooked things partway through and got the messages but not the opening handshake, which is precisely the part I needed and precisely the part I later wasted an evening on.
Log timestamps. Some of these exchanges are the fan taking its time rather than the fan refusing you, and without timing you can't tell the difference between "rejected" and "still thinking".

For reference, all of this was captured against a Pilot Max tower fan. Other models speak the same protocol as far as I can tell, but I've only watched that one do it.

The protocol

This is the part I actually wanted to publish, since nobody else has.


Service	`0000ffff-0000-1000-8000-00805f9b34fb`
Write	`00009b01-0000-1000-8000-00805f9b34fb`
Notify	`00009b02-0000-1000-8000-00805f9b34fb`
Advertises as	`DREO` plus a suffix, like `DREOpf08s8E`

Every message has the same shape, {"t": <type>, "v": <version>, "d": <payload>}:

Type	Who	Meaning
`st`	app	Set the clock
`rd` / `ri`	both	Ask the fan who it is, and its answer
`pd`	app	Which account and which API host to phone home to
`rw` / `wl`	both	Ask for a WiFi scan, results streamed back in batches
`cw`	both	Here are the credentials, then progress reports
`cf`	fan	Final verdict, including its own internet self-check
`ee`	fan	Something went wrong

Try it in thirty seconds

If you own a Dreo fan, you can confirm half of this right now without writing anything. Plug the fan in, hold the Oscillation button for about five seconds until the WiFi light blinks, then open any BLE scanner (nRF Connect is fine). You'll see it advertising as DREO plus a suffix, offering service FFFF. That's the thing the decompiled source told me didn't exist.

And here's the message that actually carries your WiFi credentials, cw, with the field names as they really go over the wire:

a    auth type
b    0
c    channel
m    { ca: 0, cm: 0, da: 0 }
p    password, cleartext
s    ssid
t    { ca: 60000, cm: 60000, da: 30000 }
sc   1 if the fan should self-check its internet after joining
scc  { dm: [ "http://www.google.com", ... ] }   the URLs it probes

Two things about that block took me longer than they should have. The fan parses the map positionally rather than by key, so the field order above isn't cosmetic, it's part of the format. And the final cw write omits the v version field that every other message carries, which I only believed after diffing my bytes against the capture for the third time.

The ordering rule that cost me an evening

Knowing the messages isn't enough, and this is the bit I wish someone had told me. The order matters.

If you send st, then rw, then cw, the fan refuses to join the network. And I mean it refuses even when the cw bytes are byte-for-byte identical to a capture of a pairing that worked. I diffed them, more than once, convinced I'd miscounted something. They matched exactly. The fan still said no.

What it's waiting for is the same opening the real app uses:

st  ->  rd  ->  pd  ->  rw  ->  cw

Introduce yourself, mention which account you're acting on behalf of, and then ask it to join a network. Add those two messages and it works on the first try.

Looking back, that makes a kind of sense. A protocol isn't really a set of messages, it's a conversation with a state machine you can't see, and the state machine is almost never documented. Capturing one successful run gives you the messages. Capturing it in order is what gives you the protocol.

That's the whole thing, by the way. Everything above is what you need to pair a Dreo fan yourself, in whatever language you like. It's maybe 250 lines of CBOR encoding and a small state machine, and the encoder has one trap in it: map keys have to keep their insertion order, which Swift dictionaries don't do, and the fan will reject you if they come out shuffled. If you'd rather not write all that, my implementation is here and it's MIT.

Once the message ordering was right, the whole protocol collapsed into about four screens of wizard:

Everything in the tables above, hidden behind "The Light Is Blinking".

The bug I invented out of thin air

While I was stuck, I managed to convince myself the real problem was Bluetooth packet size.

The reasoning was lovely. Dreo's app calls requestMtu(512), and warns in its own source that large writes fail on peripherals that can't reassemble them. My message was 213 bytes. CoreBluetooth gives you no way to request an MTU at all. So: clearly a platform limitation, clearly a dead end, clearly not my fault.

Then I printed the number. macOS had already negotiated 515. My 213-byte message fit in a single write with room to spare, and had done all along.

The theory had been dead on arrival, and I'd have spent a day "fixing" it if I hadn't checked. Honestly, most of the hours I lost on this project went the same way: I believed something I could have verified in thirty seconds.

I did keep one piece of the dead theory. There's a flag that drops the scc internet-self-check block from the credentials message, taking it from 213 bytes down to about 78, and it's still in the code. It's off by default, because on the hardware I can actually test the full message is fine. But I only ever measured one Mac talking to one fan, and I'm not confident enough in that sample to delete the smaller path. Being wrong about the diagnosis doesn't mean the escape hatch was a bad idea, it just means it isn't the thing that was broken.

The device that hid all the others

One more, from the cloud side rather than the Bluetooth side, because it's the bug I'd most like to warn people about.

The nice thing about Dreo's API is that devices describe themselves. Each one returns a controlsConf blob saying "I have a Speed control that goes 1 to 12" and "here are my four modes", so the app renders whatever it's told rather than knowing anything about fans. Then I paired a newer model and it came back with this:

"controlsConf": { "template": "DR-HPF008S" }

No controls, just a pointer at a template that lives inside Dreo's own app binary. Fine, annoying, solvable.

What wasn't fine: that one device broke decoding for the entire list. The app showed no fans at all and confidently blamed a failed login, so I spent the first while debugging authentication that was working perfectly. One unfamiliar device had taken down every other device in the account.

Both the device list and the control sections now decode item by item and drop only what they can't parse. If you're deserialising a collection from someone else's API, that's the whole lesson: one weird element should cost you that element, not the collection.

What I'd tell myself at the start

Treat decompiled code as evidence, not as truth. It shows you what the binary is capable of, never what your particular device actually does. Confirm against real hardware before you build on top of it.
Instrument the real client first. Ten minutes of Frida on the official app replaced two days of reading, and it handed me the message ordering that static analysis could never have shown me.
Measure before you theorise. If you can check a hypothesis in under a minute, checking it is always cheaper than reasoning about it, no matter how good the reasoning feels.

None of those are clever insights. They're the sort of thing every person who does this for a living presumably learned years ago. But I hadn't, and each one cost me real hours, so if you're also doing this for the first time, maybe they'll cost you fewer.

The app, if you want it

All of this ships in Windbar, a small macOS menu bar app for Dreo fans. You click the icon and your fans are there. There's a global hotkey, and a windbar://toggle URL so Shortcuts or a Stream Deck can drive it. And it pairs a brand new fan onto WiFi with no phone involved, which is the part this whole post has been about.

One thing you can't see in that screenshot: none of those controls are hardcoded. Dreo's API hands back a controlsConf blob describing what each device can do, right down to "I have a Speed control that goes 1 to 12" and "here are my four modes and their names", so the app just renders whatever it's told. A tower fan and an air circulator both work without a line of model-specific code. That part was a genuinely pleasant surprise after the Bluetooth ordeal.

It's Swift 6 with strict concurrency, a hand-rolled CBOR encoder, and 59 tests, none of which touch the network.

Free, open source, MIT. If the tables above saved you a weekend, the repo is the place to say so:

github.com/lucid-fabrics/windbar

Two honest caveats before anyone downloads it. It's an independent project, not made by or affiliated with Dreo in any way, it just talks to their fans. And it needs a Dreo account with an actual password: if you signed up with "Continue with Google" or "Sign in with Apple" it won't work at all, because the login endpoint only accepts grant_type=email-password. There's nothing I can do about that from the outside, and I'd rather you knew now than after installing.

Two loose ends I'd love help with, if you're the sort of person who reads to the end of posts like this:

The ee error message comes back as four bytes, 03 02 00 01, and the official app's own parser expects a completely different shape, so it appears to never actually receive one. I never worked out what it means.
Everything here was captured against one fan, a Pilot Max tower. If you have a different Dreo model and it speaks this protocol, or refuses to, I'd genuinely like to hear which.

Either one, drop it in the comments or open an issue.

I Spent 150 Commits Fixing These 5 macOS-on-Proxmox Bugs

Lucid Fabrics — Fri, 31 Jul 2026 03:46:33 +0000

Back in February I published a post about osx-proxmox-next, a tool that builds a macOS VM on Proxmox with one command instead of an afternoon of OpenCore plist editing.

About 1,500 people read it. Some of them installed it. On hardware I don't own.

That's when the interesting bugs showed up. 150 commits later, here are five failures that don't appear in any macOS-on-Proxmox guide I've found, with the actual root cause for each.

1. The installer stalls at 100% CPU and nothing moves

Symptom: macOS installer reaches the copy phase. CPU pegged at 100%. Disk IO and network throughput both flat zero. It sits there forever.

Only on Xeon E5/E7 v2-v4 hosts.

My first fix was wrong. The stall looked like a network problem, so I assumed the vmxnet3 kext was failing to load during install and swapped those hosts to e1000-82545em. Shipped it.

Then issue #103 came back from someone with the actual hardware: vmxnet3 got network fine, and e1000-82545em did not attach at all. I had made it worse.

The real cause is two layers down. Those chips are genuine HEDT parts with dual-socket / multi-die topology, and -cpu host leaks that topology straight through to the guest. Pair it with a MacPro7,1 SMBIOS, which macOS treats as multi-socket capable, and XNU's scheduler livelocks under heavy multithreaded IO. The installer copy phase is exactly that workload.

The fix is to stop passing the host topology through:

_XEON_HEDT_PATTERN = re.compile(r"Xeon.*E[57][ -]*\d+ *v([234])", re.IGNORECASE)

def _xeon_hedt_cpu_model(model_name: str) -> str:
    match = _XEON_HEDT_PATTERN.search(model_name)
    if not match:
        return ""
    if match.group(1) == "2":
        return "Haswell-noTSX,model=158,stepping=3"
    return "Broadwell-noTSX,model=158"

Lesson I keep relearning: the symptom showed up at the network layer, the cause lived in CPU topology. Guessing from the symptom cost me a release.

2. The VM boots into Recovery forever

Symptom: Fresh install finishes. Every subsequent boot lands back in Recovery. Selecting macOS in the OpenCore picker works for that boot and never sticks.

Cause: AllowSetDefault is off in the stock OpenCore config. That's the setting behind Ctrl+Enter in the boot picker. With it off, you have no way to pin the macOS entry as default, and the on-disk Recovery volume keeps winning the boot race.

One key in the config patch:

Misc -> Security -> AllowSetDefault = True

Then in the picker: highlight your macOS volume, hit Ctrl+Enter. It sticks.

3. The boot order after install is backwards from what you'd guess

After macOS finishes installing, the boot order has to be:

ide0;virtio0

OpenCore (ide0) first, macOS disk (virtio0) second. I shipped a hint suggesting virtio0;ide0, which reads more natural and is wrong: it boots the macOS disk directly, skips OpenCore entirely, and the VM stalls on first boot with no error.

macOS on a hypervisor never boots without OpenCore in front of it. Every boot, not just install.

osx-next-cli post-install --vmid 100 --execute

4. "Memory Modules Misconfigured" on every single boot

Cosmetic, but it fires on every boot and it is maddening.

Every VM gets the MacPro7,1 SMBIOS, and the stock OpenCore image ships no RestrictEvents.kext. macOS looks at the emulated memory layout, decides a real Mac Pro would never be configured this way, and notifies you about it. Forever.

Search for this and you will be told to add revpatch=memtab as a boot-arg. That does nothing here. revpatch=memtab only affects MacBookAir SMBIOS models. On MacPro7,1 it is a no-op, which is why so many people report it "not working."

The actual fix is shipping the kext at all. RestrictEvents 1.1.6 goes into EFI/OC/Kexts, gets registered in config.plist, and its default revblock=auto blocks both MemorySlotNotification and ExpansionSlotNotification. No boot-arg needed.

5. Apple ID sign-in fails on Sequoia and Tahoe

On older macOS versions, a vmgenid and a static MAC were enough to sign into iMessage and FaceTime. On Sequoia 15 and Tahoe 26 they are not.

Apple's DeviceCheck now reads the hv_vmm_present sysctl. In a VM it returns 1, and sign-in is refused before it ever reaches your credentials.

The community fix is a string swap in the kernel's string table, applied by OpenCore at boot. Find the hibernatecount sysctl name, replace it with hv_vmm_present:

Find:    ...hibernatehidready\0 hibernatecount\0
Replace: ...hibernatehidready\0 hv_vmm_present\0

The lookup now resolves to the hibernate counter, which is 0 on a fresh boot. macOS reads 0, DeviceCheck sees a physical machine, sign-in works.

It's a kernel patch against a specific string layout, so treat it as something that can break on any macOS point release. It's behind an explicit --apple-services flag for that reason.

Bonus: cloning a macOS VM quietly breaks iCloud on both

Proxmox's full clone is a byte copy, which means the clone inherits the source VM's SMBIOS serial, UUID, MLB and ROM. Two machines, one Apple hardware identity. Apple notices, and you get sign-in failures on whichever one loses.

osx-next-cli clone full-clones and then immediately regenerates the SMBIOS quad plus vmgenid and the static MAC, so the clone is a distinct machine as far as Apple is concerned.

All of it became a doctor command

Every one of these is a config-level mistake that is invisible until macOS misbehaves in some unrelated-looking way. So they're now 12 checks you can run against any VM:

osx-next-cli doctor --vmid 100

Balloon, q35, cores as a power of 2, memory, CPU type, NIC model, agent, smbios1, boot order, and the presence of virtio0 / ide0 / ide2. It prints OK / WARN / FAIL with a fix hint per line, and it reads the VM config directly, so it works on VMs my tool never touched. If you built your macOS VM by hand from a guide, point it there.

Still open: GPU passthrough

The one thing I can't fix from here. Passing a real GPU into a macOS guest needs hardware I don't have to test against, and guessing at it is how you get bugs like #1 above. It's the top request and it's honestly blocked on a test rig.

Everything else above is shipped and on main:

curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh | bash

Repo: github.com/lucid-fabrics/osx-proxmox-next

Still a solo project. If you hit a bug on hardware I don't own, open an issue. That's how four of the five above got found.

Proxmox Bluetooth Passthrough: Why It Silently Fails (and the One-Line Fix)

Lucid Fabrics — Thu, 30 Jul 2026 14:02:39 +0000

I run a gaming VM on Proxmox with an AMD GPU passed through. Steam works. Games work. Everything works except Bluetooth.

My Xbox controller would blink forever trying to pair, and every fix I found online led to the same place: pass a USB Bluetooth device into the VM and watch it fail anyway.

The forum threads all read the same way. Someone finds a controller. Someone else says "just pass the USB device through." The original poster tries it, and the thread goes quiet. No follow-up. No "it worked."

Why passthrough fails

My board has an Intel BE200, a Wi-Fi 7 and Bluetooth 5.4 combo card found on many modern motherboards. Intel onboard Bluetooth in the BE200, AX200, AX210, and AX211 family depends on the host driver loading firmware at boot.

A passthrough handoff re-enumerates the USB device and clears that firmware. The guest must load it again. A full Debian, Ubuntu, or Arch guest may have the matching driver and firmware blobs, so passthrough can work there. Trimmed or immutable guests such as ChimeraOS, Bazzite, and Home Assistant OS often do not.

In my case the guest got stuck here:

Reading Intel version command failed (-110)

Again and again. I spent hours thinking the chip was defective. It wasn't. The handoff was the problem.

Try plain USB passthrough first

A regular USB Bluetooth dongle passed into a normal Linux distribution often works fine:

qm set <vmid> -usb0 host=<vendor:product>

If the guest reports a missing firmware blob, install it and reboot:

# Debian, with non-free-firmware enabled
sudo apt install firmware-iwlwifi

# Ubuntu
sudo apt install linux-firmware

# Fedora, ChimeraOS, or Bazzite
sudo rpm-ostree install linux-firmware

If that fixes it, keep the simpler setup. You do not need this project.

What worked: keep the chip on the host

Instead of handing the adapter to the VM, the Proxmox host keeps it initialized. btproxy, a small tool from the official BlueZ source tree, opens the adapter in raw HCI mode and streams it over TCP.

The VM runs btproxy in reverse. It creates a virtual Bluetooth controller through hci_vhci and feeds it the stream. BlueZ inside the guest sees a normal local adapter. The physical chip never resets, so there is no firmware handoff to fail.

I packaged the setup as proxmox-bluetooth.

On the Proxmox host:

curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/proxmox-bluetooth/main/install.sh | sudo bash

The installer prints the matching command to run inside the VM. Paste that line there. Both services start at boot and reconnect automatically.

My Xbox controller paired within a minute. It has stayed paired through host reboots, VM reboots, and a full AC power cycle.

Check before installing

Run this on the host:

curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/proxmox-bluetooth/main/install.sh | sudo bash -s -- --check

It lists each adapter and tells you whether it is healthy. If an Intel chip is stuck in its blank boot state, shut the machine down and switch off AC power for 15 seconds. A reboot is not enough because the radio can remain powered.

One security detail that matters

btproxy uses plain, unauthenticated TCP on port 9700. By default, the first machine on your LAN that connects gets the Bluetooth chip. Restrict it to the VM once you know its address:

./install.sh --allow 192.168.1.50

That installs an nftables rule without interfering with pve-firewall. Treat the bridge as a trusted-LAN tool. Do not expose it to the internet.

The project is MIT licensed. The bundled bridge is unmodified BlueZ code under its upstream licenses, and CI rebuilds it from source on every commit to verify the binary byte for byte.

Source and installation guide: github.com/lucid-fabrics/proxmox-bluetooth

I Got Tired of Manually Configuring macOS VMs — So I Built a One-Click Solution

Lucid Fabrics — Thu, 12 Feb 2026 01:15:07 +0000

Every Proxmox user knows that moment. You want to spin up a macOS VM for testing, iOS development, or just playing around. And then the nightmare begins.

You Google "macOS Proxmox guide". You find a tutorial from 2021. You copy-paste commands, tweak OpenCore configs, mess up one flag, and suddenly you are staring at a UEFI shell wondering what went wrong. Again.

I lived this cycle for years. Every. Single. Time.

The Pain Was Real

I would spend hours:

Finding a current guide (most are outdated)
Chaining together qm commands
Manually generating SMBIOS serials
Editing OpenCore config.plist files
Praying it boots

And when it finally worked? I would not save my config. So next time, I would do it all over again.

I got fed up.

Enter osx-proxmox-next

I built a tool that handles the entire VM creation process in a guided wizard. No manual commands. No config editing. Just answer a few questions and boom - your macOS VM is ready.

What It Does

6-step TUI wizard - Preflight → OS → Storage → Config → Dry Run → Install
Auto-detects your hardware - CPU vendor, cores, RAM, storage pools
Both Intel and AMD supported - zero config needed
Auto-downloads everything - OpenCore ISOs and macOS recovery images
Generates SMBIOS identity - unique serial, UUID, model for Apple Services
Mandatory dry-run - see every command before it runs

Quick Look

macOS	Status
Ventura 13	Stable
Sonoma 14	Stable
Sequoia 15	Stable
Tahoe 26	Stable

What's New (v0.29.3)

Since this post first went up, a lot has shipped:

Post-install boot fix - one command fixes the boot order after macOS finishes installing. No more UEFI shell surprises.
Doctor - osx-next-cli doctor --vmid <id> gives any VM a health check and config comparison table.
Clone - duplicate a macOS VM with a fresh SMBIOS identity in one command.
VM edit wizard - change CPU, RAM, or storage through the same guided interface.
Apple ID fix - iCloud and iMessage work without manual kext hunting.
No more memory warning - OpenCore now ships RestrictEvents, silencing the MacPro7,1 memory misconfiguration warning.
HEDT Xeon fix - Xeon E5/E7 v2-v4 hosts no longer livelock during the installer copy phase. A safe emulated CPU model is picked automatically.
Older hardware - pre-Skylake Intel gets Penryn mode and an e1000 NIC automatically.
Docs site - full docs, FAQ, and troubleshooting at lucid-fabrics.github.io/osx-proxmox-next

Why This Matters

macOS on Proxmox is niche. Most guides are buried in forums or outdated. Existing scripts are rough - no validation, no dry run, no error handling.

I wanted something that just works. Something I could trust. Something that shows me exactly what it will do before it does it.

That is osx-proxmox-next.

Install

bash -c "$(curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh)"

CLI Mode

Prefer command line? Got you covered:

# Download assets
osx-next-cli download --macos sonoma

# Preview (dry run)
osx-next-cli apply --vmid 910 --macos sequoia --cores 8 --memory 16384 --disk 128

# Execute
osx-next-cli apply --execute --vmid 910 --macos sequoia --cores 8 --memory 16384 --disk 128

This Is Solo Work

I maintain this project in my free time. No company. No team. Just me, trying to make macOS VMs on Proxmox less painful for anyone else who has to go through it.

If this saves you hours of frustration - a star on the repo or a coffee would mean a lot.

☕ Ko-fi | Buy Me a Coffee | ⭐ Star on GitHub

Get Started

GitHub: lucid-fabrics/osx-proxmox-next

Try it. Your future self will thank you.