Over the past month, we’ve cleaned up the distribution, removing zap, an unmaintained CLI package management interface for AppImages, and the NX Software Center, our GUI for managing AppImages, which leaves the door open to better tools in the distribution.
We’re excited to introduce NX AppHub, a system for providing applications for Nitrux, including the CLI component, its central repository, and its integration daemon.
Today’s news post explains how NX AppHub got started, why we created it, and where you can get it. Let’s go!
Background
The history of NX AppHub goes back to January 2024, when we announced an initiative we started called NX AppImage Build Hub. In this initiative, we set out to fork the repositories that were part of the defunct AppRepo.de—a website that provided hundreds of AppImages with their build scripts hosted on GitHub—and then complete the original goal of their creator, of building the AppImages using GitHub Actions while also uploading these AppImages to another third-party website, and the only source that the NX Software Center used to fetch AppImages, AppImageHub.com.
As I mentioned in that entry, the idea was to provide the AppImages ourselves and keep our application up to date. A major issue users had with the NX Software Center was the reliability of the applications that we did not provide. They were often outdated or didn’t work, and in general, many people mistrust AppImages because “You downloaded from a random website.”
We intended to finalize this work by October 2024, in time to present it at the Linux App Summit, held in Monterrey, Mexico, which would be the best opportunity to showcase this effort. Alas, a couple of months later, we could not continue working on this endeavor due to a workforce shortage.
Nonetheless, this setback was an opportunity in disguise to develop a better solution. So, on the 24th of September, 2024, work started on NX Applications Hub, the original name of the initial implementation of NX AppHub, which was announced and presented on the 5th of October, 2024, during the Linux App Summit 2024. You can watch it below.
This implementation was based on our tutorial, Making an AppImage in Nitrux, which shows how to use appimage-builder and a Distrobox container to create an AppImage. So, I created NX Applications Hub as a fully automated version of that tutorial.
In summary, using Distrobox containers and appimage-builder, NX Applications Hub allowed application generation locally without relying on external CI configurations.
However, this implementation, while functional, proved too complex.
After a round of introspection, I found a couple of showstoppers with appimage-builder: first, that it was unmaintained, and second, that it couldn’t produce an AppImage from packages that had implemented Usrmerge, so any AppImage would’ve been made from software that was “stable” but inherently too old because it only pulled packages from Debian stable.
The choice was evident to me: appimage-builder would not serve our purposes. And, as fine as they are on their own, including the containers, they increasingly felt like overkill for the process we wanted to achieve. A few months later, after working on other recently presented projects, it was time to return to the NX Applications Hub.
But not until I watched some videos by other people using the distribution did I learn that the API endpoint on AppImageHub.com that the NX Software Center had been using for a very long time had stopped working, which caused severe problems with our application and a negative user experience for those who tried the distribution and opened the application.
That was the second occurrence for us, with AppRepo shutting down being the first, causing the same perception issues. The NX Software Center’s lack of maintenance certainly didn’t help. Although it was working, it lagged behind other MauiKit applications. All this led me to decide it had been enough. I did a hard reset with NX Applications Hub, with the first order of the day being to shorten the name.
The goal was clear: it needed to be easy to make and maintain, minimal, focused, and purpose-built, and not rely on any third-party API to provide applications.
As I mentioned, NX AppHub is a system, not a single utility. It comprises the following components, which we’ll discuss in detail below.
- NX AppHub CLI
- NX AppHub Apps
- NX AppHub Daemon
- NX AppHub GUI
- ⚠️ Important: Built with MauiKit. Placeholder name. Work in progress.
NX AppHub takes inspiration from appimage-builder, deb2appimage, zap, and appimaged.
You’ll find that NX AppHub is the sum of these parts; it does the same job, only better, cleaner, and more aligned with our goals for a package-manager-free OS.
The utility and its curated app definitions are under a 100% FOSS license (BSD 3-Clause). PRs are welcome.
NX AppHub (CLI)
https://github.com/Nitrux/nx-apphub

NX AppHub (CLI), a fast, minimal, and purpose-built command-line tool to build and manage applications in Nitrux.
NX AppHub CLI (a.k.a. nx-apphub-cli) is a tool for:
- Building AppBoxes from curated YAML recipes.
- Installing, removing, updating, and downgrading applications. No root is required.
- Search for applications from a central Git-based app specification repository.
- Generating YAML templates and Markdown descriptions from repository metadata.
What’s an AppBox?
AppBoxes share common traits with the AppImage format, such as an AppDir structure and an AppRun execution entry point. However, they follow different structural rules:
- It is guaranteed to work in Nitrux and is built from pre-built Debian packages, not from source code, using a curated YAML file from the central Git-based repository.
- It is managed via the command-line tool, not manually downloaded.
- It doesn’t embed AppImageUpdate metadata (the CLI manages updates and downgrades).
- It uses sandboxing by default, using either Firejail, Firejail+AppArmor, or Bubblewrap.
- It uses a FUSE 3 runtime in its YAML definition.
AppBoxes give us a predictable, reproducible way to manage apps, without compromising our no-package-manager philosophy.
Please read the NX AppHub CLI wiki page, which includes further clarifications, the YAML specification to create AppBoxes, and other useful information.
NX AppHub Apps
https://github.com/Nitrux/nx-apphub-apps

NX AppHub Apps is a central, Git-based repository of app specifications that the NX AppHub CLI uses to generate AppBoxes.
- Users are encouraged to contribute to this repository. To contribute new applications, read the Contribution Workflow Guidelines.
- No .deb or AppImage files are stored in Git — the CLI builds them locally.
NX AppHub Daemon
https://github.com/Nitrux/nx-apphubd
NX AppHub Daemon integrates AppBoxes generated with NX AppHub CLI with the desktop. Eventually, it will replace appimaged in Nitrux since AppBoxes will replace AppImages in our workflow.
- It focuses on AppBoxes, not externally obtained AppImages or manually built AppImages.
- It doesn’t require root or an OpenRC service either.
Requirements
- Nitrux 4.0.0 and newer.
- 🔰 Information: To use
nx-apphub-cliandnx-apphubdIn previous versions of Nitrux, use a container.
- 🔰 Information: To use
- Python 3.10 and newer.
NX AppHub CLI and NX AppHub Daemon require the following utilities to function properly:
appstream binutils file fuse3 git libfuse2t64 patchelf zstd
Installation
To install NX AppHub CLI, we recommend using pipx.
- Single-user
pipx install git+https://github.com/Nitrux/nx-apphub.git
- System-wide
pipx install --system-site-packages git+https://github.com/Nitrux/nx-apphub.git
To install NX AppHub Daemon, we recommend using pipx.
- Single-user
pipx install git+https://github.com/Nitrux/nx-apphubd.git
- System-wide
pipx install --system-site-packages git+https://github.com/Nitrux/nx-apphubd.git
Usage
To use NX AppHub CLI, check the commands below.
install→ Install one or more applications.remove→ Remove one or more installed applications.update→ Update one or more installed applications.downgrade→ Downgrade one or more installed applications.search→ Search for specific applications.show→ Show installed applications.build→ Build an AppImage from a local YAML file.--appdir-lint→ It optionally debugs missing shared libraries in an AppImage.
generate→ Generate YAML template from package metadata.--package→ Specify the package name.--distro→ Choose the distribution from which to get metadata.--release→ The release of the selected distribution.--arch→ Specify the target architecture.--output→ The file name of the generated YAML file.--description-output→ The file name of the generated metadata file.
To use the NX AppHub Daemon, simply run it.