Flatpak-NG plan puts systemd-free Linux distros at risk

Flatpak developers are discussing Flatpak-NG, a next-generation design that would move core isolation work from bubblewrap to a proposed systemd component named systemd-appd.

The change would give Flatpak a cleaner architecture and stronger sandbox controls, including network stack isolation. It would also make systemd a core dependency if the project ships the design as Flatpak 2.

That trade-off hits systemd-free distributions first. MX Linux, Alpine Linux, Devuan and Slackware use Flatpak to reach desktop apps that distribution maintainers do not package. If Flatpak 2 requires systemd, those projects would need to adopt systemd, stay on Flatpak 1, or build a replacement service that provides the same app-management interface.

The proposed design shifts work from bubblewrap, the sandboxing tool Flatpak uses today, into systemd-appd. Developers could reduce Flatpak’s own isolation code and rely on systemd to create and supervise app environments. That may help Flatpak handle network isolation, service control and resource boundaries with less duplicated code.

Users would see the cost through distro support. A systemd-free desktop user who installs apps through Flathub may lose a route to browsers, chat clients, editors and creative tools if the distribution cannot support Flatpak 2. Maintainers could keep Flatpak 1 alive for a time, but app publishers would move as the ecosystem moves.

Snap gives Canonical a different answer. Snap already ties package delivery, confinement and update behavior to Canonical’s model. Critics focus on Canonical’s control of the Snap Store, but Snap’s technical scope covers desktop apps, command-line tools and Ubuntu Core system components. Flatpak gained its audience because many non-Ubuntu distributions wanted a cross-distro app format outside Canonical’s control.

That history makes the Flatpak-NG discussion sensitive. Flatpak serves users who chose distributions with different init systems, package policies and release models. A systemd dependency would narrow that promise. Developers for other init systems could write their own systemd-appd-compatible service, but that work requires time, coordination and long-term maintenance.

Flatpak-NG remains a proposal. The project has not shipped Flatpak 2, and maintainers can still change the design. The technical goal makes sense: stronger isolation matters for desktop Linux as more users install apps from shared repositories. The governance question matters too. If one init system controls the path to modern Flatpak support, systemd-free distributions lose practical access to a major Linux app channel.