How to Install Omarchy on Proxmox or Bare Metal (Arch + Hyprland)

Omarchy now installs in under a minute. The new installer unpacks a prebuilt root image instead of pulling about 940 packages one at a time, and on our KVM test guest it went from the disk confirmation to “Installed Omarchy in 0m 57s”. So when you install Omarchy in a VM, the slow part is no longer the package download. It is getting the firmware, the GPU and the disk settings right before you boot the ISO.

Original content from computingforgeeks.com - post 163022

We cover a Proxmox VE virtual machine and a bare metal install from USB, plus the hands-off cidata install for throwaway desktops. You will verify the ISO, walk through every installer screen, unlock LUKS and check which Hyprland build you got. Every step below was run on Omarchy 4.5 in October 2026, once in a KVM guest and once unattended on a Proxmox VE node.

What Omarchy ships now

Omarchy is still Arch Linux underneath with a fixed, opinionated Hyprland desktop on top, and it still wipes a whole disk and encrypts it by default. What moved since the 3.x releases this page used to cover is almost everything you touch: the terminal, the menus, the shell and even the format of the Hyprland config. These are the packages and settings we read off the installed system with pacman -Q, hyprctl and lsblk:

Component	What the install put on disk
Base	Arch Linux, rolling, plus the Omarchy package repository
Window manager	Hyprland 0.56.2 (Omarchy’s own build)
Kernel	linux-omarchy 7.2.8
Hyprland config	Lua files in ~/.config/hypr (hyprland.lua, bindings.lua, input.lua, monitors.lua)
Terminal	foot
Shell	bash with the Starship prompt
Bar and menus	Quickshell
Browser	Chromium
Filesystem	btrfs (@, @home, @log, @pkg) on LUKS2
Bootloader	Limine, 1 second menu timeout
Packages after install	892

Two rows trip up anyone coming from an older install. Alacritty is gone from the base package list, and foot is the terminal that opens on Super + Return. The Hyprland config is no longer a set of .conf files either, because Omarchy loads its defaults from Lua and leaves your overrides in Lua files under ~/.config/hypr. Hyprland 0.57 was released upstream on 28 October 2026, with blur variants, window wobble and a release note that reads “config: remove legacy config support”. Omarchy pins and builds its own Hyprland package, so a fresh install still lands on the 0.56 series until Omarchy ships a newer build through omarchy update.

Check the hardware or VM requirements

The Omarchy manual does not publish a minimum RAM or disk size, so these numbers come from the two installs we ran. The installed system used 12 GB of a 60 GB disk. It sat at about 2 GiB of RAM with a terminal and btop open, so 8 GB of RAM and a 60 GB disk are a comfortable floor rather than a tight one.

• x86_64 machine or VM booting in UEFI mode
• Secure Boot and TPM turned off in the firmware
• A whole disk of 60 GB or more (the default install wipes it)
• 8 GB of RAM, 4 CPU cores
• A wired or 2.4 GHz keyboard on bare metal
• Internet access after the install, for updates

The keyboard line matters more than it looks. The LUKS passphrase prompt runs before the Bluetooth stack loads, so a Bluetooth keyboard cannot type it, and you would be stuck at the very first boot. If you only want a dual boot next to Windows, the installer also offers a free-space install, but this guide sticks to the full-disk path because that is what a Proxmox VM needs. If you are still choosing between Omarchy and other Arch spins, our CachyOS install walkthrough and the desktop distribution roundup cover the alternatives.

Download and verify the Omarchy ISO

The ISO lives on iso.omarchy.org and every release page on GitHub links it, so the GitHub API is the reliable way to find the current file name. Omarchy publishes no “latest” alias for the ISO (omarchy-latest.iso returns 404), which is why this pulls the URL out of the newest stable release instead of hardcoding a version:

ISO_URL=$(curl -s https://api.github.com/repos/omacom/omarchy/releases/latest | grep -oE 'https://iso\.omarchy\.org/omarchy-[A-Za-z0-9._-]+\.iso' | grep -v aarch64 | head -1)
echo "$ISO_URL"

You should see a single https://iso.omarchy.org/omarchy-...iso URL. If it prints nothing, GitHub’s unauthenticated API limit (60 requests an hour) is the usual cause, and you can copy the link from omarchy.org instead. Download the ISO and its checksum file, then verify it:

curl -LO "$ISO_URL"
curl -LO "${ISO_URL}.sha256"
sha256sum -c "$(basename "$ISO_URL").sha256"

A good download prints the ISO file name followed by OK. The x86_64 image we tested is 6.1 GiB (6,540,910,592 bytes), so a partial download is easy to spot by size alone. Each release also lists the same SHA256 on its GitHub release page, which is worth comparing if you got the ISO from a mirror.

Write the ISO to a USB stick for bare metal

The ISO is a hybrid image, so a plain dd to the whole device makes a bootable stick. We wrote the same ISO to a raw virtual disk this way and booted the installer from it, which is exactly what a USB stick does. Find the stick first, because writing to the wrong device destroys it:

lsblk -d -o NAME,SIZE,MODEL,TRAN

Pick the device whose size and usb transport match your stick (we use /dev/sdb below), and write the image to the device itself, not to a partition such as /dev/sdb1:

sudo dd if="$(basename "$ISO_URL")" of=/dev/sdb bs=4M status=progress conv=fsync

Use an 8 GB stick or larger. balenaEtcher on macOS or Windows and caligula on Linux do the same job with a confirmation step, and our USB flash drive guide covers sticks that boot reliably. Turn off Secure Boot in the firmware before you boot it: the Omarchy manual is blunt that the install won’t work with it on.

Create the Omarchy VM on Proxmox

Omarchy on Proxmox needs four settings that the Proxmox defaults get wrong: OVMF instead of SeaBIOS, an EFI disk with no pre-enrolled Secure Boot keys, the q35 machine type and a virtio GPU. Get the first two wrong and the ISO never boots; get the GPU wrong and Hyprland has no DRM device to draw on. If you do not have a Proxmox host yet, start with installing Proxmox VE 9 on bare metal.

Run these on the Proxmox node as root. Download the ISO straight into the node’s ISO store with the same detection as before, and set the VM ID once, since every qm command uses it:

export VMID=500
cd /var/lib/vz/template/iso
ISO_URL=$(curl -s https://api.github.com/repos/omacom/omarchy/releases/latest | grep -oE 'https://iso\.omarchy\.org/omarchy-[A-Za-z0-9._-]+\.iso' | grep -v aarch64 | head -1)
curl -LO "$ISO_URL"
curl -LO "${ISO_URL}.sha256"
ISO_FILE=$(basename "$ISO_URL")
sha256sum -c "${ISO_FILE}.sha256"

Now create the VM. Change local-lvm if your VM disks live on another storage (ours were on a ZFS pool). Keep the boot order with the disk first. An empty disk falls through to the ISO on the first boot, and the installed system boots from disk after that.

qm create "$VMID" --name omarchy \
  --bios ovmf --machine q35 --cpu host --cores 4 --memory 8192 \
  --ostype l26 --scsihw virtio-scsi-single \
  --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0 \
  --scsi0 local-lvm:60,discard=on,iothread=1 \
  --net0 virtio,bridge=vmbr0 --vga virtio \
  --ide2 "local:iso/${ISO_FILE},media=cdrom" \
  --boot order='scsi0;ide2'

Check that the four settings that matter actually landed before you start the VM:

qm config "$VMID" | grep -E '^(bios|machine|efidisk0|vga|boot):'

You should see bios: ovmf, machine: q35, an efidisk0 line with pre-enrolled-keys=0 and vga: virtio. Our test VM on a Proxmox VE node got exactly these settings through the Proxmox API, with one difference: the ISO went in as a raw second disk rather than a CD-ROM, and OVMF booted it the same way. Start the VM and open its console in the Proxmox web UI:

qm start "$VMID"

Skip GPU passthrough for a first install. The virtio GPU renders on the CPU, and Omarchy detects the VM and turns off animations and transparency on its own, so the desktop stays usable without a real graphics card. Pass a GPU through later if you want to use the VM as a daily desktop.

Run the Omarchy installer

Boot the VM or the USB stick and you land straight on the Omarchy splash. Our VM reached it about 25 seconds after power on. Press Return to start the install:

The first question is now the language, a new step that comes from Omarchy’s 50-language support. The line under the heading also tells you that Ctrl + C on this screen prepares the machine for another owner, which installs the system and defers the username, password and keyboard to whoever boots it first:

After the language come the keyboard layout and the timezone. The timezone list opened on Africa/Nairobi for us without any input, so it’s worth reading the highlighted entry instead of pressing Return out of habit. Then you set four values:

1. Username: letters and digits, no spaces
2. Password: used for your account, for root and for disk encryption
3. Password confirmation
4. Hostname: Return keeps the default omarchy

That single password protects three things, so pick a strong one you can type at a boot prompt with no password manager around. The installer no longer asks for a git name and email; a “Setup Git” notification on the first boot handles that instead. You get one summary before anything touches the disk:

Select Yes, then pick the install disk. The VM had a single 60 GB disk, listed as /dev/sda, and the installer now lists internal disks first so a USB stick does not end up highlighted. The confirmation screen is the last chance to back out:

Pressing Return here gives you the default LUKS-encrypted install, which is what we used for the desktop screenshots in this guide. The faint line above the buttons is the only hint that Ctrl + C switches to an install without encryption, and the button text changes to confirm it:

We’d only take the unencrypted path for a lab VM or a server-room box that never leaves the rack. A laptop without disk encryption hands your SSH keys and browser sessions to whoever picks it up. Once you confirm, the installer shows a progress animation with a percentage and rotating tips:

The encrypted install finished in 57 seconds and the unencrypted one in 40 seconds, both on a 3 vCPU guest with the ISO and the target on local disks. The time on the finish screen is measured by the installer itself:

Press Reboot Now. On Proxmox, the scsi0;ide2 boot order means the VM now boots the installed system from disk even with the ISO still attached. Detach it once you’re happy, so a later reboot can’t land back in the installer:

qm set "$VMID" --ide2 none,media=cdrom

On bare metal, pull the USB stick when the screen goes dark. Limine now waits only one second before booting, so tap any key during startup if you need the boot menu or a btrfs snapshot.

Unlock the disk and reach the desktop

An encrypted install asks for the LUKS passphrase on every boot. Omarchy installs Plymouth for a themed prompt, but in our virtio-gpu VM it came up as a plain text prompt naming the QEMU disk, which looks broken the first time you see it and isn’t:

Type the installer password and press Return. There’s no second login after this, because the passphrase is the authentication, and the system goes straight into Hyprland. The first desktop shows three notifications: Update System, Setup Git and Learn Keybindings.

Click Update System before doing anything else, since an Arch base that just came off an ISO is already behind the repositories. The disk layout is worth a look too. On our VM, lsblk -f showed a 2 GB FAT32 boot partition and a LUKS2 container holding four btrfs subvolumes (root, home, logs and the pacman cache), plus a 15 GB zram swap device. That split is what lets Omarchy roll back a bad update from a snapshot without touching your home directory.

Install Omarchy unattended on Proxmox

If you rebuild Omarchy VMs often, skip the wizard entirely. The ISO looks for a second drive labeled cidata (the cloud-init NoCloud label) and, when it finds the configuration files of the installer on it, installs and reboots with nobody at the keyboard, as the unattended install page of the manual describes. We tested this on a Proxmox VE node: the VM went from power on to an SSH login in about three minutes.

The configuration files are the ones the wizard itself writes to /root of the live session, so the easiest way to get them is one interactive install. Make that run the unencrypted one (Ctrl + C on the disk confirmation), so the copied configuration carries no LUKS block. Before you press Reboot Now on the finish screen, switch to a console with Ctrl + Alt + F2 and log in as root (the live ISO has no root password). Then copy these files out over the network or to a USB stick.

• user_configuration.json: disk layout, hostname, timezone, keyboard, kernel (required)
• user_credentials.json: username and SHA-512 password hash (required)
• user_encrypt_installation.txt: optional, leave it off the cidata drive
• authorized_keys: your SSH public keys (you add this one)

Add authorized_keys yourself, because a stock install ships OpenSSH with the service disabled and the port closed. With the file present, the installer enables sshd and opens the firewall for it, which is the only way into a VM nobody is watching. Use an unencrypted install for this: an encrypted unattended install still stops at the LUKS prompt on first boot, and its configuration carries the passphrase in plain text.

This is the exact user_configuration.json our unencrypted wizard run wrote and the Proxmox VM then installed from. The partition sizes are computed for a 60 GiB disk at /dev/sda, which is what a virtio-scsi scsi0 disk shows up as, so give your VM the same disk or generate your own file:

{
    "app_config": null,
    "archinstall-language": "English",
    "auth_config": {},
    "audio_config": { "audio": "pipewire" },
    "bootloader_config": { "bootloader": "Limine", "uki": false, "removable": false },
    "custom_commands": [],
    "omarchy_install": {
        "input_method": "none",
        "input_xkb_layout": "",
        "language": "en",
        "mode": "full_disk",
        "defer_provisioning": false,
        "target_mount": "/mnt",
        "boot": {
            "esp_mount": "/boot",
            "esp_path": "/EFI/limine",
            "efi_binary": "limine_x64.efi",
            "enable_fallback": true
        },
        "storage": {
            "kernel": "linux-omarchy"
        }
    },
    "disk_config": {
        "config_type": "default_layout",
        "device_modifications": [
            {
                "device": "/dev/sda",
                "partitions": [
                    {
                        "btrfs": [],
                        "dev_path": null,
                        "flags": [ "boot", "esp" ],
                        "fs_type": "fat32",
                        "mount_options": [],
                        "mountpoint": "/boot",
                        "obj_id": "ea21d3f2-82bb-49cc-ab5d-6f81ae94e18d",
                        "size": {
                            "sector_size": { "unit": "B", "value": 512 },
                            "unit": "B",
                            "value": 2147483648
                        },
                        "start": {
                            "sector_size": { "unit": "B", "value": 512 },
                            "unit": "B",
                            "value": 1048576
                        },
                        "status": "create",
                        "type": "primary"
                    },
                    {
                        "btrfs": [
                            { "mountpoint": "/", "name": "@" },
                            { "mountpoint": "/home", "name": "@home" },
                            { "mountpoint": "/var/log", "name": "@log" },
                            { "mountpoint": "/var/cache/pacman/pkg", "name": "@pkg" }
                        ],
                        "dev_path": null,
                        "flags": [],
                        "fs_type": "btrfs",
                        "mount_options": [ "compress=zstd" ],
                        "mountpoint": null,
                        "obj_id": "8c2c2b92-1070-455d-b76a-56263bab24aa",
                        "size": {
                            "sector_size": { "unit": "B", "value": 512 },
                            "unit": "B",
                            "value": 62274928640
                        },
                        "start": {
                            "sector_size": { "unit": "B", "value": 512 },
                            "unit": "B",
                            "value": 2148532224
                        },
                        "status": "create",
                        "type": "primary"
                    }
                ],
                "wipe": true
            }
        ]
    },
    "hostname": "omarchy-pve",
    "kernels": [ "linux-omarchy" ],
    "network_config": { "type": "iso" },
    "ntp": true,
    "parallel_downloads": 8,
    "script": null,
    "services": [],
    "swap": true,
    "timezone": "Africa/Nairobi",
    "locale_config": {
        "kb_layout": "us",
        "sys_enc": "UTF-8",
        "sys_lang": "en_US.UTF-8"
    },
    "mirror_config": {
        "custom_repositories": [],
        "custom_servers": [
            {"url": "https://mirror.omarchy.org/$repo/os/$arch"},
            {"url": "https://mirror.rackspace.com/archlinux/$repo/os/$arch"},
            {"url": "https://geo.mirror.pkgbuild.com/$repo/os/$arch"}
        ],
        "mirror_regions": {},
        "optional_repositories": []
    },
    "packages": [
        "base-devel",
        "git",
        "omarchy-keyring",
        "omarchy-settings",
        "omarchy"
    ],
    "profile_config": {
        "gfx_driver": null,
        "greeter": null,
        "profile": {}
    },
    "version": "3.0.9"
}

Change hostname and timezone to suit, and leave the rest alone unless your disk size differs. The credentials file has the same shape the wizard writes; generate a hash for your own password first. Without an argument, openssl prompts for it, which keeps the password out of your shell history:

openssl passwd -6

Open the credentials file in the folder that will become the cidata drive:

mkdir -p cidata
vim cidata/user_credentials.json

Paste the hash into both password fields. Ours was identical to this apart from the hash itself:

{

    "root_enc_password": "PASTE_THE_OPENSSL_HASH_HERE",
    "users": [
        {
            "enc_password": "PASTE_THE_OPENSSL_HASH_HERE",
            "groups": [],
            "sudo": true,
            "username": "josphat"
        }
    ]
}

Copy the configuration and your public key next to it, then pack the folder into a small ISO with the cidata volume label. On a Proxmox node, genisoimage is one apt install genisoimage away.

cp user_configuration.json cidata/
cp ~/.ssh/id_ed25519.pub cidata/authorized_keys
genisoimage -output /var/lib/vz/template/iso/cidata.iso -volid cidata -joliet -rock cidata/

Our build of that ISO was 372 KB and blkid reported LABEL="cidata" TYPE="iso9660". The unattended install needs a fresh VM with an empty disk, not the one you already installed. Set a new ID, run the qm create command from the Proxmox section again, and leave the ISO on ide2:

export VMID=501

With that VM created, attach the cidata ISO as a second CD-ROM, start it and walk away. Our test passed the same ISO to the VM as a raw disk instead, which the loader finds by label just the same:

qm set "$VMID" --ide3 local:iso/cidata.iso,media=cdrom
qm start "$VMID"

Keep the Proxmox cloud-init drive off this VM. The loader script on the ISO (omarchy-cidata-load) mounts the first drive it finds labeled cidata, and a Proxmox cloud-init drive carries that same label without the Omarchy files on it. Our test VM was cloned from a cloud-init template, so we removed its cloud-init drive before the first Omarchy boot.

The installed system takes a new DHCP lease, and on our network it came up on a different address than the live ISO had used. Look for it by the MAC address that qm config "$VMID" shows on the net0 line, in your DHCP server or with ip neigh after a ping sweep. Then SSH in with the key you put on the drive.

ssh [email protected] 'hostnamectl | grep -E "hostname|Operating|Kernel|Hardware Model"; pacman -Q hyprland linux-omarchy; systemd-analyze | head -1'

Our Proxmox VM answered with the hostname from the JSON, Omarchy’s kernel and Hyprland build, and a boot time of under 12 seconds without the LUKS wait:

 Static hostname: omarchy-pve
Operating System: Omarchy
          Kernel: Linux 7.2.8-9-omarchy
  Hardware Model: Standard PC _Q35 + ICH9, 2009_
hyprland 0.56.2-4
linux-omarchy 7.2.8-9
Startup finished in 4.845s (firmware) + 2.033s (loader) + 1.314s (kernel) + 1.339s (initrd) + 2.333s (userspace) = 11.867s

An unencrypted install doesn’t log you in by itself. With no LUKS prompt to act as the login, the VM stops at the SDDM greeter, which runs on its own Hyprland compositor: ps showed Hyprland and sddm-greeter-qt under the sddm user, drawing on the Virtual-1 output. Log in once from the Proxmox console and the normal desktop starts. For more template-style automation on the Proxmox side, the same NoCloud idea drives our Proxmox templates from cloud images.

Learn the keybindings and workspace layouts

Omarchy is keyboard-first, and two defaults changed in ways that break old muscle memory: Super + Space now opens the Omarchy menu, and the old Style menu became Appearance. These are the bindings you’ll use in the first hour, taken from omarchy menu keybindings --print on the installed system:

Shortcut	Action
Super + K	Keybindings list
Super + Space	Omarchy menu
Super + Return	Terminal (foot)
Super + Shift + Return	Browser
Super + Shift + F	File manager
Super + W or Super + Q	Close window
Super + L	Cycle workspace layout
Super + M	Minimize window to the dock
Super + T	Toggle floating or tiling for a window
Super + 1 to 0	Switch to workspace 1 to 10
Super + ~	Quake-style console
Super + Ctrl + L	Lock
Super + Escape	System menu

Everything else lives in the Omarchy menu on Super + Space, from installing optional apps to switching the update channel:

Appearance gathers the theme, background, font, menu bar, window gaps, workspace layout and animations in one place. Its theme picker previews each theme across a terminal, an editor and the file manager before you commit, and Tokyo Night is the default:

If you forget a shortcut, Super + K opens the searchable list the table above came from, and typing part of an action filters it:

The bigger change is per-workspace layouts. Super + L cycles the current workspace between dwindle tiling, scrolling and floating, and the bar shows which layout each workspace uses. On a floating workspace every window gets a titlebar in the theme’s colors and a dock appears at the bottom with pinned apps, running apps and a grid of everything installed:

That makes it easy to keep one workspace for tiled terminals and another for apps that hate tiling, such as LibreOffice dialogs or a video call. Multiple monitors now get their own workspaces too, so Super + 1 goes to workspace 1 of the monitor you’re on. Our VM had a single virtual display, so we couldn’t check that one ourselves; it comes from the release notes.

Check the Hyprland version and update Omarchy

Omarchy’s Hyprland comes from the Omarchy repository, not from Arch’s extra, so the version you get is whatever Omarchy has built and tested. Check it from a terminal inside the Hyprland session:

hyprctl version | head -3
pacman -Q hyprland linux-omarchy

The first line of hyprctl version is the build that is actually running, and pacman -Q is the package on disk. They should match; if they don’t, an update replaced the package and you haven’t restarted Hyprland since. Our install showed this:

To update, use Omarchy’s own command rather than a bare sudo pacman -Syu. Its help text describes it as “Update Omarchy and system packages”, so it covers the Omarchy layer and the Arch packages in one run, and it is the path Omarchy supports when an update goes wrong:

omarchy update

You can run the same update from Update in the Omarchy menu, and omarchy update analyze logs checks the update log for known failure conditions if one goes wrong. For plain pacman work outside the Omarchy tooling, our pacman and yay cheat sheet still applies, because it’s Arch underneath.

Expect these quirks in a VM

None of these stopped the install, but each one looked like a fault the first time we hit it. They all come from running Omarchy on virtual hardware rather than a laptop:

• The LUKS prompt is plain text on virtio-gpu, not the Plymouth screen
• Animations and transparency start off, and Appearance offers “Animations On”
• An unencrypted install stops at the SDDM login instead of the desktop
• The installed system takes a new DHCP lease, separate from the live ISO’s
• The live ISO console runs zsh, so bash-only tricks like /dev/tcp need bash -c

The animations one is deliberate. A script in the installer (vm-no-animations.sh) checks for a VM and switches on the no-animations and opaque-window toggles. A guest without a GPU renders every frame on the CPU. Leave them off unless you’ve passed a real GPU through. For everything else, Omarchy in a Proxmox VM behaved like the bare metal install: same packages, same Lua config and the same Hyprland build, which makes a VM a cheap way to try it before you wipe a laptop for it. If you then want a hand-built Arch with the same encryption, our guides to installing Arch with archinstall and Arch on LUKS take it from there, and the terminal benchmarks show how foot compares with the terminal Omarchy used to ship.