Nitrux is a distribution that doesn’t revolve around a package manager like other distributions; in Nitrux, the preferred method of obtaining new software is using AppImages. However, we understand that not all software is available as an AppImage. So, by default, we have included various options for users, such as Flatpak and Distrobox, to complement AppImages.
Additionally, Nitrux is an immutable distribution (the root is immutable by default), with the idea being that by making the root immutable, we provide users with a functional system that will not break over an update from a delivery channel we can’t control and that each upgrade to a new version occurs without anomalies, what we call “to have degree of certainty.” In fact, in Nitrux, there is no package manager because, of course, having one that can alter the root wholly defeats the purpose.
Having laid out the context, today’s tutorial will look at how users can manage software in Nitrux.
Difficulty: ★☆☆☆☆
📜 Table of Contents
AppBox
NX AppHub forms the foundation of Nitrux’s user-level software management system, with a reproducible, declarative, and rootless model designed specifically for Nitrux’s immutable architecture, built around AppBoxes—our vision of modern, smaller, faster, Nitrux-first AppImages.
- NX AppHub CLI builds AppBoxes using curated YAML specs from a Git-based repository—the user does not manually assemble them.
- 🔰 Information: We have planned a GUI for NX AppHub.
- NX AppHub CLI builds AppBoxes using prebuilt packages (e.g., Debian packages), not from source code. They are assembled by extracting and staging trusted package files into an AppDir.
- AppBoxes do not embed AppImageUpdate metadata—they don’t support AppImageUpdate because we don’t embed update URLs in the files, and we don’t serve or fetch binaries from a web host. Instead, updates are handled explicitly by the CLI because we believe users benefit more from predictable updates through the CLI than from per-file embedded metadata.
- AppBoxes are guaranteed to work on Nitrux and with Nitrux’s app lifecycle management—they’re tracked and managed consistently via the CLI.
- AppBoxes use either Firejail, Firejail with AppArmor, or Bubblewrap.
- AppBoxes use a FUSE 3 runtime in their YAML definitions.
- AppBoxes are automatically integrated into the desktop by the NX AppHub Daemon.

NX AppHub CLI, a lightweight command-line tool for managing and building applications in Nitrux.
AppImage
An AppImage is a downloadable Linux file that contains an application and everything it needs to run (e.g., libraries, icons, fonts, translations), which you can’t expect to be available on every target system. AppImage provides a very simple solution for software distribution. Nitrux uses the directory ~/Applications to organize AppImages.
- 🔰 Information: Users can install Bauh from the applications menu.
- 🔰 Information: Since Nitrux 5.0.0, applications available as AppImages are not integrated into the desktop anymore because Nitrux no longer includes appimaged. Users can download appimaged from their repository.

Bauh can manage both AppImage and Flatpak. Image for reference.
Flatpak
Flatpak builds upon existing technologies such as CGroups, namespaces, bind mounts, and seccomp in the Linux kernel, OSTree from Project Atomic, and the OCI format developed by the Open Container Initiative.
- Nitrux also supports Flatpak.
- ⚠️ Important: Users who want to use bleeding-edge Flatpaks can enable the Flathub-beta channel. Do it at your own risk.
flatpak remote-add --user flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
- 🔰 Information: To manage Flatpaks using a graphical application, we recommend that users install either Plasma Discover or GNOME Software on Distrobox; see Managing Flatpaks in the Host using a Container.

Plasma Discover in Distrobox (Arch Linux container). Image for reference.
- Users can install Bauh from the applications menu.

Bauh (is not included by default). Image for reference.
Flatpak Runtime Information
Below is the information we deem essential for users to know about Flatpak runtimes.
- 🔰 Information: Due to Flatpak’s design, most applications automatically install a runtime containing graphics libraries, like MESA or, for NVIDIA hardware, the NVIDIA proprietary driver runtimes; therefore, Flatpak applications will not use the system libraries. This problem is not a bug in Nitrux or caused by Nitrux.
- 🔰 Information: For the NVIDIA proprietary driver runtimes that Flatpak installs, the runtimes must match the driver version installed in the system. For example, if the installed driver is version 560.35.03, then the Flatpak runtimes should look like this when listing all Flatpaks using the command
flatpak list. Otherwise, applications requiring 3D acceleration will stop working entirely. This problem is not a bug in Nitrux or caused by Nitrux.
nvidia-560-35-03 org.freedesktop.Platform.GL.nvidia-560-35-03 1.4 user nvidia-560-35-03 org.freedesktop.Platform.GL32.nvidia-560-35-03 1.4 user
- 🔰 Information: Installing other NVIDIA proprietary driver runtimes not mentioned will prevent applications that require 3D acceleration from working. This problem is not a bug in Nitrux or caused by Nitrux.
- 🔰 Information: Flatpak does not automatically remove older NVIDIA proprietary driver runtime versions. This problem is not a bug in Nitrux or caused by Nitrux.
- 🔰 Information: We recommend rebooting after upgrading the MESA or NVIDIA proprietary driver runtimes, as we’ve observed that applications requiring 3D acceleration won’t work; logging out and in is not enough. Additionally, developers must update applications like MangoHud to use the newer runtimes before working again. This problem is not a bug in Nitrux or caused by Nitrux.
- 🔰 Information: Flatpak, like other package managers, uses a dependency-based design. When an application is updated and the new version requires an updated base runtime or SDK, the exact version may be available alongside the application. In this case, users must manually install these new versions. This problem is not a bug in Nitrux or caused by Nitrux.
Disclaimer: We do not develop Bauh or Flatpak. To report bugs about Flatpak, create an issue at their bug tracker, and to report bugs about Bauh, create an issue at their bug tracker.
Distrobox
⚠️ Important: Please note that starting from version 2.6.0 to use a package manager users should use Distrobox.
Distrobox is based on an OCI image and implements concepts similar to ToolBox, built on top of Podman and OCI standard container technologies. As the project describes, “Simply put it’s a fancy wrapper around podman, docker, or lilipod to create and start containers highly integrated with the hosts.”
- 🔰 Information: If the user needs to use dpkg/APT (or any package manager), we strongly recommend using Distrobox; check our tutorial.

neofetch on a Distrobox container.
Compiling Software in Nitrux
We strongly recommend that users use containers to compile software. Users can create a container using the following tools.
- Distrobox (our recommendation).
- 🔰 Information: Distrobox uses Podman by default. However, Distrobox can also use Docker.
Disclaimer: We do not develop Distrobox. To report bugs about Distrobox, create an issue at their bug tracker.
Support for Other Self-Contained Formats
In addition to AppImage and Flatpak, other types of self-contained formats exist, such as Snaps.
- Snap is a software packaging and deployment system developed by Canonical for Linux and the Systemd software suite (which includes an init).
- ⚠️ Important: Nitrux does not support Snaps as its daemon (snapd) requires systemd.
Another more popular option is undoubtedly static binaries or static builds.
- A static binary is an executable program compiled and linked with all its dependencies statically. In contrast to dynamic binaries, which rely on shared libraries (also known as dynamic link libraries) at runtime, static binaries include all the necessary libraries and code within the binary itself. A static binary can run on a system without requiring any external dependencies.
This description could make static binaries sound similar to AppImages. Both offer portability and independence from external libraries, but the crucial difference lies in their packaging and distribution approaches. Static binaries are single executable files, whereas AppImages are a specific packaging format for bundling applications and dependencies.
- 🔰 Information: Below is a list of GitHub repositories containing static binaries.
- https://github.com/andrew-d/static-binaries – Various *nix tools built as statically-linked binaries.
- https://github.com/polaco1782/linux-static-binaries – A collection of multiple binaries compiled for ARM, x86, and x86_64.
- https://github.com/Azathothas/Static-Binaries – Cross-Compiled Statically Linked Binaries for Android, Linux, macOS, Windows & More.
Disclaimer: We do not develop or maintain the static binaries provided in these repositories. Their content is the responsibility of their maintainers.
Support for Other Software Installation Methods
As we can see, there are multiple ways to add software to Nitrux. With the options above, there’s no shortage of software to install and use. Below, you can find information on other methods for obtaining software.
Homebrew
As we indicated at the beginning of this tutorial, Nitrux is a distribution that doesn’t revolve around a package manager like other distributions; however, besides using Distrobox, users can use package managers in a non-containerized way in Nitrux. The critical difference is that these package managers do not alter the root directory; they store their content in the home directory. Additionally, in the case of Homebrew, the software is provided by its community of users, as the famed AUR does for Arch Linux users, rather than the distribution through software repositories, i.e., what we used to do before Nitrux 2.6.0.
Below are two recommendations for these package managers.
- Homebrew is a macOS package manager that works on Linux and allows users to install software in their home directory. Homebrew features are the following:
- Homebrew can install software to your home directory, so it does not require sudo.
- 🔰 Information: A package in Homebrew is called a formula; you can find the list of available formulas here.
- To install Homebrew for Linux in Nitrux, run the following command.
- Homebrew can install software to your home directory, so it does not require sudo.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
-
- After downloading and executing the install script, run the following commands to add Homebrew (brew) to your $PATH.
(echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/$USER/.zprofile && eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" && echo -e "\n# Alias for Homwbrew\nalias brew='\/home/linuxbrew/.linuxbrew/bin/brew'\n" >> ~/.zshrc && source ~/.zshrc
-
- For help, run the following command,
brew --help- ⚠️ Important: At the time of writing, graphical software is not available in Homebrew for Linux.
- For help, run the following command,

Homebrew in Nitrux. Image for reference.
Nix Package Manager (Portable)
- Nix Package Manager (Portable)
- To install Nix (Portable) in Nitrux, do the following. The command will download the binary to the
$HOMEand create an alias.- 🔰 Information: Please refer to Nix’s documentation to learn how to use it.
- To install Nix (Portable) in Nitrux, do the following. The command will download the binary to the
axel -o $HOME/.local/bin/nix https://github.com/DavHau/nix-portable/releases/download/v010/nix-portable && chmod +x $HOME/.local/bin/nix && echo -e "\n# Alias for Nix\nalias nix='\$HOME/.local/bin/nix'\n" >> ~/.zshrc && source ~/.zshrc
-
- For help, run the following command:
nix --help
- For help, run the following command:

Nix portable in Nitrux. Image for reference.
Disclaimer: Nitrux does not develop or maintain Homebrew for Linux, Nix, or Nix (Portable).
Installers for Linux
However, that’s not all; as we can see below, there are similar experiences to managing software in Windows but targeting Linux.
- Linux (application) Installers. Some developers use installers rather than distributing their software through AppImages, Flatpaks, or Snaps—yes, installers exist in Linux.
- Like the ones used by Oracle and VMware to distribute their hypervisors, in practice, there’s no difference between these installers other than their file extensions. Both installers install software via a script through the terminal rather than a graphical package manager.
- <🔰Information: Check our tutorial to see how to install them.
- Graphical installers also exist; an example of a graphical installer for Linux is the linux-installer software, a graphical framework to create installers using GTK 3 and CSS for the GUI that imitates the look-and-feel of install wizards commonly used in Windows, specifically the NSIS (Nullsoft Scriptable Installable Software) Wizard software.
- Like the ones used by Oracle and VMware to distribute their hypervisors, in practice, there’s no difference between these installers other than their file extensions. Both installers install software via a script through the terminal rather than a graphical package manager.

Example of linux-installer. Image for reference.
That’s it; this concludes today’s tutorial.