Omarchy requirements: architecture, hardware and a practical preflight

There are three different questions behind “Can my computer run Omarchy?”: can it boot the chosen installer, can its devices work with the Linux desktop, and is it comfortable for your workload? A CPU/RAM table alone cannot answer all three.

Separate documented requirements from estimates

The reviewed getting-started guide does not publish a complete numeric minimum/recommended specification. We therefore do not label an invented RAM or storage number as an official minimum. A small Arch installation’s minimum is not a guarantee for Omarchy’s application set, graphical compositor or development workloads.

Area	Establish before installation	Why it matters
Architecture	Match the official image to the CPU; the reviewed standard ISO path is x86-64	An ARM CPU cannot simply boot an Intel image
Firmware	UEFI boot and the policy needed for the selected installation path	Reaches the installer before Linux drivers matter
Target storage	Identify the disk and whether using the whole disk or unallocated space	Prevents replacing the wrong system
Graphics	Exact GPU model, integrated/discrete arrangement and monitor connection	Hyprland requires a functioning graphics stack
Network	Ethernet or a known-working Wi-Fi adapter; connection credentials	Downloads and first-run troubleshooting need connectivity
Early keyboard input	Wired keyboard or a keyboard using a 2.4 GHz USB receiver	Bluetooth may be unavailable at encrypted-disk unlock
Recovery	Independently usable file backup and a way to boot another system	Installer media is not a backup

The keyboard limitation and installation disk options come from the official guide. The table’s separation of stages is a planning aid, not an Omarchy hardware certification list.

Inventory the actual machine

“A gaming laptop” is less useful than a model, GPU and Wi-Fi chipset. In Windows, start with System Information (msinfo32) and Device Manager. On macOS, use About This Mac and System Information; Mac generations need a separate decision. On an existing Linux system, these read-only commands help:

uname -m
lscpu
lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINTS
lspci -nnk

x86_64 and aarch64 describe different architectures. lsblk distinguishes disks from partitions and shows mount points; it does not grant permission to erase anything. lspci -nnk identifies PCI devices and their current driver, but a working driver in another Linux distribution does not prove every Omarchy feature will work. USB hardware may need lsusb as well.

Write a short inventory: exact computer model; CPU architecture; all GPUs; Wi-Fi chip; disk model/capacity; display connections; input devices. Remove serial numbers or personal mount paths before publishing it.

Budget for the work, rather than only the boot

An idle desktop, a browser with many tabs and a development stack with containers have different needs. Plan RAM around concurrent applications and check the host’s available RAM if using a VM. Do not allocate all host memory to the guest.

Storage planning includes the system, applications, package cache, project files, container images and retained snapshots. A dynamically allocated virtual disk can advertise a large capacity while the host still runs out of physical space. A Btrfs snapshot initially shares blocks, but later writes and retained old data still consume storage. See snapshots before treating them as free backups.

If you choose your own resource budget, label it an experimental starting point for that workload and record the result. A recommendation without a measured workload should not be presented as a tested minimum.

Check the devices that decide daily usability

After installation on a spare disk or in an appropriate trial environment, test these before moving your only copy of important work:

1. Reach the desktop, open a terminal and reboot to the installed disk.
2. Connect the network, then reconnect after a reboot. A VM’s virtual Ethernet does not test the laptop’s physical Wi-Fi adapter.
3. Test internal/external displays, their intended scale and refresh rate, and reconnect an external display.
4. Test speakers, microphone, headphones and the intended Bluetooth devices separately.
5. On a laptop, test lid close, wake and brightness while a recovery method remains available.
6. Check keyboard layout and early disk-unlock input, separately from input methods inside the desktop.

This is your acceptance checklist, not a claim that the ISO exposes a full live desktop for every test before installation. A VM is useful for learning workflow; it cannot validate your physical GPU, battery or suspend behavior.

Handle the gaps explicitly

Situation	Better next step
ARM machine or M-series Mac	Read Mac support and VM architecture choices before writing an Intel ISO
Windows must remain available	Use dual-boot planning; back up recovery information before firmware changes
Unknown graphics or mixed-GPU behavior	Keep the GPU identifiers; separate installer black screen from later display problems
No working network during install	Arrange Ethernet or another verified connection; changing desktop theme cannot fix this stage
Unsure which disk is safe to overwrite	Resolve disk identity and backup first; do not use the installer as a guessing tool

Finish with a concrete plan: chosen release, compatible architecture, target disk, usable early keyboard, network path and recovery copy. Then continue to download and USB preparation. No article can turn an untested hardware combination into a support guarantee; it can make the unknowns visible before they become an emergency.