Omarchy is DHH's opinionated Arch Linux desktop: Hyprland, a themed set of tools, one install, and since version 4 ("Quattro", August 2026) one Quickshell process instead of the old Waybar, Walker, and Mako stack. People with a Mac keep asking the same question: can I run it in UTM?
The honest answer has three parts. The official ISO is x86_64 and will not boot natively on Apple silicon. Emulating x86_64 in UTM boots it and is too slow to use. Virtualizing an ARM build works, with software rendering and a list of things you have to fix by hand.
This guide gives you the decision first, then the working path, then everything I could not verify so you know where the edges are.
Last verified against Omarchy v4.0.1 release notes, the Omarchy manual, basecamp/omarchy discussions #7956 and #452, and three first-hand reports. Version-specific details drift — check the vendor docs before relying on an exact flag or limit.
Why "download the ISO into UTM" fails on a Mac with Apple silicon
The ISO is built for x86_64. UTM offers two engines: Virtualize, which runs guests of the Mac's own architecture (aarch64) through Apple's hypervisor at near-native speed, and Emulate, which runs other architectures through QEMU's software CPU.
The ISO only fits the second engine. A September 2025 report did exactly that, with virtio-gpu-pci, Retina mode on, 8GB of RAM and a 32 to 64GB disk. It booted. It was not usable for work. Hyprland is a compositor; a compositor on an emulated CPU with no GPU is the worst case for that engine.
So the ISO is out, and the question becomes: which aarch64 Linux can carry Omarchy, and what breaks when it does.
By the end you will have
- The Omarchy on Mac Decision Matrix: four paths, what each gives you, and which to pick for your reason.
- The working UTM path on Apple silicon, step by step, with every command taken from a documented build.
- The fix list for graphics, keyboard, clipboard, and display scaling inside UTM.
- A clear list of what is unverified as of this writing, so you can test it instead of trusting it.
Magnet: Omarchy on Mac Decision Matrix
| Path | What you get | Cost | Pick it when |
|---|---|---|---|
| UTM, Emulate, official x86_64 ISO | The real ISO, unchanged | Unusably slow; no GPU | You want to see the installer once, and nothing else |
| UTM, Virtualize, Arch Linux ARM + community Omarchy port | Near-native CPU, Hyprland with software rendering, single monitor | No blur/shadows, keyboard and clipboard fixes, some apps missing | You want a daily-usable VM and can live without GPU effects |
| Parallels Desktop (paid), ARM port | GPU passthrough, the closest to the real thing in a VM | Licence; still a community port; 3.x-era reports | You want it to look and feel like Omarchy and will pay for it |
| Asahi Linux bare metal + manual install | Native performance on the Mac's GPU | Replaces or dual-boots macOS; M1/M2 focus; unofficial | You are done with macOS on that machine |
Intel Macs are a separate case, covered below.
You should see: one row that matches your reason. If none does, the honest answer is a second machine; Omarchy's own manual says the ISO is the supported path, and that machine is x86_64.
The working UTM path on Apple silicon
This follows the build documented in basecamp/omarchy discussion #7956 (August 2026), which is the most complete first-hand report I found. It is one person's build, which is why every step below says what to expect rather than promising it.
1. Create the VM as Virtualize, not Emulate
In UTM, create a new virtual machine, choose Virtualize, then Linux. Attach an Arch Linux ARM (aarch64) root filesystem rather than an ISO; the documented build boots an ALARM environment and installs from there.
Set the display to virtio-gpu-pci and turn on Retina Mode. Give it several cores and at least 8GB; the reported Parallels builds used 4 cores and 16GB, and there is no reason to give UTM less.
2. Boot with UEFI and install the bootloader without NVRAM
UTM does not persist NVRAM entries between boots, so the reported build uses systemd-boot with the edk2-arm-vars.fd variables file and installs it with:
bootctl install --no-variablesThe same build uses btrfs with @ and @home subvolumes. Set a fixed boot resolution; changing it at runtime whitened the screen in that report.
3. Install Omarchy from an ARM port, not from master
The official installer is:
curl -fsSL https://omarchy.org/install | bashOn aarch64 it will not complete: the 4.x branch no longer refuses the architecture, but stable-mirror.omarchy.org publishes no aarch64 packages, so the installs 404. The documented UTM build used a community script for exactly this (ggalancs/omarchy-arm-utm, referenced in #7956), assembled against the Quattro layout. Other community ports exist: alexisraitano-myffu/omarchy-arm, omarchy-mac/omarchy-mac for Asahi, and jondkinney/armarchy for the 3.x generation.
Read the port's README before running it. These are third-party scripts that run as your user and install packages; treat them the way you would treat any curl-pipe-bash from someone you have not met.
4. Make Hyprland paint
Under virtio-gpu in UTM, OpenGL clients did not paint; only software (wl_shm) clients rendered. The fix in the reported build:
export LIBGL_ALWAYS_SOFTWARE=1Set it for the session, not just one shell. You lose blur and shadows. Everything else draws.
5. Give Hyprland a Super key
macOS intercepts Command before UTM sees it. The reported fix maps Option to Super with the XKB option:
altwin:swap_lalt_lwinPut it in the guest's keyboard configuration; the Omarchy manual's keyboard section is the place to look for where your version reads it.
6. Clipboard, scaling, and what is missing
Clipboard sharing on Wayland needed a small bridge in that build: vdagentd --disable-session-integration plus wl-copy and wl-paste, with "Share clipboard" enabled in UTM and the VM window open, since a headless VM has no SPICE client.
Omarchy assumes a high-density display by default. On a non-Retina external monitor you edit the scale in the Hyprland monitor config the manual describes.
Expect these gaps on ARM: 1Password, Obsidian, Typora, LocalSend, and Chrome are x86-only or proprietary and need opt-in scripts; herdr needed Zig 0.15 against ALARM's 0.16 at the time; the UTM build was single-monitor only.
Why a VM cannot give you the real Omarchy on an M-series Mac
Hyprland wants a GPU. UTM's Apple Virtualization backend does not expose one to an aarch64 Linux guest with hardware acceleration, and UTM's QEMU backend on Apple silicon has the same limit for practical purposes. That is the whole reason for LIBGL_ALWAYS_SOFTWARE=1 and for every visual effect you lose.
Parallels does pass a GPU through; the ARM-port reports on Parallels are the only ones that describe acceptable performance. VMware Fusion also passes a GPU but caps OpenGL at 2.1, and Hyprland needs 3.0 or newer, so it is not a path.
The only way to get the Mac's GPU under Hyprland is to run Linux on the metal, which is Asahi. DHH's answer to "does the ISO work on M1" was, in short, no; install Asahi's Arch-based image first, then do a manual install.
Intel Macs are ordinary x86_64 machines
On an Intel Mac the official ISO is native. The Omarchy repository ships Apple-specific hardware fixes for bare-metal installs on T2 models (install/hardware/apple/fix-t2.sh, fix-suspend-nvme.sh, fix-spi-keyboard.sh, fix-brcmfmac-supplicant.sh), which tells you the intended route is dual-boot or replacing macOS. Running the ISO inside UTM on an Intel Mac is plain x86_64 virtualization; none of the ARM caveats above apply, but I found no separate write-up of it and have not done it myself.
Failure modes
Emulating because the ISO was handy. It boots. You will close it within the hour.
Cloning master on aarch64 and expecting the packages to exist. The guard is gone on the 4.x branch; the mirror still has nothing for ARM. Use a port.
Changing the resolution at runtime. Reported to white the screen under virtio-gpu. Set it at boot.
Running headless and wondering where the clipboard went. SPICE clipboard needs the window open.
Treating a community port as the official product. It is someone's script over the Omarchy layout. When it breaks after an Omarchy release, the fix comes from the port's maintainer, not from omarchy.org.
When not to do this
Do not do it to evaluate Omarchy's feel. Software rendering removes the part people talk about. Borrow an x86_64 laptop or use the ISO in a VM on an Intel machine.
Do not do it on a Mac you need for work tomorrow with a bare-metal Asahi install. That path is a commitment, and M3 and later support is not where M1 and M2 are.
Do not do it if you are not willing to read a third-party install script. Every working ARM path runs one.
What I could not verify
- The exact
omarchy-command list in v4.0.1; only some names surfaced (omarchy-update,omawrite,omacalc,omacut). - Whether the 4.x installer refuses a VM or non-bare-metal hardware. I confirmed the architecture check was removed on the
quattrobranch; I did not read the current script in full. - Suspend and sleep behaviour inside UTM. No report mentioned it.
- The current UTM version and changelog from the UTM docs directly; the 4.7.x figure came from a search result, not the source.
If you have first-hand data on any of these, the field-note format on this site updates in place.
A VM is a place to learn a system, not a place to live in it
Omarchy is a bet on the hardware you own running one operating system well. A Mac running it in UTM is a demo of the layout, and that can be exactly what you need to decide whether the second machine is worth buying.
The same rule shows up one level down in the systems I build: an agent that runs in a sandbox is not evidence that it runs in production. The six-gate control model is how I keep those two things separate.
Your next action: pick your row in the Omarchy on Mac Decision Matrix and, if it is the UTM row, budget an evening for steps 4 to 6 before judging the result.
