Overview

While AppBoxes and NX AppHub CLI offer a flexible, user-centric application management system, there are inherent conceptual limitations based on our design goals.

1. Trade-offs and design limitations under a rootless model: Desktops in an AppBox?

While it's technically possible to package standalone window managers (like Blackbox (X11), Openbox (X11), Sway (Wayland), or Hyprland (Wayland), etc.) or even desktop shells (like Plasmashell or GNOME shell) into AppBoxes, session-based integration presents clear limitations for both.

Still, they are now better defined rather than categorically excluded.

AppBoxes as defined in FAQ → 1. Why are the files called AppBoxes? are built around these principles:

• Rootless operation: AppBoxes are built and managed entirely in user space without requiring elevated privileges at any stage—installation, update, or removal.
• Immutable system integrity: AppBoxes never write to or depend on modifying the base system. They respect the read-only nature of Nitrux's root filesystem and avoid tampering with system directories like /usr or /etc.
• Predictable lifecycle: Every AppBox is registered, tracked, and updated via the NX AppHub CLI, which ensures consistent management and avoids the fragmentation of ad hoc AppImage deployments.
• Built from curated packages: AppBoxes are constructed from trusted prebuilt .deb packages using a formal YAML specification, not improvised staging or source builds.
• Isolated execution: AppBoxes support declarative sandboxing to limit access to system resources when configured in YAML.

While AppBoxes' design philosophy supports a wide range of user-level software, one category poses a unique challenge: window managers and desktop environments.

Most applications integrate cleanly into the user space and can use a sandbox. However, standalone window managers and desktop environments (e.g., desktop shell + window manager) operate differently; they interact deeply with display servers, manage input/output, and often must run outside sandbox environments to function correctly.

Additionally, session-based integration (e.g., for login managers like SDDM) requires placing .desktop files in privileged system directories such as /usr/share/xsessions or /usr/share/wayland-sessions; NX AppHub CLI and its integration daemon do not and will never write to these directories during the integration process of an AppBox.

Why not just "fix it" with root?

Because doing so would break the foundation NX AppHub CLI is built on: rootless, user-controlled, immutable application management.

To accommodate this edge case without compromising the system design, NX AppHub CLI introduces a special integration mode, see YAML Configuration Syntax → 1.2 Integration Configuration.

However, users must manually install the session launcher into the appropriate system directory if they want their login manager to detect the standalone window manager or desktop environment session, for example, using these templates and placing them in either /usr/share/xsessions or /usr/share/wayland-sessions:

1.1 Example #1 - Template session launcher for Wayland

[Desktop Entry]
Name=<Display name>
Comment=<Small description>
Exec=<Path to Appbox>
Type=Application

1.2 Example #2 - Template session launcher for X11

[Desktop Entry]
Name=<Display name>
Comment=<Small description>
Exec=<Path to Appbox>
TryExec=<Path to Appbox>
Type=Application

The issue isn't technical feasibility; it's philosophical and design coherence; it's a deliberate safeguard to preserve a clean separation of system and user space.

2. An AppBox is for applications, not for system services

AppBoxes are designed strictly for user applications, not for system components.

They are not intended for—and cannot cleanly replace—essential system software such as:

• Init systems (e.g., OpenRC, systemd)
• Login managers (e.g., SDDM, GDM)
• Core daemons (e.g., NetworkManager, dbus-daemon)
• Critical services (e.g., cron, udev, elogind)
• Kernel-integrated hypervisors (e.g., VirtualBox, VMware)

Scope	Purpose
GUI applications (e.g., Inkscape, Firefox)	✓
Full desktop environments (e.g., Plasma)	✓
CLI tools and utilities	✓
Immutable, portable packaging	✓
Reproducible builds with versioning	✓
Rootless app execution	✓
Sandboxed app launches (Firejail, bwrap)	✓
Offline-compatible app deployment	✓
Apps needing host integration (themes, icons)	✓
QEMU-based virtualization tools (non-root)	✓
Installing databases, LAMP stacks, etc.	✖ → Better suited to containers
Kernel-dependent hypervisors (VirtualBox, VMware)	✖
System daemons or socket-activated services	✖
Multi-user or shared environment deployments	✖
Dev toolchains or mutable environments	✖ → Better suited to containers
Apps requiring persistent background state	✖ → AppBox does not manage long-running or stateful services internally
System-level package management	✖

Why this matters:

• Security: No root permissions required to install, run, or manage AppBoxes.
• Simplicity: No entanglement with system-wide package managers or services.
• Reliability: Avoid breaking system-critical functionality by keeping it separate.

TL;DR:

AppBoxes are for apps you launch as a user, not services that boot your system.