Shelly ALPM: a GTK4 package manager for Arch Linux that talks to libalpm directly

What Shelly ALPM replaces, and who it is aimed at

Pacman is a terminal program. Every search, conflict prompt and orphan cleanup happens as text in a shell, and the graphical front ends that exist tend to wrap pacman's output rather than talk to the library underneath it. Shelly takes the other route. The README states that Shelly "interfaces directly with libalpm", the same library pacman links against, which is why the project can present package state in a GTK4 window without parsing pacman's stdout.

The audience is narrower than "Arch users". Shelly is described as designed for Arch Linux and Arch-based distributions, and the recommended installation method is the CachyOS package. That tells you where the maintainers expect the bulk of installs to land: CachyOS, a distribution that already ships its own repositories and tooling. A user on plain Arch has the AUR path instead, which means trusting an AUR helper to build the package. If you administer servers over SSH and never open a graphical session, the GTK4 front end is dead weight, though the CLI still exists.

How Shelly talks to libalpm, AUR and Flatpak

The repository splits the work across several components rather than shipping one binary. Shelly.PackageManager holds what the README calls "Core libalpm/AUR/AppImage logic plus the backend-neutral Flatpak facade and secure loader". Shelly.Ui.Gtk is the GTK4 desktop application. Shelly.Cli.Zig is the command-line interface used by both terminal users and the UI. Shelly.Http is a standalone HTTP client with what the README describes as a compatibility TLS implementation, which matters because AUR and AppImage work needs network access outside pacman's own fetchers.

Flatpak is the interesting design decision. The base package does not depend on Flatpak at runtime. Instead, libflatpak and GLib implementation details live in Shelly.Flatpak.Backend, a versioned shared library loaded only when a Flatpak operation is requested. The README states that a base-only installation keeps ALPM, AUR, AppImage, help, version and completion commands available. That separation is deliberate enough to have its own verification script and an ABI document at docs/flatpak-backend-abi.md covering memory ownership, discovery rules and the version-bump procedure.

There is also a tray component. Shelly-Notifications is described as a tray service to manage notifications for the Shelly UI, and the README notes it starts with the UI or can be configured to launch at startup.

Installing Shelly on CachyOS or Arch and running it once

The README gives the CachyOS package as the recommended path. This installs the latest release including both the UI and CLI tools.

sudo pacman -S shelly

On plain Arch, or anywhere the package is not in the configured repositories, the README points to an AUR helper. Either of these builds and installs Shelly from the AUR.

yay -S shelly

paru -S shelly

If you would rather build from source, the repository ships a git PKGBUILD. The README's sequence copies PKGBUILD-git over PKGBUILD and runs makepkg.

git clone https://github.com/Seafoam-Labs/Shelly-ALPM.git
cd Shelly-ALPM
cp PKGBUILD-git PKGBUILD
makepkg -si

Building from source needs zig 0.16.0, vala and libalpm, which comes from pacman. Once installed, the GUI and the CLI are separate entry points.

shelly-ui

shelly

Expect the first CLI run to create a default configuration file at ~/.config/shelly/config.json. The README does not list the individual keys; it links to a configuration page on the project site for those. One documented CLI operation is generating makepkg-compatible SRCINFO from a PKGBUILD you have already reviewed, without running the build lifecycle.

shelly build --makesrcinfo --reviewed PKGBUILD > .SRCINFO

Where Shelly is not ready, and where it is the wrong tool

The roadmap is the honest signal here. Repository modification is listed as in progress, and offline updates are listed as a target with no shipped equivalent. The README does not document rollback, downgrade handling or what happens to a partially completed transaction if the UI is closed mid-operation. Those are exactly the moments where a package manager earns trust, and the documentation is silent on them.

The Flatpak arrangement is a trade-off in the other direction. Keeping Flatpak out of the base package means fewer dependencies and a smaller install, but it also means a Flatpak operation fails unless both flatpak and shelly-flatpak-backend are present, and the backend is loaded only for that operation. If you expect one tool to manage native packages and Flatpaks out of the box, the base install will disappoint you.

Finally, consider the maturity curve. Three releases landed between 2026-08-14 and 2026-08-26, which suggests rapid iteration rather than a settled interface. The default branch is named development. If you manage a workstation you cannot afford to repair by hand, the pacman commands you already know remain the safer default, and Shelly is something to run alongside them rather than instead of them.

Shelly against pacman and the wrapper front ends

The obvious comparison is pacman itself. Pacman is the reference implementation, it is already installed, and every Arch guide assumes it. Shelly does not replace the package database or the repositories; it reads and writes through libalpm, so the underlying state is the same. What you gain is a GTK4 interface, a JSON configuration file at ~/.config/shelly/config.json, and a CLI whose documented surface includes things pacman does not do, such as producing .SRCINFO from a reviewed PKGBUILD.

The second comparison is against graphical front ends that shell out to pacman and parse its output. That approach inherits pacman's exact behaviour, including its prompts, but it is brittle whenever pacman's output format changes and it cannot easily offer structured progress. Linking libalpm directly avoids the parsing layer at the cost of tracking the library's own API. Shelly's component split, with a separate HTTP client and a versioned Flatpak backend, is the consequence of taking that path.

AUR support is where the difference is most visible in day-to-day use. Pacman has no AUR concept at all, so every AUR workflow depends on a helper like yay or paru. Shelly folds AUR into the same application as the native package view, which is convenient, but it also means the AUR code path lives inside the same process as your system package operations.

Building Shelly from source and running its test suites

The README documents per-component test commands, which is useful because it lets you verify a build without installing the desktop application. Each component is built and tested from its own directory.

(cd Shelly.Flatpak.Backend && zig build integration-test)
(cd Shelly.Http && zig build test)
(cd Shelly.PackageManager && zig build test)
(cd Shelly.Cli.Zig && zig build test)
(cd Shelly.Ui.Gtk && zig build test)

The Flatpak backend has a fuller set of targets, including an ABI test and a parity test alongside the integration test.

(cd Shelly.Flatpak.Backend && zig build test abi-test parity-test integration-test)

To check both optional configurations and confirm the ELF boundaries between them, the repository provides a script.

scripts/test-flatpak-separation.sh

That script is the one to run first if you plan to rely on the Flatpak path, because it is the documented way to verify the separation the README describes. Manual testing notes live in MANUAL_TESTING.md, and the Flatpak backend's ABI, memory ownership and version-bump rules are in docs/flatpak-backend-abi.md.

Licence, maintenance and the cost of upgrading

Shelly is licensed under GPL-3.0, with the LICENSE file at the repository root. That is the same licence family as much of the Arch tooling around it. The practical implication is that if you redistribute a modified Shelly, or ship a product that links against it, the GPL's source-availability terms apply to that distribution. This is a description of the licence text, not legal advice; if you plan to bundle Shelly in a commercial image, read the LICENSE file and talk to someone qualified.

The GPL also matters for the optional backend. Because the Flatpak backend is a shared library loaded at runtime rather than linked at build time, the repository documents its ABI and version-bump procedure separately. Anyone packaging Shelly for a distribution should read docs/flatpak-backend-abi.md before bumping that library, since a version mismatch is the kind of problem that shows up only when a user triggers a Flatpak operation.

On maintenance: the last push to the repository was on 2026-08-26, and the most recent release, v3.1.1, carries the same date. The project is not archived. Upgrading is handled through the same channels as installation, either the CachyOS package or the AUR, so the upgrade cost is mostly the cost of re-reading the configuration page when a release changes a config key. The README does not promise configuration stability across releases.

Editorial conclusion

Shelly suits Arch and CachyOS users who want a GTK4 front end over libalpm and are willing to install it from the CachyOS repositories or an AUR helper such as yay or paru. Skip it if you need a stable desktop, since the roadmap still lists repository modification and offline updates as unfinished. Before adopting, run shelly build --makesrcinfo --reviewed PKGBUILD, then scripts/test-flatpak-separation.sh, to confirm the CLI and the optional backend build cleanly on your machine.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes