Overview

This FAQ covers naming, usage quirks, and common points of confusion.

1. Do the YAML files in this repository prioritize Nitrux?

Yes. The curated YAML files in this repository create reproducible, sandboxed bundles, i.e., AppBoxes (Nitrux-native application bundles).

These AppBoxes are guaranteed to work in Nitrux but are not guaranteed to work in other Linux distributions.

While we may test these files in other environments (e.g., via Distrobox containers), doing so is optional and purely for formality.

2. Is the goal of NX AppHub Apps to provide AppImages for all Linux users?

No. NX AppHub Apps is not a universal AppImage distribution service.

This project aims to provide AppBoxes (Nitrux-native application bundles) using curated YAML definitions. Compatibility with other distributions is incidental, not intentional.

Supporting every Linux distribution is outside this project's scope.

3. Can I contribute a YAML file that also targets other distributions?

Yes, but with strict conditions.

You may include additional libraries or configurations to improve portability, provided the build remains Nitrux-native.

• Allowed: Bundling extra dependencies that might be missing on other distros (e.g., specific library versions), provided they don't conflict with Nitrux.
• Not Allowed: Downgrading the build base (e.g., using ubuntu:focal or debian:oldstable) to achieve "Universal AppImage" status.

As stated in NX AppHub → Are AppBoxes the same as AppImages? and NX AppHub → Do AppBoxes work on other Linux distributions?, universality is not a goal. We accept incidental portability improvements, but we will reject any contribution that sacrifices the modern Nitrux stack (glibc version, compiler flags, etc.) to appease older distributions.

4. Why don't YAML files just download existing AppImages or other portable binaries from upstream developers or third parties?

We don't do that because that's not the goal of NX AppHub Apps.

This repository provides YAML build definitions that assemble AppBoxes by staging .deb packages into clean, reproducible AppDirs.

Existing AppImages and other portable programs (e.g., tarballs, with static or bundled binaries) are often built from source code by their developers/maintainers/packagers; for obvious reasons, we do not know their build processes. Additionally, these files do not prioritize Nitrux.

By contrast, AppBoxes are:

• Built consistently from known prebuilt .deb packages.
• Guaranteed to work in Nitrux because they target the stack in the distribution.
• Fully transparent in their build process and their provenance.
• Fully reproducible via nx-apphub-cli using declarative YAML.

You aren't trusting a black box; you are using a recipe to manufacture a trusted artifact on your own machine.

5. How is NX AppHub Apps different from other AppImage stores, catalogs, or other App Stores?

NX AppHub Apps is neither a commercial "App Store" nor a graphical "Software Center."

It is strictly a version-controlled repository of build instructions (YAML).

• It is not a Store: There is no payment infrastructure, no user accounts, and no proprietary licensing mechanism.
• It is not a Software Center: It acts as a library of recipes, not a catalog of products. Unlike a Software Center that serves prebuilt binaries for immediate download, this repository provides the raw specifications the CLI uses to build applications locally.
• It is not a Link Aggregator: It does not simply list URLs to external binaries (like GitHub Releases or developer websites). It hosts the actual source definitions (YAML) used to build the software, ensuring the application's source is the repository itself, not a third-party link.

NX AppHub Apps enable users to build the application from trusted upstream Debian-based repositories.

This approach removes:

• The need to trust an unknown third party to build and host binaries
• The maintenance burden of hosting, mirroring, or snapshotting large binary archives
• The risk of binaries becoming outdated, broken, or compromised without user visibility