Package managers update a running system in place, which means a failed upgrade leaves you somewhere between two versions with a machine that might not boot. APEX-OS builds on Fedora bootc instead: the operating system is an OCI image, updates replace it in one transaction, and the previous image stays on disk to roll back to.
Two editions from one base
| Edition | Accent | Built for |
|---|---|---|
| Gaming | Gold | A performance-tuned desktop |
| Daily | Chartreuse | A general-purpose daily driver |
Both editions come off a shared base image and diverge in packages, tuning and branding. Keeping one base means a fix lands in both without me maintaining two trees.
apexd
A first-party system daemon written in Rust manages the machine. An image-based system needs something owning update state, rollback and the edition-specific tuning, and hanging that off shell scripts stops scaling once rollback enters the picture.
The desktop
APEX Shell is the native desktop: a Quickshell and QML shell running on Hyprland and niri. It derives from Brain_Shell by Brainitech, used under the MIT licence. The kernel underneath is a custom build based on CachyOS patches.
Installing it
The releases page carries a netinstall ISO per edition alongside a .sha256. You need a 4 GB USB stick, 16 GB of disk and a network connection during the install, since the image downloads as part of installing rather than shipping inside the ISO. Budget about half an hour, most of it waiting.
The install guide asks you to verify the checksum before writing the stick. A truncated ISO fails much later and presents as a hardware fault, which costs far more time than the check does.