Shelly-ALPM: A GTK4 and Zig Package Manager That Puts libalpm at the Center

What Shelly-ALPM Actually Solves

Shelly-ALPM is aimed at Arch Linux users who find pacman's command-line interface intimidating or who want a graphical way to manage packages without losing the underlying system's integrity. It is also for developers and power users who appreciate a CLI that can be scripted, since the same core logic powers both interfaces. The project's emphasis on native Wayland support and GTK4 suggests it targets modern Linux desktops, not legacy X11 environments. If you are comfortable with pacman and have no need for a GUI, Shelly may not offer enough to justify switching. But if you manage multiple Arch systems or want to introduce new users to Arch without forcing them to memorize pacman flags, Shelly provides a middle ground.

The Architecture: Zig Components and a Flatpak Backend

The repository is split into several Zig components, each with a clear responsibility. Shelly.PackageManager holds the core libalpm, AUR, and AppImage logic, plus a backend-neutral Flatpak facade. Shelly.Ui.Gtk is the GTK4 desktop application, while Shelly.Cli.Zig is the command-line interface. Shelly.Http is a standalone HTTP client with a compatibility TLS implementation, and Shelly.Flatpak.Backend is an optional versioned shared library that contains all libflatpak and GLib-native details. Shelly-Notifications is a tray service that manages notifications for the UI. This separation is deliberate: the Flatpak backend is loaded only when a Flatpak operation occurs, so a base installation without Flatpak support does not pull in libflatpak as a runtime dependency. The README mentions a script, scripts/test-flatpak-separation.sh, that builds both optional configurations and verifies their ELF boundaries, which suggests the project takes the isolation seriously. The backend ABI, memory ownership, and version-bump procedure are documented in docs/flatpak-backend-abi.md, indicating a design that expects the backend to evolve independently. This modularity is a strength for maintainability, but it also means that building from source requires Zig 0.16.0 and vala, which are not trivial prerequisites for casual users.

Getting It Running: Install and Build Paths

The quickest installation path is to use a prebuilt package from CachyOS repositories or an AUR helper. The README shows sudo pacman -S shelly for CachyOS, and yay -S shelly or paru -S shelly for AUR users. Uninstall is equally straightforward with sudo pacman -Rns shelly or the corresponding AUR helper command. For those who prefer to build from source, the repository provides a PKGBUILD-git file that you copy to PKGBUILD and run with makepkg -si. The manual build process is more involved: you can test each Zig component independently with commands like (cd Shelly.PackageManager && zig build test) and (cd Shelly.Ui.Gtk && zig build test). The CLI is invoked as shelly, and the UI as shelly-ui. Notifications are started with the UI or can be configured to launch at startup via shelly-notifications. The CLI automatically creates a default configuration file at ~/.config/shelly/config.json on first run, which is a JSON file that controls behavior. The README points to external documentation for the full list of configuration options, so you will need to visit the project's website for details. The build process requires Zig 0.16.0 and vala, which are not standard on all Arch systems, so expect to install those first.

The CLI: More Than a Pacman Clone

The Shelly-CLI is not just a terminal version of the UI; it has its own commands and features. One notable example from the README is a command that generates a makepkg-compatible SRCINFO file from a reviewed PKGBUILD without running its build lifecycle: shelly build --makesrcinfo --reviewed PKGBUILD > .SRCINFO. This is a safety-oriented feature that lets you inspect package metadata without executing arbitrary build scripts. The CLI supports searching, filtering, installing, updating, and removing packages, and it integrates with AUR. The README mentions that the CLI provides the same core functionality as the UI, but in a scriptable format. This is important for automation and for users who prefer the terminal. The CLI also has completion commands, which are part of the base installation. The configuration file is JSON, which is a departure from pacman's plain-text config and may be easier for some users to parse programmatically. However, the README does not list the actual configuration keys, so you will need to consult the online reference. The CLI's integration with libalpm means it should handle transactions with the same consistency as pacman, but it is a separate codebase, so bugs are possible.

Aur and Flatpak: Integration with Caveats

Shelly supports AUR integration, which is a significant feature for Arch users who rely on the Arch User Repository. The README does not detail how AUR packages are handled, but it is listed as a core feature. Flatpak support is optional and implemented as a separate backend package, shelly-flatpak-backend. This design means that the base Shelly package does not depend on Flatpak at runtime; the backend is loaded only when a Flatpak operation is performed. The README explicitly states that a base-only installation keeps ALPM, AUR, AppImage, help, version, and completion commands available. This separation is a smart move to keep the core lightweight, but it also means that if you want Flatpak management, you must install an additional package and trust that the backend's ABI remains compatible. The project includes tests for ABI and parity, which is reassuring, but the documentation warns that the backend is versioned, so upgrades may require coordination. For users who want a single tool to manage both native and Flatpak packages, this adds an extra step, but it avoids bloating the base install.

Limitations and the Wrong Tool Scenarios

Shelly-ALPM is still under active development, with the latest release being v3.1.1 from August 2026. The roadmap lists repository modification as in progress, meaning you cannot yet modify repository settings through Shelly. Offline updates, similar to pacman-offline, are also not yet implemented. This makes Shelly a poor choice for users who need to manage custom repositories or plan offline system updates. The project's default branch is development, which suggests that the stable branch may lag behind. The build prerequisites of Zig 0.16.0 and vala are not trivial, and if you are not familiar with Zig, debugging build issues could be challenging. The README does not mention any official support for non-Arch distributions, so this is strictly for Arch-based systems. The CLI and UI are separate binaries, which could lead to inconsistencies if one is updated without the other. The project's reliance on libalpm means it inherits the same transaction limitations as pacman, such as not being able to install packages from different repositories in a single transaction without resolving conflicts. For users who need a mature, feature-complete package manager, Shelly may not yet be ready.

Alternative: Pacman and Pamac

The most direct alternative to Shelly is pacman itself, which is the default package manager on Arch Linux. Pacman is a command-line tool that also uses libalpm, so it provides the same underlying functionality. The difference is that pacman has no graphical interface and its CLI is less forgiving for beginners. Pamac is a graphical package manager for Arch that supports AUR and Flatpak, but it is written in C and uses its own backend, not libalpm directly. Pamac is often used by Manjaro users and is available in the official repositories. The key difference is that Pamac is a separate project with its own configuration and may not always stay in sync with pacman's behavior. Shelly's approach of using libalpm directly means it is more likely to behave like pacman, but it is also a younger project with fewer users. If you want a graphical interface with a proven track record, Pamac might be a safer choice. If you prefer the terminal, pacman is the standard. Shelly's value proposition is the combination of a modern UI and a scriptable CLI that both use libalpm, which is unique among the options.

Maintenance and License Implications

The project is licensed under GPL-3.0, which means any derivative works must also be open-sourced under the same license. This is a standard choice for Linux tools, but it has implications if you plan to integrate Shelly into a proprietary product. The repository is not archived, and the last push was on August 26, 2026, which suggests active development. The release cadence is fairly frequent, with three releases in August 2026 alone, indicating that bug fixes and features are being shipped regularly. However, the development branch being the default means that users who build from source may encounter unstable code. The maintenance cost for users is moderate: you will need to keep up with releases and possibly rebuild from source if you want the latest features. The project's modular structure means that updates to the Flatpak backend may require updating the base package as well. The documentation for the Flatpak backend ABI is provided, which helps with upgrades, but it is an extra thing to track. The use of Zig 0.16.0 is a specific version, so if the project moves to a newer Zig version, you will need to update your toolchain. Overall, Shelly is a project with a clear direction, but it is not yet a set-and-forget solution.

Editorial conclusion

Shelly-ALPM is for Arch users who want a visual package manager that stays close to libalpm and is willing to accept a young project. It is not for those who need stable, battle-tested tooling or who require full repository modification, which is still in progress. Before adopting, verify that the CLI and UI cover your common workflows, check that the Flatpak backend separation works with your system, and review the GPL-3.0 license for any distribution plans. The project's reliance on Zig 0.16.0 and its development branch status mean you should expect breaking changes and be prepared to build from source.

Official sources

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