FAQ - Nitrux/nx-apphub GitHub Wiki

Overview

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

1. Why are the files called AppBoxes?

We use "AppBox" as a policy label, not as a generic synonym for "any AppImage-like file."

In this ecosystem, AppBox means a managed, curated bundle. Manually built files, renamed third-party AppImages, or bundles outside the curated policy are not treated as AppBoxes.

Operationally, in the NX AppHub ecosystem, a file is considered an AppBox only when all of the following are true:

It is built from a curated YAML definition in NX AppHub Apps.
That YAML targets the same Nitrux packaging baseline (including the Debian/repository snapshot policy used for Nitrux builds), rather than an arbitrary downgrade baseline for cross-distro universality.
It uses trusted distribution repositories allowed by project policy (no third-party PPAs in curated definitions).
It follows the AppBox runtime/sandbox policy documented for curated submissions.

This operational checklist is the canonical AppBox definition used across NX AppHub documentation.

2. Are AppBoxes the same as AppImages?

Not exactly. An AppBox is an architectural policy that dictates how an application component interacts with a specific, immutable host system, i.e, as an extension of the Nitrux root filesystem.

AppBoxes use the AppImage format as a runtime and filesystem container (AppDir model). However, they intentionally do not follow the upstream portability-oriented best-practice profile (old-base build target, cross-distro universality, etc.).

Build model: assembled locally from curated YAML + trusted distro packages, not downloaded as opaque prebuilt binaries.
Update model: managed through nx-apphub-cli metadata/workflow, not AppImageUpdate embedded metadata.
Lifecycle model: treated as managed application artifacts in the NX AppHub ecosystem (install/update/remove/integration), not ad hoc standalone files.
Target model: optimized for the Nitrux baseline and policy goals, not for universal lowest-common-denominator portability.
- Curated YAML entries declare buildinfo.os-target, and nx-apphub-cli refuses install/update when host VERSION_ID does not match.

3. Do AppBoxes follow the official AppImage specification?

Not entirely. An AppBox does not aim to follow the AppImage specification—rather, AppBoxes use the AppImage format/container (runtime + filesystem/AppDir model), with functionality in Nitrux as the top priority; this reflects an important philosophical distinction.

While we respect the format, we don't adopt the AppImage project's best practices as strict requirements. Instead, we take a pragmatic approach: ensuring that AppBoxes work in Nitrux and treating AppImage as a self-contained format, not a universal compatibility guarantee.

AppBoxes intentionally diverge from several of the upstream suggestions, including:

Not targeting ancient baseline Linux distributions—we prioritize Nitrux, which already includes modern shared libraries.

Our goal in Nitrux is reliability and integration, not adherence to cross-distro compatibility heuristics. We believe AppImage is a flexible format and use it in a way that best serves our Linux distribution—even if that diverges from upstream guidance.

4. Do AppBoxes work on other Linux distributions?

Not necessarily. While AppBoxes use the portable AppImage format, the binary packages rely on Nitrux system libraries (including modern glibc). They are not guaranteed or intended to run on other distributions, particularly those with older base systems.

The YAML files in the curated apps repository generate AppBoxes; files specifically designed and tested for Nitrux. Curated entries also declare a target Nitrux version, and the CLI blocks installation when the host version does not match that target.

However, nothing about NX AppHub CLI "locks" them to Nitrux and prevents them from working elsewhere, except for old Linux distributions or distributions not using the GNU C Library; see 3. Do AppBoxes follow the official AppImage specification? and 18. Does NX AppHub CLI handle C library compatibility?.

The goal is reliability and integration within Nitrux, not portability as a universal rule. An AppBox is a clean "overlay" that fills the gaps, rather than a "kitchen sink" that duplicates the OS.

"If it 'uses' the portable AppImage format, then it can be made portable, right?"

Potentially. Ensuring portability requires additional testing steps using other target Linux distributions; see 6.1 Ensuring AppDir Portability.

However, custom application bundles are not, by definition, AppBoxes. For NX AppHub CLI to manage an app, contribute its YAML to the NX AppHub Apps repository (note that contributions must target the Nitrux stack, not older distributions); see NX AppHub Apps → Contribution Workflow Guidelines.

"If it uses the format and I take it to Ubuntu or Fedora, it crashes because it doesn't bundle everything. Isn't it just a 'bad' or 'broken' AppImage?"

No. It is a specialized AppBox.

From the perspective of the traditional "Universal AppImage" philosophy, which prioritizes running anywhere at the cost of file size and redundancy, an AppBox might seem "incomplete."

However, we designed AppBoxes with a different priority: Nitrux.

Universal AppImages: Prioritizes portability over efficiency. It bundles redundant libraries to ensure it runs on the oldest possible Linux base.
AppBoxes: Prioritizes efficiency over portability. It bundles only what is uniquely required, relying on the targeted Nitrux library stack to stay small, fast, and secure.

[!IMPORTANT] An AppBox failing to run on other Linux distributions isn't a defect; it is a consequence of its specialized design.

For evident reasons, we cannot know or guarantee the content of the root directory of other Linux distributions; thus, other Linux distributions are likely not to include the same files in their root.

Since Nitrux provides a specific set of system libraries, AppBoxes rely on them rather than bundling redundant or older copies; you know exactly what is inside the box because your system built it using only the components Nitrux was missing.

Therefore, while the file uses the AppImage format, it is structurally a Nitrux-native application bundle (AppBox) and may not work on other distributions that lack this specific library baseline.

5. Can I rename an AppImage to look like an AppBox?

Technically, yes, but we strongly advise against it.

Renaming an unrelated AppImage to match the AppBox naming format (e.g., xemu.AppImage → xemu.AppBox) and placing it in the AppBox directory may cause it to appear as an installed AppBox. However, it remains a standard AppImage and lacks the specific metadata and internal structure required by Nitrux.

The CLI will be unable to update the file (there's no associated YAML).
The daemon may attempt to integrate it, but it bypasses the intended curation and reproducibility model.

[!WARNING] This behavior is not supported in the workflow, and it is not guaranteed to remain usable. We discourage it.

6. Where are AppBoxes stored?

We install AppBoxes to:

~/.local/bin/nx-apphub/

This location keeps them isolated from system packages and other AppImage tools.

7. Why does NX AppHub CLI specifically target Nitrux?

NX AppHub CLI is designed for and tightly integrated with the Nitrux ecosystem. It builds files using metadata tailored to the structure, environment, and tools available in Nitrux.

Including:

Nitrux-specific filesystem layout (e.g., paths, immutable root, philosophy, etc.)
Assumptions about runtime compatibility, packaging tools, and sandboxing behavior.

8. Can I use NX AppHub CLI on other Linux distributions?

You can try—but it's not guaranteed to work elsewhere. Support and compatibility are only guaranteed on Nitrux, as indicated in 3. What isn't NX AppHub CLI?. We don't aim for NX AppHub CLI to be a cross-distro utility.

9. Does NX AppHub CLI only generate YAML files that create AppBoxes?

Technically, no. NX AppHub CLI will create a template YAML file using the command generate. The user is responsible for replacing placeholder values, including their dependencies and environment variables, and for creating workarounds as needed.

NX AppHub CLI does not determine whether a YAML file produces a file that works only in Nitrux.

It's up to the user to further test the resulting file in other Linux distributions to ensure its portability, as mentioned in 4. Do AppBoxes work on other Linux distributions?.

Nonetheless, the YAML files in NX AppHub Apps prioritize Nitrux and produce an AppBox.

In short: every AppBox is an AppImage-format bundle, but not every AppImage-format bundle built with NX AppHub CLI is an AppBox. In this documentation, we reserve “AppBox” for bundles that target the Nitrux stack and come from curated YAML definitions in the NX AppHub Apps repository.

10. Aren't AppBoxes just Debian packages repackaged as "AppImages"?

No. Think of AppBoxes as a declarative evolution of the package. AppBoxes use Debian packages purely as raw materials (trusted binaries), but the resulting file behaves fundamentally differently. We strip away the legacy requirements of dpkg (root access, system mutation) and repackage the binaries into a modern, immutable Nitrux-native bundle.

AppBoxes repurpose the binary packages and stage them into a self-contained AppDir that aligns with Nitrux's design principles: immutability, minimalism, and user-level application management.

Debian packages are for systems with a mutable root, tight integration with dpkg and APT, and system-wide installations. AppBoxes, on the other hand, assume none of that, shifting the paradigm from system-wide package management to user-level application portability.

"If you use .deb packages, doesn't that make you just Debian with extra steps?"

No, and this is a fundamental misunderstanding of what Nitrux and NX AppHub CLI are doing.

At a superficial level, AppBoxes uses Debian packages as a source for prebuilt application binaries.

But we do not:

Install .deb packages with dpkg or APT, or
Assume a mutable root filesystem, or
Use system-wide dependency resolution, or
Treat them as system packages.

Instead, we:

Extract them, stage their binaries manually, and bundle them inside a self-contained AppBox.
Declaratively manage application state through YAML configuration, not through dpkg metadata.
Sandbox and isolate execution using Firejail or Bubblewrap.
Do not modify the base system to install or integrate applications.
Integrate applications per user, rootlessly and immutably.

In other words:

The source of the binaries (Debian, Ubuntu, Devuan, KDE Neon, and Nitrux) provides trusted, audited packages.
The management model (NX AppHub CLI and AppBoxes) breaks from Debian completely.

AppBoxes are not technically bound to the .deb format.

"Why not use RPMs, staged tarballs, or other packaging systems instead?"

The AppBox model could be adapted to support other packaging systems, such as .rpm, .apk, .eopkg, .xbps, and staged tarballs. What matters most is not the source format but the reproducible, auditable, and user-centric philosophy behind how applications are built and managed.

We deliberately chose Debian packages as our primary source to leverage the massive, audited supply chain of the Debian ecosystem (the package format, not the distribution exclusively). This strategy allows us to focus on the management model (AppHub) rather than wasting resources on repackaging binaries that already work perfectly.

It's not a technical limitation—it's a strategic decision focused on consistency, simplicity, and tight integration with the distribution we build and maintain.

11. Will NX AppHub CLI manage my existing AppImages?

No. NX AppHub CLI only manages AppBoxes.

The CLI does not track, update, or integrate existing AppImages downloaded from websites or built manually. Although they may still run on Nitrux, they fall outside the scope of the NX AppHub CLI.

If you'd like NX AppHub CLI to manage an application, you must create a YAML file that builds it as an AppBox for Nitrux and contribute it to the curated apps repository.

12. Will my existing AppImages conflict with AppBoxes?

No. Existing AppImages will continue to work on Nitrux, and you can run them manually. NX AppHub CLI and its integration daemon, NX AppHub Daemon, do not interfere with external AppImages.

You can still use external AppImages in Nitrux, but they won't be managed or integrated by default.

[!NOTE] Nitrux no longer includes the standard (though optional) AppImage integration daemon, appimaged, by default.

13. Does NX AppHub CLI download existing AppImages from sources other than the NX AppHub, such as the developer's website or GitHub Releases?

No. NX AppHub CLI does not fetch AppImages from external sources. It doesn't download binaries, it builds them.

NX AppHub CLI uses YAML definitions to stage .deb packages into an AppDir. The result is a structured, predictable file tailored for Nitrux, not a wrapper around third-party binaries.

While NX AppHub CLI supports running commands through apprunconf.prebuild-commands, this feature is intended for configuration steps, not for downloading standalone binaries.

Attempting to build an AppImage by downloading a portable binary unnecessarily complicates the process, requiring manual staging of missing files and libraries, environment adjustments, and integrations that NX AppHub CLI normally handles automatically.

Following the intended workflow: building an AppDir from distribution packages ensures simplicity, reliability, and full integration with the Nitrux system environment.

14. Do AppBoxes support sandboxing?

Yes. When creating a YAML for an AppBox, users can optionally sandbox the application by declaring a sandbox policy in the YAML definition.

AppImages do not include an inherent sandbox policy by default; sandboxing is usually added externally (for example, by running them via Firejail or Bubblewrap).
AppBoxes, by contrast, declare a sandbox policy (e.g., Firejail or Bubblewrap) during the build process. When launched, the resulting AppBox runs in that configured sandbox mode.

Which means sandboxing is declarative, but with one major difference:

[!NOTE] AppBoxes do not rely on a centralized runtime or background daemon to enforce sandboxing.

Whether an AppBox uses sandboxing depends on the YAML definition and target system capabilities:

Sandbox selection is declarative via sandbox.type (none, bwrap, or firejail).
firejail is supported only with integration.type: cli.
bwrap can be used with integration.type: cli and integration.type: gui.
integration.type: wm must use sandbox.type: none.
On other distributions, custom bundles use sandboxing if the selected sandbox tool is available in the system path.

To enable sandboxing, define a sandbox: section in the YAML file; see 1.1.4 Sandbox Configuration for more details.

While defining sandbox.type in the YAML file is optional for personal use, submissions to the curated apps repository must include sandbox support.

[!IMPORTANT] Window manager entries are a special case and should use sandbox.type: none due to deeper integration with display servers and D-Bus.

15. Why NX AppHub CLI is not a general AppImage manager

NX AppHub CLI is not an AppImage manager. Unlike tools focused on downloading and launching prebuilt AppImages, it specializes in building and managing AppBoxes as declaratively defined builds.

Traditional AppImages do not require a package-management interface, but NX AppHub CLI introduces one intentionally for AppBoxes to provide a structured and predictable workflow in the Nitrux context.

AppBoxes are built locally from curated YAML definitions and distribution repositories, then integrated and managed through NX AppHub CLI.

For example, to clarify how this differs from other general-purpose tools such as the independent community-developed "AM" Application Manager by ivan-hc and Zap by srevinsaju, here's a side-by-side comparison:

15.1 Comparison: NX AppHub CLI vs Zap vs AM / AppMan

Feature	NX AppHub CLI	Zap	AM / AppMan
Purpose	Build and manage curated AppBoxes (Nitrux-scoped AppImage-format bundles)	Manage AppImages	Manage AppImages and portable binaries (e.g., tarballs, static builds)
Application Source	YAML-defined builds from NX AppHub Apps	AppImages from AppImage Catalog and AppImage catalog v2, direct-link URLs or GitHub Releases artifacts, and local files	Shell scripts from AM database fetching upstream or third-party AppImages or portable binaries
AppImage Strategy	Locally built from staged `.deb` packages	Downloaded as-is from upstream developers or GitHub Releases artifacts or local files	Downloaded as-is from upstream developers or GitHub Releases artifacts
Package Philosophy	AppBoxes: Nitrux-targeted, policy-curated, and managed via NX AppHub	Prebuilt upstream AppImages (typically broad-compatibility oriented) as convenient binaries for any Linux distribution	Prebuilt upstream AppImages (typically broad-compatibility oriented) and portable binaries as convenient binaries for any Linux distribution
Installation Model	Standardized local user installation path; Desktop integration via NX AppHub Daemon	Customizable local user installation path; built-in integration method via internal logic in `zap`	Customizable local user installation path or system-wide installation path; may invoke `sudo`; Desktop integration via internal logic in AM/AppMan
Build Reproducibility	Fully rebuildable AppBoxes via YAML spec; AppDir linter, YAML template, and metadata generation capabilities	None built-in; uses prebuilt AppImages	None built-in; uses prebuilt AppImages and portable binaries
Sandboxing	Declarative: Firejail (+ optional AppArmor) or Bubblewrap, defined per build; Optional for personal use but required for NX AppHub Apps	None built-in	Optional: via aisap (Bubblewrap profiles) for AppImages
Update Mechanism	CLI-managed updates (no AppImageUpdate metadata required) using YAML definitions; Local backups are created during the update process	AppImageUpdate metadata compatible via `zapd`; AppImages are downloaded from the available source in its internal database and replaced; No local backups are created during the update process	Script-driven via an AM/AppMan self-generated script called AM-Updater, uses AppImageUpdate or downloaded from the specified source in their install scripts and replaced; Local backups are created during the update process
Rollback Mechanism	CLI-managed downgrades (local backups); Local backups are restored during the downgrade process	None built-in	The user has to manually download the versioned AppImage from the specified source in their install scripts
System Scope	Nitrux-first; Support for other Linux distributions is not a priority	Any Linux distribution	Any Linux distribution
File Layout Consistency	Standardized AppDir layout, with FHS-aligned payload paths inherited from Debian packages	Can vary due to heterogeneous sources	Can vary due to heterogeneous sources
Extensibility	Users can contribute YAML specs to NX AppHub Apps or define local builds	Users can add local AppImages files manually via `zap`	Users can add install scripts to AM database or replace it with a custom repository
Design Focus	Minimal, purpose-built CLI tool to build and manage self-contained, sandboxed application files in Nitrux	Command-line package management interface and desktop integration functionality for AppImages	Command-line package management interface and desktop integration functionality for AppImages and portable binaries

NX AppHub CLI is part of a broader, modular system vertically integrated with the Nitrux workflow. Its role is specific: to build and manage AppBoxes.

By contrast, utilities such as AM/AppMan and Zap are general-purpose tools that aggregate and manage executables, including AppImages and other portable formats (e.g., tarballs, static or bundled binaries), sourced from upstream repositories or third-party GitHub repositories, primarily providing a package-management layer for these files.

TL;DR

The difference isn't just technical—it's architectural. NX AppHub CLI aims to redefine the management of self-contained apps in a Nitrux-first context. These tools are diametrically different in purpose and philosophy.

16. I heard AppImages are "insecure" and "badly maintained"? Wouldn't an AppBox inherit these defects?

Technically, no. By design, an AppBox would not inherit those perceived defects.

Regarding AppImages, as with any technical question, it depends.

This use case may apply depending on the source of the AppImage. While some upstream developers distribute their software via AppImages, third parties that distribute software in AppImage format may not have transparent build processes or may eventually stop maintaining the AppImage they build, which can lead to this perception.

In addition, generally speaking, since the files may not come from a centralized repository or an authoritative site, which is out of the norm for the traditional expectation of software acquisition in a Linux distribution, critics of AppImages consider this to be a contention point in favor of invalidating their proliferation.

It's not the format itself; the cultural design choice around it caused the trust issues.

AppBoxes resolve these concerns by changing the model: they are not binaries from unknown builders fetched from unknown sources. Instead, they are built locally on the user's system from trusted distribution repositories.

AppBoxes are not trying to repackage the entire system model of Debian-based distributions; see 10. Aren't AppBoxes just Debian packages repackaged as "AppImages"?. They use trusted building blocks (.deb)—but in a way that preserves freedom, separation, and immutability.

This approach preserves the user freedom envisioned by AppImage while restoring a strong, verifiable chain of trust.

With AppBox, we articulate a philosophically coherent position around AppBox's trust model, addressing one of the AppImage ecosystem's perceived "ironies":

One of the characteristics of the AppImage format is its emphasis on decentralization, as its creator strongly advocates. While this philosophy promotes freedom and flexibility, critics argue that it also weakens the traditional chain of trust, making provenance and maintenance harder to guarantee.

AppBoxes preserve the original spirit that makes AppImages compelling.

System	Philosophy
AppBoxes (via NX AppHub)	Locally built, auditable, reproducible applications
Trust	Comes from Debian/Ubuntu/Devuan/KDE Neon upstream, not intermediaries
Maintenance	Keep it light; no hosting, no mirroring headaches
Simplicity	Build it here, use it here. No middle layers
Updates	Driven by open YAML metadata, rebuilt locally
Security	No hidden binaries, no opaque build pipelines
Flexibility	Users can audit, modify, or extend the build definitions themselves

AppBoxes empower users to:

See what goes into their applications.
Build and rebuild applications on their systems.
Retain freedom and reproducibility without sacrificing simplicity.

By assembling applications locally from trusted distribution repositories (such as Debian, Ubuntu, Devuan, KDE Neon, and Nitrux), NX AppHub CLI ensures that Nitrux users inherit the strong trust models of existing Linux distributions.

At the same time, it reinforces Nitrux's ethos of root immutability and user-centric application management—giving users the flexibility and freedom that AppImages originally promised, but with stronger transparency and reproducibility.

17. Can I convert an existing AppImage into an AppBox?

No. AppBoxes can't be "repacked," "converted," or renamed from existing AppImages, as mentioned in 5. Can I rename an AppImage to look like an AppBox?.

We don't develop NX AppHub CLI with support for this in mind.

An AppBox differs from a traditional AppImage in both design and philosophy: it is built from scratch using staged Debian packages and a declarative YAML configuration. This design ensures that every AppBox is reproducible, auditable, and built from trusted sources.

Given that, we can't guarantee or validate the build processes of external AppImages, their bundled libraries, or any potential security risks.

An AppBox intentionally avoids this opacity by building locally, cleanly, and declaratively.

The correct way to address the need for an application to be managed by NX AppHub CLI is to create a YAML definition and contribute it to the NX AppHub Apps repository; see NX AppHub Apps → Contribution Workflow Guidelines; not by trying to game the system.

18. Does NX AppHub CLI handle C library compatibility?

No. NX AppHub CLI does not attempt to enforce or guarantee C library compatibility across different Linux distributions.

Unlike traditional AppImage practices that target the "lowest common denominator" (e.g., building for the oldest supported Ubuntu LTS release), we designed the NX AppHub ecosystem to ensure applications are built for the Nitrux stack.

AppBoxes target the C library and system environment provided in Nitrux (GNU C Library).
AppBoxes do not bundle alternative libc implementations like musl or older versions of glibc.
NX AppHub CLI does not enforce compatibility workarounds for other distributions, such as those using an older version of the GNU C Library than the version we use in Nitrux.

This non-universality is intentional.

As explained in NX AppHub Apps → FAQ → 2. Is the goal of NX AppHub Apps to provide AppImages for all Linux users?.

NX AppHub Apps is not a universal AppImage distribution service.

We focus on Nitrux because we know Nitrux: how it's built, its philosophy, and its usage model. AppBoxes are a solution for Nitrux, not a generic solution for other Linux distributions.

Additionally, by not attempting to solve cross-distro compatibility, NX AppHub CLI and AppBoxes maintain the following:

A simpler codebase that is easier to maintain.
A clearer, predictable system model without unpredictable behavior across unknown environments.
Freedom from overbearing complexity that inevitably arises when serving incompatible or diverging systems.

TL;DR

We designed the NX AppHub ecosystem to ensure Nitrux users have access to functional, trusted applications. An AppBox's ability to run on other Linux distributions is purely incidental; it is neither a priority nor a guarantee, and it is not part of the project goals.

It's essential to understand that creating an AppImage from pre-compiled packages is not recommended by AppImage developers—especially when developers compile software against a newer version of the GNU C Library.

Such an AppImage will not work on a distribution with an older version of the GNU C Library because the executable and its runtime libraries in the AppDir require symbols that are missing.

This reasoning is why the AppImage documentation recommends using the oldest supported version of a Linux distribution and compiling the software from source to maximize forward compatibility; see Reference AppImage documentation → Best practices → Binaries compiled on old enough base system.

The distributions often cited in the AppImage community for this purpose include:

CentOS 7
Debian (oldstable)
Ubuntu LTS (oldest still supported)
Red Hat (oldest still supported)

The AppImage developers' recommendation is to maximize compatibility, meaning AppImage is forward-compatible, which is part of what makes it "universal."

When using the build command in NX AppHub CLI, users can use a YAML to create a custom bundle that precisely targets these older distributions using packages compiled against older versions of the GNU C Library.

Nevertheless, YAML files that create such files aren't allowed in the NX AppHub Apps repository; therefore, by our definition, they don't create an AppBox.

19. Which CPU architectures does NX AppHub CLI support for building AppBoxes?

NX AppHub CLI currently targets x86_64 (amd64) and ARM64 (aarch64) architectures.

These choices reflect the primary target platforms for Nitrux systems and the most widely used general-purpose computing hardware today.

x86_64: Standard 64-bit PCs, laptops, and workstations.
ARM64: ARM-based devices using a 64-bit architecture (e.g., some ARM laptops, SBCs).

We do not plan to support 32-bit architectures (e.g., i386, armhf/armv7l, armel). However, we do not rule out supporting other 64-bit variants (e.g., RISC-V, ppc64le, s390x).

This focus ensures NX AppHub CLI and AppBoxes remain lean, maintainable, and focused on the architectures most relevant to Nitrux.

20. Which runtimes and compression formats do AppBoxes use?

NX AppHub CLI offers a selection of runtimes that use FUSE 2 or 3, with varying levels of compression during build. However, AppBoxes, per our definition, should not require FUSE 2; their YAML files should use a FUSE 3 runtime (either go or uruntime).

While AppImages traditionally use a FUSE 2 runtime (libfuse.so.2) for compatibility, the YAML definitions from NX AppHub Apps do not use the classic runtime.

[!WARNING] FUSE 2 is considered obsolete and unmaintained; some distributions no longer ship it by default; we recognize that users and distributions increasingly prefer FUSE 3. Nitrux continues to include FUSE 2 for compatibility purposes with external AppImages.

Adding support for the Go-based appimagetool and uruntime advances NX AppHub CLI without breaking compatibility with existing setups.

This approach provides:

A gradual migration path.
User flexibility.
Better alignment with future Linux distribution practices.

Nonetheless, since NX AppHub CLI allows users to choose between two build modes (FUSE 2 or FUSE 3), edit the buildinfo section to specify the runtime in the YAML file; see 1.1.1 Supported keys for buildinfo.

For context, here's a side-by-side comparison of how much space and startup time different runtimes provide by using the same Inkscape AppDir (314.0 MiB uncompressed) as an example:

20.1 Compression efficiency by runtime: FUSE 2/3+SquashFS vs FUSE 3+DwarFS

Format	Size	Reduction from AppDir	Compression Algorithm	Block Size	Startup Time	Startup Time vs Uncompressed AppDir
Uncompressed AppDir	314.0 MiB	—	—	—	00:01.03	—
FUSE 2 + SquashFS (`classic`)	91.16 MiB	↓ ~71%	Gzip	131072	00:01.56	+51% (slower)
FUSE 3 + SquashFS (`go`)	75.86 MiB	↓ ~76%	Zstd	1048576	00:01.61	+56% (slower)
FUSE 3 + DwarFS (`uruntime`)	61.93 MiB	↓ ~80%	Zstd	4194300	00:01.23	+19% (slower)

These results highlight the benefits of migrating away from FUSE 2 and, optionally, adopting DwarFS to improve the compression-to-startup-time ratio.

While compressed files introduce some startup overhead compared to running the application directly from an uncompressed AppDir, this tradeoff is intentional and beneficial.

Compression significantly reduces disk space usage, while the slight delay on first launch is generally outweighed by the convenience, reproducibility, and efficiency—especially on systems with modern I/O or SSDs, where the impact is minimal, and the root remains separate and immutable.

21. Can I use PPAs in NX AppHub CLI?

Yes. NX AppHub CLI supports using PPAs when building files. You can define them in your YAML file under the buildinfo.distrorepo.ppas section.

However, YAML definitions submitted to the curated NX AppHub Apps repository must not use a PPA. Therefore, according to our definition, a YAML file that uses a PPA to obtain Debian packages to build a self-contained AppDir does not produce an AppBox, but an unmanaged binary.

We base our definition of an AppBox on reproducibility and trust: builds must rely on trusted distribution repositories; see 10. Aren't AppBoxes just Debian packages repackaged as "AppImages"? and 16. I heard AppImages are "insecure" and "badly maintained"? Wouldn't an AppBox inherit these defects?.

While PPAs can be useful for local builds, they are third-party sources and fall outside the trusted scope of official distribution archives.