# Flatpak: a sandboxed app runtime where the runtime, not the distro, owns the libraries

> Flatpak builds, distributes and runs sandboxed desktop applications on Linux. It is for people who want an app to carry its own dependency stack without giving it the whole home directory or the whole filesystem.

**flatpak/flatpak** — Linux application sandboxing and distribution framework

- Repository: https://github.com/flatpak/flatpak
- Website: https://flatpak.org
- Stars: 5,080 · Forks: 526
- Language: C
- License: LGPL-2.1
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/flatpak-flatpak

## The problem Flatpak solves is library ownership, not packaging

Traditional Linux distribution packages bind an application to the libraries of the distribution that built it. A binary built against one release of a graphics stack or a toolkit may not start on another, so an upstream project that wants to reach many distributions ends up maintaining build recipes per distribution. Flatpak inverts that. The application ships with the libraries it was built against, and the host distribution supplies only the kernel and the basic system services. The README describes the project as a system for building, distributing, and running sandboxed desktop applications on Linux, and the distribution half is the part that matters to upstreams: one build artifact reaches many distributions.

The audience follows from that. If you maintain a desktop application and your users span several distributions, Flatpak removes the per-distribution rebuild from your release process. If you are a user, the benefit is different: an application you install arrives with its dependencies and runs in a sandbox rather than as a normal process with your full user privileges. The project is deliberately conservative about host requirements, which is a design statement as much as a technical one: the main branch states it requires at least kernel version 5.8, for statx STATX_MNT_ID.

## Runtimes, sandboxes and the pieces you actually interact with

The unit of reuse in Flatpak is the runtime. An application declares a runtime, and that runtime provides the shared libraries and tooling the application expects. Multiple applications built against the same runtime share it on disk, so the model is not one bundled blob per application. The application itself is a separate object that depends on the runtime. This is why the system can update a runtime once and have every application that uses it pick up the change.

Around that sit the parts visible in the repository layout. The app/ directory holds the application-side code, common/ holds shared code, system-helper/ and session-helper/ contain privileged and per-session helpers, portal/ relates to the portal interfaces that mediate access to host resources, revokefs/ handles the filesystem view presented to sandboxed applications, and sideload-repos-systemd/ deals with repository access on systems where the normal path is unavailable. The sandbox is not a single switch. It is a set of permissions the application requests, and the portal layer is what lets a sandboxed application reach a file the user chose without granting it the directory that contains it.

Two ecosystem projects are named in the README. Flatseal manages the permissions of Flatpak applications without using the command line, which tells you something about the default experience: permissions are numerous enough that a graphical editor for them exists. Flat-manager manages Flatpak repositories, which is the piece you need if you are on the publishing side rather than the consuming side.

## Installing Flatpak and running a first application

The README does not give install commands. It says Flatpak is available in the package repositories of most Linux distributions and that quick setup instructions for many distributions are at https://flatpak.org/setup/. That is the path to follow: install through your distribution's package manager, then use the setup page for your distribution.

Once the distribution package is in place, the binary it provides is flatpak. The project's own documentation is at https://docs.flatpak.org/en/latest/index.html, and the README points there for usage rather than spelling out commands. The README does not document rollback, so anything about reverting an application or a runtime to an earlier version has to come from the documentation site, not from the repository front page.

What the README does make concrete is the publishing side. It suggests adding your favorite application to Flathub by writing a flatpak-builder manifest and submitting it. That is the artifact an application author produces, and it is the thing to look at first if you are evaluating whether the model fits your project.

## Where the sandbox model gets in the way

The most common failure mode is a sandboxed application that cannot see a file the user expects it to see. That is not a bug in the application; it is the permission model working as designed. A sandboxed application sees the filesystem view it was granted, and reaching outside that view goes through the portal layer or through a permission the application declared. When an application writes to a location it was not granted, the write fails or lands somewhere the user did not expect.

There is a second cost that the README does not discuss and that surfaces in practice: disk usage. Runtimes are shared, but they are not free, and a system with applications across several runtimes accumulates several of them. On a machine with limited storage this is a real budget item, not a rounding error.

The third case is the wrong-tool case. If your application needs broad, unpredictable access to the filesystem, to arbitrary devices, or to system services that are not exposed through a portal, the sandbox is an obstacle rather than a benefit. You can widen permissions, but at some point you have reproduced the access a normal distribution package would have had and paid the packaging cost for nothing. The same argument applies to a user whose work is entirely within one distribution's package set: Flatpak adds a second package universe to keep updated.

## Flatpak against Snap and AppImage, and where the difference shows

Snap and AppImage are the two comparisons people reach for, and the difference is in where the dependency stack lives and who controls the repository. Snap packages are distributed through a single vendor-controlled store, and the format is tied to that store's tooling. Flatpak separates the application from the runtime and lets a remote be any repository, which is why the README can point application authors at Flathub while Flat-manager exists for people running their own repository. If you need to host your own repository and control distribution, that separation is the reason to pick Flatpak.

AppImage is a different shape entirely. An AppImage is a single executable file with no runtime concept and no repository, so there is nothing to update centrally and nothing shared between applications. That makes it excellent for handing someone a file and terrible for keeping a fleet of applications patched. Flatpak's runtime model means a runtime update reaches every application that depends on it. If your problem is distribution to many users with updates, AppImage is the wrong tool; if your problem is one file that runs anywhere without installation, Flatpak is the heavier answer.

The sandboxing story also differs. Flatpak's permissions are visible and editable, which is why a tool like Flatseal exists, and the portal layer is part of the design rather than an add-on. That visibility is a feature: users can inspect and change what an application is allowed to do.

## Maintenance, release cadence and the licence

The repository is not archived, and the last push was on 2026-09-22, the same day as the 1.18.3 release. The recent release list shows a stable line at 1.18.2 and 1.18.3 with a 1.19.0 development release in between, which is the ordinary pattern for a project that keeps a stable branch and a development branch. For an operator, that means upgrade cost is mostly the cost of following your distribution's packaged version and the runtimes your applications depend on, not the cost of tracking upstream source.

Flatpak itself is licensed LGPL-2.1 according to the repository. That is the licence of the framework, not of the applications you distribute with it, and it is not the licence of the runtimes or the applications on Flathub. If you are packaging your own application, the licence that governs your application is the one you choose; the LGPL-2.1 of the tooling does not propagate to it. This is a description of what the repository states, not legal advice, and anyone with a specific compliance question should read COPYING in the repository and consult their own counsel.

The host requirement is the maintenance constraint worth flagging. The main branch states a minimum kernel version of 5.8 for statx STATX_MNT_ID. If you deploy on older kernels, that floor is the first thing to check against your fleet, because it is a hard requirement rather than a recommendation.

## Conclusion

Adopt Flatpak if you ship a desktop application to many distributions and cannot rebuild it per distro, or if you run third-party desktop binaries you would rather not expose to your whole home directory. Do not adopt it if your target is a single distribution with an established package set, or if your application genuinely needs unrestricted filesystem and device access, because the sandbox will fight you. Before committing, check that the kernel you deploy on meets the 5.8 floor the main branch states for statx STATX_MNT_ID, and read the permissions of the manifest you intend to publish, since that is the surface users will judge you on.

## FAQ

### What is Flatpak used for?

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux, according to the README. It lets an application ship with the libraries it needs and run in a sandbox rather than as an ordinary process with full user privileges.

### What are the downsides of using Flatpak?

The sandbox means an application only sees the filesystem view it was granted, so files outside that view are not reachable without a portal or an explicit permission. Runtimes also consume disk space, and a system with applications across several runtimes accumulates several of them.

### What's better, Flatpak or Snap?

The README does not compare the two. The structural difference is that Flatpak separates an application from a shared runtime and lets a remote be any repository, while Snap distributes through a single vendor-controlled store.

### What is Flatpak and how is it used in Linux?

It is a sandboxing and distribution framework for desktop applications on Linux. The README points to https://flatpak.org/setup/ for setup instructions per distribution and to https://docs.flatpak.org/en/latest/index.html for documentation.

### How do I install Flatpak on Linux?

The README states that Flatpak is available in the package repositories of most Linux distributions and points to https://flatpak.org/setup/ for quick setup instructions for many distributions. It does not give install commands itself.

## Sources

- [flatpak/flatpak on GitHub](https://github.com/flatpak/flatpak)
- [License: LGPL-2.1](https://github.com/flatpak/flatpak/blob/main/LICENSE)
- [Project website](https://flatpak.org)
- [README](https://github.com/flatpak/flatpak/blob/main/README.md)
- [Releases](https://github.com/flatpak/flatpak/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flatpak-flatpak