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.
I bet it’s all related to the bullshit mass surveillance Age Verification that they so hastily pushed in system and locked the merge request so it cannot be downvoted anymore or commented on it.
This definitely looks like a concerted effort to tie programs to the dicatorial bullshit that is coming.
Luckily I use very few programs in Flatpak format for which I will ask their developers to look at other packaging formats, like native distro formats, deb, rpm or I will remove their programs immediately, never install them again and never recommend them to anyone and I will also warn everyone about what they are trying to do.
Good luck to Deb, Rpm and AppImage formats!
This will probably take many or multiple years to even implement since a transition period would most likely be needed which supports this and old and it will take some time regardless to even reach a point where its even usable and I doubt I will ever notice the changes since I just use the software and never think about this kind of stuff anyways since it all feels the same to me.
flatpaks and systemd are Red Hat pet projects.
They try to force their garbage onto users by locking them and removing choice. No surprise there, Red Hat has been going for this for 15 years.
Artix, Void or Devuan will thank them once again. Another massive users switch to come. The more they force-feed systemd and remove choices, the more the alternatives grow.
There is no need for systemd in 2026. The alternatives are mature and transparent (you won’t even feel you are not using systemd), and you only lose heavily market-share declining software such as flatpak or Gnome. So basically, nothing is lost.
No problem with that. No one cares about flatpaks.
They’ve never been adopted much, and they’re already in decline as Steam installs show.
You must really hate flatpaks for whatever reason. There is absoulty nothing wrong with more software choices. Heck all your blabbering sounds childish and serves no purpose.
Says the only person blabbering without purpose here.
There is nothing wrong with more software choice, I didn’t say anything contrary to that.
But if the new modern and popular distros (Artix, Void, …) need to move on without the most outdated choice, it’s not a big deal.
As more Linux distros push to grow their share of desktops, I see more evidence of GNU/Linux organically splitting ever more sharply into “mainstream” and “experimental” branches. Systemd init has emerged as one of the most defining components of more mainstream Linux distros. There’s a lot of good to be said about distros like Nitrux OS, for example, like its strong support for AppImages. But it’s really hard to recommend it to anyone as a potential daily driver.
Hi, Nitrux developer here.
Categorizing distributions that use established init systems like OpenRC as “experimental” misrepresents the Linux ecosystem. Different engineering goals simply require different architectural foundations.
Regarding the article’s premise, changes to Flatpak’s upstream dependencies do not inherently leave non-systemd distributions behind. We could actively reverse-engineer the required daemon functionality to ensure Flatpak remains fully compatible with our OpenRC foundation.
To clarify, Nitrux never restricts users to AppImages. We utilize a Rootless App Model that natively integrates NX AppHub, Distrobox, and Flatpak.
Finally, defining a “daily driver” depends entirely on user expectations. Users expecting a zero-learning curve that perfectly replicates their legacy setup will naturally experience frustration. However, for anyone willing to engage with its distinct workflow, Nitrux functions exceptionally well as a primary system.
That time is gone though. systemd is outdated and overkill for home usage, and distros are slowly dropping it, with the more modern alternatives growing faster at the moment.
systemd is not going anywhere and will be heavily used by many for the unforseeable future. Even if somthing replaces someday who cares??? I never even think about it since its somthing that goes unoticed on my system.
Cool story.
Once again, nothing to do with what I wrote though.
I mean, thick-skulled techno-luddites who reject systemd are probably, in general, also against Flatpaks and Snaps, though maybe not AppImages.
You could also probably scare them away with Tanenbaum’s Modern Operating Systems like demons with a Bible.
So, this change will probably have a very low impact if implemented.
Thick-skulled because they chose a different path than yours?
You’re the thick-skulled narrow-minded resistant to change intolerant one here.
Either way, no value is lost. Flatpaks never picked up, and are already in decline.
majority of people will notice no difference and most people will continue to use flatpak on os’s where it works. I have no issues with these changes and the older I get the less I want to mess with things. I literally use snaps and flatpaks for everything and think they are both amazing. I have not used a ppa or went looking elsewhere for software in many years now. Heck one of my setups is a cheap n100 intel mini that runs both snaps and flatpaks and I never have any issues and everything is always lightning fast.
I just want to throw in my two cents. I’ve been using Linux as my daily driver since around 2004, and one thing I’ve always liked about it is that Linux itself is just the kernel. Everything on top of that is pretty much your system. If you don’t like something, change it. If something doesn’t exist, build it. If someone else’s way of doing things doesn’t work for you, make your own.
That freedom is what makes Linux powerful, but it also seems to be what makes the community so divided. I don’t think I’ve ever seen another community argue so much over tools, distros, package formats, desktops, and workflows. Still, with enough patience, I can usually get almost anything working on almost anything.
For my own setup, I prefer AppImages or tarballs that I can keep organized on my NFS volume. It keeps things simple, portable, and under my control, which is kind of the whole point for me.
This is the best comment I have seen so far on this topic.
wouldn’t it be installed automatically if its needed anyways when installing flatpak or threw a update like any other program I install that needs stuff to make it work or am i missing something?
not sure that would be possible easily considering what it does.
Another reason to use SystemD free distros.
This means no more Flatpaks and even more systemd- free distros for me. 🙂
Another thing: there never was real value with Flatpaks.
This comment makes no sense unless you have a specific reason for not wanting it to be part of your setup.
There is literally no use to flatpaks.
It’s easy to explain if you’re old enough to remember the Unix philosophy. Black boxes and things that do more than one thing at a time are antithetical to Linux/Unix philosophy. Systemd is an example of breaking that philosophy.
It is becoming Windows and we’re letting it by ignoring the reason Linux IS NOT Windows.
who the heck would want a system that can not do more then 1 thing at a time? I guess my pc is to powerful and I need to get something from the early 80’s maybe the 70’s maybe even older?
systemd-free distros can do everything systemd distros do, regardless of the different philosophy behind init systems.
maybe anything more powerful then a calculator goes against linux/unix philosophy
lol
This is nonsense
I just checked in terminal and systemd is active on ubuntu.
To check if systemd is installed, you can run the command ps -p 1 -o comm= in the terminal; if it returns “systemd,” then it is active.
So I guess this change would have no effect on debian or ubuntu based distros.
It’s simple:
Distributions that don’t adopt systemd won’t be able to use Flatpak.
A distribution that doesn’t implement systemd by 2026 isn’t an ideal system for today’s users.
That’s the stupidest take I’ve ever read.
In fact, systemd-free is more popular than ever, with Artix, Void or Devuan slowly becoming 1st class citizen.
Also, the ecosystem around turnstile+seatd and dinit (or runit, OpenRC, S6) is growing FAST.
People dropping systemd are likely to drop flatpaks too, as it’s yet another project sponsored by the toxic company of the Linux World.
And flatpaks never took off anyways, while even declining now as Steam installs clearly show.
Losing something that has never really been adopted is losing nothing.
What’s simple is how people continue to accept the “Microsoft-ization” of Linux. it’s the byproduct of life-long windows users trying Linux and making it look like what they left, rather than embracing what makes Linux great… hint: it’s not making things like systemd.
That attitude should change and realize Systemd breaks the core tenet of the Unix philosophy.
It may break it for you but it breaks nothing for me since even without systemd the os can look and function the same since something else can just take its place. Systemd does not make linux distros look like windows. Are you saying linux distros should not use init systems since we need system to function like the very early os olden days and any progress is bad. There are distros that use alternative init systems I guess they are bad also according to your logic.
Yeah, Flatpak can be added to the steaming pile of garbage that systemd is required for nowadays, good riddance.
Agreed. They’re a hot pile of garbage.
A pile of garbage? Lots of people use flatpak and this would still work with most distros based on redhat or debian which are many. I do not use that many flatpaks but it is not a pile of garbage it is only another software choice that many find useful. Heck I use snap also since there are things I can not find on flathub plus I like snaps.
Only a niche of people use flatpaks. It never picked up, and even less so these days.