Omakade: a local-first game library for Omarchy and Arch

What Omakade solves for multi-launcher Linux desktops

A Linux desktop with games installed through Steam, Lutris, Heroic, Faugus, RetroArch and a handful of emulators has no single place to look. Each launcher keeps its own library, its own artwork and its own idea of what a game is. Omakade is a C++ and QML application that scans those sources and presents the results as one cover-focused library. The README describes it as "a Linux game library built for Omarchy" and lists discovery for native and Flatpak Steam, Lutris, Heroic, Faugus, RetroArch, PCSX2, Ryujinx, Cemu, shadPS4, Dolphin and Xenia, plus direct GOG installation discovery, Steam non-Steam shortcuts, games sideloaded into Heroic, and Battle.net titles living in Wine, Proton or Bottles prefixes. The intended user is someone on Omarchy or Arch who already has games scattered across those tools and does not want to reinstall anything. The README states plainly that Omakade is an independent community project and not an official Omarchy application, so the Omarchy connection is a design target, not an endorsement.

How discovery and launching actually work

Omakade reads launcher data without modifying it. That single sentence in the README defines the architecture: the application is a reader and an indexer, not a package manager. It scans known locations, builds its own catalog, and launches games through the platform that owns them, which the feature list calls "delegated launching through the owning platform." A GOG game installed through Heroic still launches through Heroic. Native Linux builds launch directly; Windows game builds run on Linux through umu-run with an isolated per-game prefix. Because core discovery, browsing, artwork and launching work offline, the network-dependent pieces are opt-in: IGDB ratings and game-length estimates, SteamGridDB portrait covers, Steam owned-library sync, RetroAchievements progress, ProtonDB badges and the read-only RomM integration. The README also notes that Omakade ships a deterministic fictional library behind omakade --demo, which is a useful way to inspect the interface before pointing it at real data. Optional Sunshine app export lets Moonlight start Omakade or any installed game, and the binary exposes --play and --quit commands.

Installing Omakade on Omarchy or Arch and running a first scan

On Omarchy, the README gives the Omarchy Package Repository as the shortest path, and notes that OPR may carry an older version than the latest GitHub release.

sudo pacman -S omarchy/omakade

If you need the published version, the README provides a download, checksum verification and an in-place upgrade for x86_64. ARM64 users replace x86_64 with aarch64 in the filename and URL.

curl -fLO https://github.com/btsouth/omakade/releases/download/v1.9.2/omakade-1.9.2-1-x86_64.pkg.tar.zst
curl -fLO https://github.com/btsouth/omakade/releases/download/v1.9.2/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
sudo pacman -U ./omakade-1.9.2-1-x86_64.pkg.tar.zst

After installation, the first useful step is not a real scan but the demo library. The README says to run this to explore the UI with a deterministic fictional library:

omakade --demo

What you should see is a cover grid populated with fictional entries, which tells you whether the theme integration and cover sizing behave on your display before any real data is indexed. When you switch to your real library, check the runtime source controls, which the README says show scan status and detected locations. If your GOG games are not found, the README states that direct discovery checks ~/GOG Games, ~/Games/GOG, ~/Games/Heroic and immediate game folders under ~/Games, and that Extra GOG Folders in Settings adds library folders by path or through the desktop folder picker. The environment variable OMAKADE_GOG_LIBRARY_PATHS remains an additive, colon-separated list of extra roots.

Where Omakade stops: platform limits and wrapper failures

The clearest boundary is in the README itself: Omakade itself does not run on Windows. It is a Linux application, packaged for x86_64 and ARM64, and the Windows support it offers is for running Windows game builds on Linux through umu-run, not for running Omakade on Windows. The second limitation is documented in issue #13 and repeated in the README: on ARM64, the fex-steam wrapper that provides /usr/bin/steam can fail to start games from any steam:// request, including Steam's own client. The README calls that a wrapper limitation that Omakade cannot work around. That matters because delegated launching depends on the owning platform handling the request; if the platform's own entry point is broken, the library cannot compensate. A third boundary is philosophical rather than technical: Omakade reads launcher data without modifying it. If you want a tool that moves installs between prefixes, rewrites launcher configuration, or manages downloads, this is the wrong tool, since its job is to index what is already installed and hand launches back to the owner. Finally, the feature list is long and much of it is optional integrations that depend on third-party services; the offline core is discovery, browsing, artwork and launching.

Omakade compared with Lutris and Heroic as the front end

Lutris and Heroic are installers and runners first. They create prefixes, fetch installers, manage Wine and Proton versions, and keep their own library of what they installed. Omakade inverts that relationship: it does not install games, and it delegates launching to the platform that owns each title. The practical difference shows up in a library that spans sources. Lutris knows about what Lutris manages; Heroic knows about Heroic, GOG, Epic and Amazon. Omakade's README claims discovery across Steam, Lutris, Heroic, Faugus, RetroArch, a list of emulators, direct GOG folders, Battle.net prefixes and Steam non-Steam shortcuts, and then links games installed through multiple sources explicitly rather than duplicating them. That makes Omakade complementary to Lutris or Heroic rather than a replacement: you keep installing and running through them, and use Omakade as the view. The trade-off is dependency. Every launcher it reads is a moving target, so a Lutris or Heroic layout change can break discovery until Omakade ships an update, and the release cadence in September 2026 (1.9.0, 1.9.1 and 1.9.2 within three days) suggests that kind of chasing is ongoing.

Licence, packaging and the cost of keeping up

Omakade is licensed GPL-3.0-or-later, and the repository carries a COPYRIGHT file alongside LICENSE. For anyone embedding, redistributing or forking it, that means the usual copyleft obligations apply to derivative distribution; the project does not offer a separate commercial licence anywhere in its documentation, and nothing here is legal advice. On the maintenance side, the repository was not archived and the last push was on 2026-09-16, two days after the 1.9.2 release on 2026-09-14, with 1.9.1 and 1.9.0 landing on 2026-09-13. That is a fast release rhythm for a project of this scope, and it has a cost for the user: the README notes that the Omarchy package repository may carry an older version than the latest GitHub release, so sudo pacman -S omarchy/omakade and the verified release package can put different versions on your machine. Upgrades through pacman -U are documented as in-place, without removing settings or library data. The repository also ships checksums, SBOMs and signed provenance for its packages, according to the feature list, which matters if you are installing a binary you did not build. The top-level tree includes tests/, scripts/, packaging/, CMakeLists.txt and CMakePresets.json, so building from source is possible, but the README's documented path is the package.

Editorial conclusion

Adopt Omakade if you run Omarchy or Arch with games spread across Steam, Lutris, Heroic, Faugus and emulator frontends, and you want one cover-focused, offline-capable view that follows your theme. Skip it if you are on Windows (the README states Omakade itself does not run on Windows), if you want a launcher that manages installs rather than reading them, or if you expect a stable API: the project shipped 1.9.0, 1.9.1 and 1.9.2 within three days in September 2026, so check CHANGELOG.md before pinning a version. Before adopting, verify three things: that your GOG games live in one of the scanned paths or are registered under Extra GOG Folders, that your emulator save sets are covered by versioned save protection, and, on Asahi Linux, whether your Steam wrapper is fex-steam, since issue #13 reports that wrapper can fail to start games from any steam:// request.

Frequently asked questions

Official sources

1. btsouth/omakade on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases