Get started

Which ring is for me?

1. Choose a ring and your architecture

Not sure? stable is the one to use on a machine you rely on.

The one command

Everything below, done for you — once per machine, on x86_64 or aarch64 (it finds out):

copy

What it does, and nothing else: trusts the key that signs the pool's databases (step 2); writes /etc/pacman.d/omarchy-pool.conf with the repositories the ring serves right now (step 3 — asked to the pool at run time, so it is never stale); adds one line to /etc/pacman.conf, above [core], once: Include = /etc/pacman.d/omarchy-pool.conf; runs pacman -Sy and tells you to run the upgrade — omarchy update on an Omarchy install (its pacman hook refuses a bare pacman -Syu), sudo pacman -Syu elsewhere. It keeps a backup (pacman.conf.bak-omarchy-pool), it never upgrades on its own, and it never touches your other repositories.

Why an Include, above [core]. pacman takes a package from the first repository that has it, in file order. What you keep above the line — an Asahi [omarchy] or [asahi-alarm] on a Mac, a repository of your own — keeps priority; the pool serves core, extra, multilib, alarm, the OPR and the factory's builds from the ring; Arch's own mirrors below the line stay as the fallback for the rare package the pool does not have yet, and for repositories it does not mirror ([aur] on Arch Linux ARM). Switching rings rewrites the include file only: --ring rc, --ring edge; --remove deletes it and takes the line out. The script, in full →

The first upgrade. Usually "nothing to do": stable is hours behind upstream, and pacman never downgrades what a mirror already gave you. From then on the upgrades come through the ring when it promotes them.

2. Trust the database key

Once per machine. The key signs the pacman databases and the packages the pool builds itself (source factory); every other package still carries its upstream signature.

copy

3. Configure pacman, by hand

Save the sections below as /etc/pacman.d/omarchy-pool.conf (sudo nvim, or curl -o from /api/v1/pacman.conf?ring=…&arch=… — the same text), then add Include = /etc/pacman.d/omarchy-pool.conf to /etc/pacman.conf above [core]. The list is what the ring serves right now.

copy# omarchy-pool — ring stable, x86_64. Generated from what the ring serves (release #25).
# Included from /etc/pacman.conf above [core]; the mirrors below it are the fallback.
# https://pkgs.omarchy-pool.org/setup rewrites this file; edit /etc/pacman.conf, not this.

[omarchy-packages-stable]
SigLevel = Required DatabaseRequired
Server = https://pool.omarchy-pool.org/packages/$arch

[omarchy-core-stable]
SigLevel = Required DatabaseRequired
Server = https://pool.omarchy-pool.org/core/$arch

[omarchy-extra-stable]
SigLevel = Required DatabaseRequired
Server = https://pool.omarchy-pool.org/extra/$arch

[omarchy-multilib-stable]
SigLevel = Required DatabaseRequired
Server = https://pool.omarchy-pool.org/multilib/$arch

Then:

copyomarchy update   # off Omarchy: sudo pacman -Syu

Optional: omarchy-cli

A thin client that knows about rings and releases: status shows what the ring would change on this machine, check runs the ABI safety check before an out-of-band install, upgrade drives pacman and pins the release you are on, security lists the advisories that apply here. A package of the factory, in every ring; not on your ring yet? Binaries for both architectures ship with every release.

copy

Switching rings, going back

Only the repository names change between rings (omarchy-core-stable → omarchy-core-rc); the packages are the same objects. A ring itself rolls back automatically when a promotion fails its health check — you do not have to do anything, the next pacman -Syu sees the restored release.