Flatpak's next sandboxing milestone bolts it to systemd. Alpine and Void users get the bill.

Sebastian Wick and Adrian Vovk used their Linux App Summit talk on May 17 in Berlin to lay out systemd-appd, a new component that pulls Flatpak’s permission model out of the runtime and into the init layer. The cost lands on every distro that doesn’t ship systemd by default.

The plan is still on a whiteboard. “Not a single line of code has been written yet,” OSnews points out in its writeup of the talk. But the architectural direction is set, and Wick has been explicit about what depends on it.

This affects most of desktop Linux. Flatpak is the default installation channel on Fedora, the default on GNOME OS, the recommended path on Steam Deck for non-Steam apps, and a first-class installer on Ubuntu through GNOME Software. The init-system fight Flatpak just stepped into has been mostly dormant since around 2018. By forcing the question, Wick and Vovk have effectively asked the smaller half of desktop Linux to either pick up an elogind-style maintenance load or fall behind on sandboxing features that Fedora users are about to get for free.

What systemd-appd actually does

In Wick’s own words from his post-summit blog, “Adrian and I have made plans for a service which allows querying running app instances (systemd-appd). This provides a new way of authenticating Flatpak instances and is a prerequisite for nested sandboxing, PipeWire support, and getting rid of the D-Bus proxy.”

Today, Flatpak holds its own table of app identities and permissions inside the runtime. systemd-appd would move that table down a layer: the service stores each running app’s identifier and permission set, and any other component on the system (PipeWire, the desktop portal, future XDG services) can query it.

Three concrete features unblock once that authentication path exists:

• Nested sandboxing. An app running inside a Flatpak can spawn its own sub-sandbox. The current model can’t authenticate the parent-child relationship without leaking the parent’s permissions, which is why Chromium and Electron sandboxes have been awkward in Flatpak for years.
• PipeWire portal support. PipeWire wants to verify which app is asking for a microphone or screen capture. Today that’s done through the D-Bus proxy. systemd-appd gives PipeWire a direct query path and finally lets the audio server hand out fine-grained capture permissions.
• Killing the D-Bus proxy. Every Flatpak app today routes its D-Bus traffic through a bubblewrap-internal proxy that filters method calls. The proxy is slow. It’s brittle in ways GTK apps regularly trip over. Removing it has been on the Flatpak roadmap since at least 2022.

For users on systemd-based distros (Fedora, Ubuntu, Debian, Arch, openSUSE), this is upside without a tradeoff.

The bill for non-systemd distros

Flatpak’s selling point to Alpine, Void, Guix, and the runit/OpenRC ecosystem was that the runtime was init-agnostic. You could install Flatpak on an Alpine container, run desktop apps from Flathub, and never touch systemd. systemd-appd ends that. Mainline Flatpak will hard-depend on the systemd userland.

Workarounds exist on paper. elogind is the project that already extracts systemd’s session-management bits as a standalone daemon, and an “elogind-style” fork of systemd-appd would in theory let non-systemd distros keep up. Wick and Vovk haven’t said they’ll write it. The community pass at suggesting they should has, per OSnews, gone badly: “any future Flatpak dependency on systemd will be stricter” after the post-summit pushback, and creating an independent daemon “became much harder than it was going to be.”

That’s the load-bearing detail. The Flatpak developers are not just adopting a systemd dependency; they’re signalling that the cost of maintaining compatibility shims for alternative init systems has tipped above the cost of saying no.

A few mechanics matter

The realistic ship window for systemd-appd is GNOME 49 or 50, which puts user-visible impact at late 2026 or 2027 depending on how aggressively the change gets staged. Until then, Wick’s blog post is the closest thing to a public design doc.

• Timeline. No code, no merge date. The Linux App Summit talk on May 17 is the only public artifact so far.
• Flathub keeps working. This is a runtime change, not a packaging-format change. The apps on Flathub today will keep installing on systemd-based distros without rebuilds. The pain is on the distro-maintainer side, not the app-developer side.
• Existing Flatpak installs on Alpine and Void don’t break tomorrow. Older Flatpak releases will keep running. The new features won’t reach those distros unless someone writes and maintains the elogind-style daemon.

What this means for you

If you run Fedora, Ubuntu, Debian-with-systemd, Arch, or openSUSE, this is a quiet net win. The features Wick listed have been the long tail of Flatpak’s “it almost works” reputation, and removing the D-Bus proxy alone will close a backlog of intermittent app bugs.

If you run Alpine, Void, Guix, or a runit/OpenRC setup, plan now. The next 12 to 18 months of Flatpak releases are the last that will be portable without a downstream patch set. If you maintain a Flatpak-using package for one of these distros, the question to put to your community is whether the project has the engineering capacity to ship and maintain an elogind-style appd. If the answer is no, the realistic exit is to migrate users to native packages or to a different containerization model (bubblewrap directly, Distrobox, or just rpm/apk for the affected apps).

If you build a desktop Linux app, none of this changes the format you ship. You will, however, get a better sandbox to ship into. PipeWire-mediated screen capture is the feature most app authors have been waiting on, and it lands the moment systemd-appd is in.

The Flatpak team has been clear about one thing throughout: the architecture they want needs an authentication primitive that lives below the runtime. They’ve picked the one systemd already exposes. The cost of that choice falls on the smaller half of the desktop Linux ecosystem, and the team is no longer pretending otherwise.