I Put Omarchy on an M1 MacBook Pro

Status as of November 6, 2026: Omarchy 4.5 is the stable release, and it installs natively on M1, M2, M3, and Neo MacBooks (how). It merges Omarchy Mac into Omarchy, leaving only the Mac boot setup separate. There’s no upgrade path for an existing omarchy-mac install, so I reinstalled both my Macs, the M2 Pro and this M1, on the dev build with the new Mac installer, and both went smoothly (details). Both run 4.5 now. I’m keeping it: seven weeks and three machines in, it replaced macOS and Windows for my day-to-day work. The field report below is from the first week.

TL;DR: I’m a few days into running Omarchy (a Hyprland-based, opinionated Linux setup) on an M1 MacBook Pro, dual-booting macOS. There’s a purpose-built path for this: omarchy-mac puts Omarchy on Apple Silicon via Asahi Alarm in about one command. Installing it is the easy part, and it’s documented well. What isn’t documented is the layer underneath: where the install still breaks, and what daily life costs once macOS isn’t there anymore. The surprise: thirteen coding agents come pre-wired, the OS hands segfaults to whichever one you’ve set as default, and configuring the machine by asking an agent is the designed path rather than a workaround. I don’t know yet if I’m keeping this. Field report, not a verdict.

Update, September 23, 2026: Omarchy on Apple Silicon is now an official project, Omarchy M. What that changes is below the install section.

Update, October 20, 2026: The Omarchy 4.5 release candidate merges Omarchy Mac into Omarchy. What that means for an omarchy-mac install is right after the Omarchy M update.

Update, October 31, 2026: I reinstalled both my Macs onto the merged Omarchy. How that went is in the same section.

Update, November 6, 2026: Omarchy 4.5 is final, with a native Mac installer and a Homebrew install. Omarchy on a Mac today has the current path.

Omarchy on a Mac today

As of November 6, 2026, this is how you get Omarchy onto an Apple Silicon Mac. Omarchy 4.5 went stable on November 4, and its release notes say it installs natively on M1, M2, M3, and Neo MacBooks. Start in macOS with the Omarchy Mac Installer from its releases page and follow its steps. New installer builds come out every few days, so take the newest one. If you prefer Homebrew, the notes give one line: brew install omacom/mac/omarchy. M4, M5, and M6 support is being worked on, per the same notes.

When I reinstalled in late October, the installer’s rc channel had nothing in it yet, so a moderator on the Omarchy Discord pointed me to the dev build, Edge in the installer’s Release channel menu. Both Macs still run Edge, which is on 4.5 now, and both have been fine. The 4.5 notes add the stable and RC channels on Apple Silicon Macs, so a new install doesn’t need Edge. My x86 desktop ran the 4.5 release candidates.

If you installed through the old omarchy-mac project, there’s no upgrade path. Back up the Linux side and reinstall. I did that on my M2 Pro and on this M1, and both went smoothly. The full story is in the 4.5 update below. If you’re weighing it for a company laptop, I wrote up what it means for SOC 2.

Why this exists

macOS is still on the disk right now, dual-booting. A few days ago I put Omarchy on this machine using omarchy-mac, which pairs Asahi Alarm with Omarchy and does most of the work in a single command.

The install is the well-trodden part. omarchy-mac has been around since mid-2025, it’s actively maintained, and the README walks you through it properly. What I couldn’t find much of was the next layer down: what still breaks on the way through, whether a working dev setup actually survives the move, and what you give up day to day once macOS isn’t underneath anymore. That’s the gap this post is trying to fill, and it’s why I’m publishing now instead of waiting three months to have a settled opinion.

This post is not a recommendation, and it’s not a “why I switched” essay, because I haven’t switched. macOS is still on the disk. It’s a status report from someone a few days into an experiment who doesn’t know how it ends.

The install path

Two steps. First the Asahi Alarm bootstrap, run from the macOS terminal, which partitions the disk and puts Arch Linux ARM on the machine alongside macOS. Then, booted into that fresh Arch, the omarchy-mac setup command, which installs Omarchy itself.

Asahi is the project that ports Linux to Apple Silicon in the first place; Asahi Alarm is its Arch Linux ARM flavor. omarchy-mac is the layer that takes that base and makes it an Omarchy machine. None of this is exotic territory anymore.

It still broke.

Update: Omarchy M makes Apple Silicon official

Added September 23, 2026. Four days after I published this, on September 11, DHH announced Omarchy M, an official team for Macs with Apple Silicon. The path above stops being a side project. The announcement credits Naeem Malik, who “has maintained Omarchy Mac for a year, getting Omarchy onto M1 and M2 machines long before any of this was official,” and states the goal plainly: “Let’s finish what Asahi started.”

The announcement describes two ways in. The native installer is a macOS app that fetches the signed Omarchy release, partitions the disk, and boots Omarchy next to macOS, with no USB stick. Try Omarchy runs the real desktop as a hardware-accelerated app on the Mac, with camera, audio, clipboard, and a shared folder passed through, so you can look before you partition anything.

The first release targets M1 and M2, including the Pro and Max variants: full GPU support, external monitors over USB-C, Touch ID, MLX, and disk encryption. Newer chips are being worked on in parallel.

What it changes for this post: the two-step install above is now the pre-official path. I haven’t run the new installer or Try Omarchy, so I can’t tell you whether the aquamarine break below still happens on it. External monitors are on that first-release list, and they’re one of the things I said further down I hadn’t tested. The 30-day follow-up will say whether Omarchy M changes my answer. DHH also gave Omarchy a progress report on stage at Rails World on September 24, install times included; my notes on that keynote cover it.

Update: Omarchy 4.5 merges Omarchy Mac into Omarchy

Added October 20, 2026. The first release candidate of Omarchy 4.5 shipped today, and one of its headline items is about this post. From the release notes: “Omarchy Mac used to be a separate fork. Its shared hardware and desktop support now lives in Omarchy itself, so Apple Silicon Macs run the same Omarchy as every other machine, with only their boot setup left in the Omarchy Mac packages.”

The release also ships an aarch64 ISO. The hardware the notes name for it is NVIDIA N1x laptops (the ASUS ProArt P14 and Dell XPS 16) and Snapdragon X laptops (the Lenovo Yoga Slim 7x and ThinkPad T14s). Macs aren’t on that list, and the notes don’t say whether the ISO boots one. ARM machines also get smaller fixes: no reboot prompt after every update, Dropbox on machines with 4K pages, and Spotify as a web app.

What it changes for this post: I installed through omarchy-mac before the merge, and that install follows its own release line. The omarchy-mac releases page still tops out at 4.0.3rc4, from September 17, which is what my second Mac, an M2 Pro, ran until I reinstalled it. The 4.5 notes say to upgrade an existing machine with Update, then Channel, then RC. They don’t say whether an omarchy-mac install picks up that channel, or when it moves over to the main one.

Added October 30, 2026. The second release candidate, 4.5.0-rc2, shipped October 27. There is no date yet for the final 4.5 release, and the omarchy-mac releases page still tops out at 4.0.3rc4.

Added October 31, 2026: I’ve now done it on the M2 Pro, and the answer is that it doesn’t move over. There’s no upgrade path from an older omarchy-mac install yet. Enough changed in how the machine is put together underneath that the Omarchy team, asked on the Omarchy Discord, recommended a fresh install over trying to convert the old one. So I reinstalled. Getting the merged Omarchy on a Mac also meant the dev build, because the 4.5 RC hasn’t reached Macs yet. A moderator on the Discord pointed me there.

The new route starts in macOS with the Omarchy Mac Installer, version 2.3.9, the one I used. New builds land every few days (2.3.11 was out by October 30), so if that link doesn’t work, get the newest from the installer’s releases page. You download the disk image, run the installer, and follow its reinstall steps. It was smooth. The aquamarine failure from my first install, below, didn’t come back.

What’s on the machine now matches the 4.5 notes. Omarchy itself is the main project’s dev build, omarchy-dev, built from the tip of its quattro branch. My x86 desktop runs the 4.5 RC of the same project. The Mac part has shrunk to two packages from omarchy-mac-pkgs: omarchy-mac for Apple Silicon configuration and support services, and omarchy-mac-boot for boot, encryption, and first-boot setup. I’ve since reinstalled the M1 the same way, and it went just as smoothly. If you’re on an older omarchy-mac install too, plan on a reinstall, and back up anything on the Linux side before you start.

Added November 6, 2026: Omarchy 4.5 is final. DHH announced it on November 4 in the release notes, and v4.5.0 is the latest release on GitHub. The notes say it installs natively on M1, M2, M3, and Neo MacBooks, through the Mac installer or one Homebrew line, and that M4, M5, and M6 are being worked on. They also add the stable and RC channels on Apple Silicon Macs. My two Macs stayed on the Edge channel through the release and run 4.5 now. Both have been fine so far.

Where it broke: aquamarine

Omarchy’s installer failed partway through, trying to install aquamarine, the rendering backend library that Hyprland depends on (maintained by the Hyprland team, source at hyprwm/aquamarine). The version the installer tried to pull was too new, and it wouldn’t install. I didn’t save the error.

The fix was to downgrade to an older aquamarine build out of the local pacman cache rather than take whatever the installer wanted to pull fresh. That got the install moving again. It wasn’t an architecture problem, since omarchy-mac is built for M1/M2 specifically. This is the ordinary rolling-release failure mode: a dependency moves faster than the thing consuming it, and you land on the wrong side of a version for a few days. Arch does this on x86 too, and it comes with having current packages.

What’s actually good

Once it was up, the parts that are working are working well:

Hyprland’s tiling and the keyboard-driven flow. Window placement, workspace switching, everything stays on the keyboard, and that’s the thing I notice most hour to hour. Most of the bindings survive the MacBook keyboard unchanged; the ones that don’t get their own page.

Speed. This is the same M1 hardware I was running macOS on, and it feels fast. I haven’t benchmarked it; that’s how it feels day to day on identical silicon.

Opinionated defaults. Omarchy makes a lot of choices for you (theming, keybindings, the tool selection) and I haven’t had to configure much of anything. Someone already decided, and mostly I agree with the decisions.

The agent stack isn’t ported. It’s built in.

I’d budgeted a day for getting my agent setup working again. I didn’t need it, and the reason turned out to be the most interesting thing I’ve found so far.

Omarchy’s own manual opens its AI chapter with this: “Omarchy treats AI coding agents as first-class citizens, but it doesn’t pick a favorite for you.” That is not marketing copy bolted onto a Linux distribution. It describes how the system is wired.

Thirteen agent CLIs come pre-wired as lazy-loaded launchers: claude, codex, opencode, grok, copilot, crush, pi, omp, agy, ori, hermes, muse, cursor-agent. They’re mise-managed stubs in ~/.local/bin/, so nothing actually downloads until the first time you run one. You pick a default with omarchy default agent <name>, and a fresh install prompts you to choose. Super + Shift + Ctrl + A opens it in a dedicated terminal. omarchy agent prompt "Review this project" launches it straight into a task, unattended, in its don’t-stop-to-ask mode.

My Elixir/Erlang toolchain came across without special handling too, but that part I expected. Toolchains are portable. The rest of it is a set of assumptions about how you work.

Two features make the assumption concrete. The top bar grows an agents panel the first time it sees AI coding usage on the machine: your plan, how much of the five-hour and weekly limits you’ve burned, tokens by day and by model. The OS status bar, next to the clock, tracks coding agent usage.

The second is better. Omarchy watches systemd-coredump, and when something segfaults you get a “Process crashed” notification. Click it and the crash is handed to your default agent along with a diagnose-crash skill that walks it through reading the core dump and deciding whether the thing is worth reporting upstream. The operating system’s answer to a segfault is to hand it to your coding agent.

There’s also a skill for configuring the machine itself (Hyprland, the bar, themes), symlinked into ~/.claude/skills, ~/.codex/skills, ~/.pi/agent/skills and the generic ~/.agents/skills, so most harnesses find it without being told. In practice this has been the fastest way to fix things on this machine, including things unrelated to writing code. I made the longer case, with six breakages across two machines, in Linux Setup Was a Hazing Ritual. Agents Changed It. Worth repeating the project’s own warning though: it labels that skill experimental, suggests running plan mode first, and points at omarchy reinstall configs for when the agent makes a mess. That matches my experience: it’s very good and you should still watch it.

Most of what I do is a terminal, a browser, and an agent loop. I assumed that stack would be indifferent to the OS underneath it. On this one it isn’t indifferent. The desktop is designed around agentic work, which is a different thing from an OS that stays out of your way.

Has the Apple Silicon hardware actually held up?

So far, yes, in the narrow sense that nothing has broken, but I want to be precise about what that does and doesn’t mean. I haven’t hit any hardware gaps in the time I’ve been on this. I’m not claiming external display, sleep, or the webcam work, because I haven’t specifically tested or stressed those. I’m also not claiming any of them are broken. Nothing has bitten yet, and it’s only been a few days.

That distinction matters more than it sounds like it should. A few days of normal terminal-and-browser use doesn’t exercise the parts of a laptop that tend to be the hard problems on a reverse-engineered hardware port: sleep/wake cycling, external display timing, camera and audio pipelines. Asahi’s own project documents an ongoing, per-chip hardware feature support matrix for exactly this reason; I haven’t gone looking for where my specific gaps are yet, because I haven’t needed to. Take my “nothing’s broken” as “no news,” not as a clean bill of health.

The container caveat

This is the sharpest technical finding so far, and it’s worth real space because it’s the one that actually shapes what I’d tell someone else considering this.

Container images build fine locally on this arm64 machine. They don’t work on GCP, because of the architecture mismatch: arm64 built locally, x86_64 expected on the other end.

buildx plus QEMU does get you cross-arch builds that work. But those cross-arch builds run 3-5x slower than the same builds on macOS, and those builds were already fairly slow to begin with. Getting QEMU installed and working in the first place was itself a chore, and not as straightforward as you’d hope.

If your workflow involves building containers locally that need to run on GCP’s standard x86_64 infrastructure, I don’t think this current setup serves you well. You’d be better off on a Dell XPS or some other native bare-metal x86 install where the build target matches the build machine and you’re not paying a QEMU emulation tax on every image. Worth noting that “just buy another machine” is a more expensive answer than it was a year ago.

What the walled garden actually costs

It’s hard to leave the Mac walled garden. Omarchy is pulling me toward leaving it, but that pull has a cost: there’s real, daily friction from missing creature comforts I didn’t think about until they were gone.

iMessage has no usable path on Linux. iCloud Drive, Photos, and Keychain sync don’t follow you off macOS. They just stop. I use both Proton Mail and Proton Drive, and neither has an Arch Linux install, which forces me back onto their web clients, which isn’t the ideal experience for either. Backblaze is the same story: I haven’t found a Linux equivalent that fits how I was using it on macOS.

None of this is a dealbreaker on its own. It’s a daily tax: small friction, repeated every day, that adds up in a way a single dramatic failure wouldn’t. A crashed install is a bad afternoon and then it’s over. A missing sync feature is a bad moment every single day, indefinitely, and those compound differently than a one-time failure does.

Update, October 24, 2026: Proton Mail turned out fine as a web app, and backups on Omarchy moved from Backblaze’s app to Restic plus B2, Backblaze’s storage service. iMessage and a native Proton Drive client are still missing. The seven-week review has the details.

Where it stands

I’m still dual-booting. macOS is still on the disk, and I’m not deciding anything yet. The tiling, the speed, the opinionated defaults, and the fact that my actual dev and agent workflow just works are real points in Omarchy’s favor. The container-to-GCP story and the daily walled-garden tax are real points against it, at least for how I currently work.

What would actually decide this for me: whether the container workflow gets less painful, and whether the macOS creature comforts I’m missing stop mattering as much as they do right now. I don’t have a timeline on either of those, and I’m not going to pretend I do. For now, this is where it stands: an open experiment, not a verdict.

Update: I’ve since made the call. Seven weeks and three machines in, I’m keeping Omarchy, and the review covers what happened to the container workflow and the creature comforts.

Questions people search for

Does Omarchy run on an M1 MacBook?

Yes. Since Omarchy 4.5 (November 4, 2026), it installs natively on M1, M2, M3, and Neo MacBooks through the Omarchy Mac Installer. I’m running it on an M1 MacBook Pro, dual-booted with macOS. My first install, through the older omarchy-mac project, broke once on the aquamarine package, and pinning an older build fixed it.

What is Omarchy M?

Omarchy M is the official Omarchy team for Apple Silicon Macs, announced September 11, 2026. It builds on the omarchy-mac project, and its first release targets M1 and M2, including Pro and Max, with a native installer, full GPU support, external monitors over USB-C, Touch ID, MLX, and disk encryption.

Do you need Arch Linux installed first?

No. The Omarchy Mac Installer runs in macOS and puts Omarchy next to it, so you start from macOS, not from an existing Arch install. Keep macOS on the disk; dual-booting is the sane default while you decide.

Is Omarchy on Apple Silicon worth it for coding agents?

For the agent workflow, yes: thirteen agent CLIs are pre-wired as lazy-loaded launchers, usage shows in the top bar, and crashes are handed to your default agent. The cost is elsewhere. arm64 container images don’t run on GCP without buildx and QEMU at 3-5x the build time, and iMessage, iCloud, and Proton Drive have no Linux path.

Do sleep, the external display, and the webcam work?

I haven’t tested them and I’m not claiming either way. Asahi publishes a per-chip feature-support matrix; the 30-day follow-up will report only what diverged from it in daily use.

Can you dual-boot macOS and Omarchy?

Yes, and it’s how I run both Macs. The installer puts Omarchy next to macOS. To switch, I hold the power button at startup and pick macOS or Omarchy in Apple’s startup options. Keep macOS on the disk while you decide.

Do iCloud, iMessage, and Touch ID work on Omarchy?

Touch ID does. On my M2 Pro since the reinstall, it works for sudo, system password prompts, and the lock screen. iMessage has no usable path on Linux, and iCloud Drive, Photos, and Keychain don’t sync off macOS. What that costs day to day is further down.

Which Omarchy version runs on a Mac right now?

Omarchy 4.5, the stable release from November 4, 2026. It supports M1, M2, M3, and Neo MacBooks, with M4 to M6 in progress. Both my Macs run 4.5 on the Edge channel, which I installed before the RC reached Macs. Omarchy on a Mac today has the details.

If you’re weighing a build-target decision like this one, where the machine, the toolchain, and the deploy target all have to agree, that’s a conversation I have with clients regularly. Reach out if you want to think it through together.