Flatpak developers are discussing major architectural changes that could make systemd a central part of Flatpak’s next-generation sandboxing model, raising questions over the project’s long-term compatibility with non-systemd Linux distributions.
Last November, Sebastian Wick, a Flatpak maintainer, published a project update. He noted that development had slowed after maintainers stepped back, but activity has since increased, with renewed focus on pending merge requests, OCI support, preinstalled applications, and permission handling.
The main concern is the long-term direction of Flatpak Next, an early design initiative for a future architecture that could lead to a major 2.0-style redesign, which Wick and Adrian Vovk discussed publicly a few days ago at Linux App Summit 2026.
A key element of this future work is systemd-appd, a proposed systemd component designed to provide information about running application instances. Wick states that systemd-appd is intended to support authentication of Flatpak instances, enable nested sandboxing, improve PipeWire integration, and eventually replace Flatpak’s current D-Bus proxy model.
This is significant because Flatpak’s current architecture has several limitations. Previous design documents note that Flatpak already requests systemd to assign application instances to appropriate cgroups, although this step can currently fail without consequence. Future designs may require a cgroup for each application instance, managed by systemd or directly, to support app identity and metadata tracking.
The technical motivation is clear: Flatpak requires more robust methods to identify running applications, manage permissions, support nested sandboxes, and integrate with desktop services such as portals and PipeWire. These improvements are especially important for complex applications, including browsers and apps with internal sandboxing.
However, this proposed direction raises a sensitive issue in the Linux ecosystem: whether a cross-distribution application platform should depend on systemd. As you can guess, this concern primarily affects non-systemd distributions such as Alpine, Void, Devuan, and others that intentionally avoid systemd.
Currently, Flatpak is associated with the broader Linux desktop rather than any single distribution family. If future Flatpak releases require systemd-appd without a compatible alternative, these distributions may need to apply downstream patches, maintain a replacement layer, or forgo full Flatpak support.
Finally, it is important to note that Flatpak does not currently require systemd-appd in stable releases, and systemd-appd is not yet a completed or widely deployed component.
The current discussion concerns future architecture, specifically Flatpak Next, and the work developers believe is necessary to address long-standing design limitations. However, its next-generation sandboxing is being designed around infrastructure that may make systemd significantly more difficult to avoid.
Yeah, Flatpak can be added to the steaming pile of garbage that systemd is required for nowadays, good riddance.