FAQ

Overview

This FAQ digs into naming, usage quirks, and common confusion points.

1. Why are the files called AppBoxes?

We use the "AppBox" term to differentiate files built using NX AppHub CLI and the curated YAML specifications from the Git-based repository (NX AppHub Apps) from AppImages built locally or downloaded from other sources.

Any AppImage manually built, i.e., from a YAML file that isn't available in (NX AppHub Apps), downloaded from elsewhere, or renamed isn't considered an AppBox and won't be managed the same way by the CLI.

2. Are AppBoxes the same as AppImages?

Technically, yes. AppBoxes are AppImages under the hood. However, there are key differences:

• AppBoxes are built using NX AppHub CLI using curated YAML specs from a Git-based repository—the user does not manually assemble them.
• AppBoxes are built using prebuilt packages (e.g., Debian packages), not from source code. They are assembled by extracting and staging trusted .deb files into an AppDir.
• AppBoxes do not embed AppImageUpdate metadata—they don't support AppImageUpdate since we do not embed update URLs in the files, and we do not 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 are integrated with Nitrux's app lifecycle management—they're tracked and managed consistently via the nx-apphub-cli commands.
• AppBoxes are sandboxed by default(*) and are built to use either Firejail, Firejail+AppArmor, or Bubblewrap.
• AppBoxes use a FUSE 3 runtime (go or uruntime) in their YAML definitions.

3. Do AppBoxes follow the official AppImage specification?

Not entirely. An AppBox does not aim to follow the AppImage specification—rather, it uses the AppImage format as a delivery mechanism for applications, 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?

Technically, they should. However, the YAML files in the curated apps repository are guaranteed to generate an AppImage specifically functional in Nitrux, ergo, an AppBox.

However, nothing about NX AppHub CLI "locks" them to Nitrux and 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.

Ensuring portability requires additional testing steps using other target Linux distributions; see 5.1 Ensuring AppImage Portability.

The AppBoxes might still be portable, i.e., they might work in other Linux distributions, but it's not the project's priority.

---

It's important to understand how the portability aspect of an AppImage works; whatever is not in the root directory of the target Linux distribution must be included in the AppImage.

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 already includes many libraries, the number of files necessary for the AppImage to work in Nitrux is less; therefore, while a YAML file creates an AppImage that prioritizes Nitrux—ergo, it's an AppBox—the same AppImage may not work in other Linux distributions immediately.

5. Can I rename an AppBox?

Yes, but we do not recommend doing that as it may break auto-detection and integration. AppBoxes follow a standard naming format so the CLI can manage, update, and remove them correctly.

You may want to do this if you're thinking of running the generated AppImage(s) in other Linux distributions; however, renaming an AppBox will not automatically make it work in other Linux distributions, see 4. Do AppBoxes work on other Linux distributions?.

---

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, this is not a supported workflow:

• 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.

This behavior 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.

This includes:

• 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 the placeholder values, including its dependencies and environment variables, and creating workarounds if necessary.

NX AppHub CLI does not decide whether a YAML file specifically produces a file that only works 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.

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

Kind of—but that's exactly the point. AppBoxes take existing prebuilt packages (like .deb files) and stage them into 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. Instead, they:

• Run without root, installable per user.
• Integrate cleanly into the desktop without modifying the base system.
• Support declarative rebuilds from YAML.
• Enable sandboxing via Firejail or Bubblewrap.

So, while AppBoxes leverage .deb packages, they recontextualize them for a modern, immutable, user-centric environment, and they reimagine what it means to use them in a system built around AppImage, not dpkg and APT.

---

"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 operating 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) provides trusted, audited packages.
• The management model (NX AppHub CLI and AppBoxes) breaks from Debian completely.

But AppBoxes aren't tied to .deb packages as a sacred technical truth.

---

Why not use RPMs, staged tarballs, or other formats instead?

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

However, we deliberately use Debian packages for NX AppHub CLI and NX AppHub Apps because of Nitrux's existing build systems, tooling, and ecosystem. This choice minimizes complexity, avoids redundant work, and keeps maintenance streamlined.

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 what we design NX AppHub CLI to manage.

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. To contribute a functional YAML to the curated apps repository, see NX AppHub Apps → Contributing.

Renaming an AppImage to look like an AppBox will not make it manageable by the NX AppHub CLI.

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.

• ♦ Information: Nitrux will not include the standard (although optional) AppImage integration daemon, appimaged, by default in future releases of the distribution.

We're not deprecating external AppImages—we're adopting AppBoxes as a structured, Nitrux-first way to use them.

13. Does NX AppHub CLI download existing AppImages from other sources, such as the developer 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.

You may use another AppImage tool to manage existing AppImages, but NX AppHub CLI is not designed to work like that.

---

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 complicates the process unnecessarily, requiring manual staging of missing files, libraries, environment adjustments, and integrations that NX AppHub CLI normally handles automatically via Debian packages.

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, the user can sandbox the application by default—not at runtime, but at build time, using the configuration specified in the YAML definition; this is a key distinction from traditional AppImages:

• Other AppImages typically rely on tools like appimaged to sandbox them during integration. These tools create a .desktop launcher that runs the AppImage using Firejail with a generic AppImage profile.

• AppBoxes, by contrast, declare a sandbox policy (e.g., Firejail or Bubblewrap) during the build process. When launched, the resulting AppBox runs with that sandbox, meaning the binary inside the AppDir is executed with the sandbox, not the AppBox.

The previous means sandboxing is declarative—but with one major difference:

AppBoxes do not rely on a centralized runtime or background daemon to enforce sandboxing.

Whether an AppBox uses sandboxing depends on the target system's capabilities:

• On Nitrux, AppBoxes run sandboxed by default using either:
  • Firejail (with or without additional AppArmor profiles)
  • Bubblewrap (with declarative binds and permissions)
• On other distributions, sandboxing still works if those tools are 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.

15. How does NX AppHub CLI compare to other AppImage management tools?

NX AppHub CLI is not "just" an "AppImage manager." Unlike tools that aim to aggregate or launch existing AppImages, it focuses on building structured, reproducible application files tailored to prioritizing Nitrux.

It treats AppImages as a format for distributing declaratively built applications, not as a random executable collection.

While it is true that traditional AppImages (and, by extension, AppBoxes) do not require a package management interface, NX AppHub CLI introduces one intentionally:

• To provide a familiar, structured, and predictable experience in a modern Linux distribution context.

In this sense, AppBoxes, while technically AppImages, lean toward a more streamlined and integrated user experience, respecting both AppImages' freedom and users' desktop expectations.

AppBoxes aren't just files you manually download and guess about; they are declaratively built, reproducibly integrated, and managed cleanly 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 AppBoxes (Nitrux-first AppImages)	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	AppImages as a declarative, reproducible delivery mechanism for applications in Nitrux	AppImages as convenient binaries for any Linux distribution	AppImages 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 structure following the Filesystem Hierarchy Standard (FHS)	Varies due to heterogeneous sources	Varies 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, self—contained application files prioritizing Nitrux.

By contrast, utilities such as AM/AppMan and Zap are general-purpose tools that aggregate and manage various AppImages and portable programs (e.g., tarballs, static or bundled binaries) from upstream sources or third-party GitHub repositories, primarily providing a package management aspect 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've 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.

However, regarding external AppImages, as with any technical question, it depends.

This could be considered the case depending on the source from which an AppImage was obtained. While some upstream developers distribute their software via AppImages, third parties distributing software in AppImage format may not have transparent build processes or 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 obtention 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 led to the trust issues.

AppBoxes resolve these concerns by changing the model: they are not random 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 the AppImage (and now AppBox) 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.

We preserve the original spirit of why AppImages (and, by extension, AppBoxes) are 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, or KDE Neon), 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 AppBox?.

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

An AppBox differs from other AppImages from a design and philosophical standpoint by being built from scratch using staged Debian packages based on 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 apps repository; see NX AppHub Apps → Contributing; 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 aim to target the "lowest common denominator" (e.g., building for the oldest supported Ubuntu LTS release), NX AppHub CLI and AppBoxes are designed to guarantee a self-contained application files that prioritizes Nitrux.

• 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; ergo, AppBoxes prioritize Nitrux.

This 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

AppBoxes are intended to guarantee Nitrux users of functional, trusted applications. Their ability to run on other Linux distributions is purely incidental—not a priority, guarantee, or part of the project goals.

---

It's essential to understand that creating an AppImage using pre-compiled packages is not recommended by the AppImage developers, much less software that is compiled against a newer version of the GNU C Library, because such an AppImage will not work on a distribution with an older version of the GNU C Library due to missing symbols required by the executable and its runtime libraries inside the AppDir, that's why the AppImage documentation mentions using the oldest supported version of a Linux distribution, and there's a prevalence for the preference to compile the bundled software instead; 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 the AppImage is forward-compatible, which is part of what makes them "universal."

Meanwhile, an AppBox targets Nitrux, not other Linux distributions; thus, NX AppHub CLI builds them from .deb packages that link against the version of the GNU C Library included in the distribution, which will be newer than the version included in those distributions. As we mentioned earlier, this is a significant difference in our definition of AppBox, and it's one of the reasons why they're divergent.

However, when using the build command in NX AppHub CLI, users can use a YAML to create an AppImage that precisely targets these older distributions; see 9. Does NX AppHub CLI only generate YAML files that create AppBoxes?, using packages compiled against older versions of the GNU C Library.

Nevertheless, YAML files that create such files won't be allowed in the NX AppHub Apps repository; therefore, based on 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 (like i386, armhf/armv7l, armel, etc.). However, we do not discard supporting other 64-bit variants (like RISC-V, ppc64le, s390x, etc.).

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; these use FUSE 2 or 3, with varying levels of compression during building. 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.

⚠️ Important: 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 for an even better 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 the 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 also preserves separation and immutability of the root.

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 AppImage.

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've 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.