Pros of Using Flatpak

Flatpak does a lot of things. Oftentimes people ask me “Why Flatpak?” and I only end up remembering a few off-hand, so I figured it’s time to sit down, reflect, and go over “Why Flatpak” in a nice forum thread once and for all.

  • Package once, identical version is installed on 20+ distros
  • Build server runs offline for predictable builds*
  • Encourages upstream to follow xdg standards (i.e. so your config files/cache files are in predictable places)
  • x-data-checker allows maintainers to update apps quickly
  • (On Flathub) Packages can be verified to come from upstream
  • Apps are sandboxed by default, and permissions are easily modifiable with Flatseal
  • Flatpaks run seamlessly on immutable distros like SteamOS
  • Installed apps can be individually rolled-back
  • Updates don’t require root

* Note this isn’t the same thing as reproducible builds, but still covers many of the same benefits

And for completeness, some disadvantages of Flatpak:

  • Worst-case scenario you’ll have two identical copies of the same library on disk (although mitigable with FS compression like BTRFS)
  • App library dependencies happen independently of the package manager, requiring more bandwidth
  • Apps requiring root priviages (like VPNs) can’t be packaged
  • CLI apps don’t appear on Flathub and are otherwise awkward to use

Thank you for the brief list!

To further some advantages, here are some I can think of:

  • Safer app installation and updating process, as dependency hell is much more unlikely to happen (or probably even impossible)
  • malcontent (parental control) support
  • Rootless and user installs
  • Configure the sandbox a bit more conveniently, as opposed to Firejail, or even bubblewrap directly
  • No need to create a new desktop entry if you need to persistently set environment variables, socket, etc. strictly for a specific app (except Electron)

And to complete with a disadvantage:

  • Strong dependency to XDG portals. If a portal doesn’t exist for a specific use case, then you’re out of luck, as you have to rely on static permissions, or can’t do anything about it.

Here’s a concrete disadvantage, which is a spin on the dependency to XDG portals:

  • Accessing a serial port works, but only if it’s connected on app launch. And if that device reboots in between (when you flash something for e.g.) it will not show up without restarting the app.

More pros:

A rational straightforward manifest to define the application, rather than a cobbled-together collection of random files and circularly-linked documentation.

The aim of the well-mannered people running it is to do everything in their power to help you get your Flatpak published. Unlike other packaging systems where the aim is to keep the plebs out of their “old boys club”.


Honestly I find the documentation for the manifest one of the worst parts about Flatpak.

The documentation linked on should be the differences between what Flathub wants and what Flatpaks need (in those terms, not “app submission” and “app requirements”), and then the manifest documentation itself should be a skeleton example with links to learn more about each part. Right now that requirements page is non-chronological with no example, and lists optional & uncommon features with the same emphasis as required ones. To top it off, it’s hosted on Github pages so contributors can’t submit any patches to improve it. isn’t a solution either, since it is an absurd amount of information to go through for someone trying to package their first binary app, and doesn’t actually address many of Flathub’s own needs.

The result of this is over 50% of the app submissions include egregious mistakes, and while I commend the patience of hflguiere to go through them, handling this at the documentation level would save both the submitters and maintainers extra stress.

If it weren’t for that buildbot, I think hflguiere would be bald.

The new 5.27 kde update now has a feature called flatpak permission settings, where you can manage the permissions of settings


Creating our own docs that coexist with the flatpak docs is on my (personal) roadmap.

GitHub - razzeee/flatpak-docs-docusaurus is currently only a slimmed down version of the flatpak docs and an added blog. But I hope to start working on docs that are more flathub focused. I’ve also talked with barth about this, but the website relaunch has a higher prio right now.

I do have some thoughts about a new possible outline for docs, but haven’t written them down.


This will only happen if you installed an application in two separate repositories—e.g. your user’s and the system’s repository—which is something that doesn’t really happen.

Identical files in the same Flatpak installation repository are de-duplicated on disk.

I’m referring to once with the package manager and once via Flatpak