Flatpak is a packaging, distribution and sandboxing system for desktop applications on Linux that lets one build of an application run on many Linux distributions. In the field of installation and packages, it represents the distribution-independent model: instead of relying on libraries supplied by the operating system, an application declares a shared runtime and runs inside an isolated environment with controlled access to the host.
Flatpak complements rather than replaces the system package manager. Tools such as APT or DNF still install the operating system, drivers and command-line software, while Flatpak typically delivers graphical end-user applications such as office programs, browsers, editors and games, often from a central repository called Flathub.
How Flatpak installs and runs applications
Flatpak separates an application from the system by combining three components: the application bundle, a runtime and a sandbox. The bundle contains the program and any libraries the runtime does not provide. The runtime is a versioned set of common libraries, such as a GNOME, KDE or freedesktop base, that many applications share.
Content is stored using OSTree, a content-addressed storage system that works somewhat like version control for binary files. Identical files across applications and runtimes are stored only once, and updates download only the changed objects, which keeps repeated updates smaller than the first installation.
At launch, Flatpak uses bubblewrap and Linux kernel namespaces to build a private view of the file system in which the runtime appears under /usr and the application under /app. The application cannot see most of the host system unless its declared permissions or the user allow it. Access to files chosen by the user is mediated by portals, desktop services that open a file chooser outside the sandbox and hand the selected file back.
Core components and terminology
Flatpak uses its own vocabulary, and each term corresponds to a concrete part of the system. The table below summarizes the key building blocks an administrator or packager encounters.
| Component | What it is | Practical role |
|---|---|---|
| Application ID | Reverse-domain name such as org.example.Editor | Identifies the app in commands and storage |
| Runtime | Versioned shared library set | Provides the base platform for many apps |
| SDK | Runtime plus compilers and headers | Used to build applications |
| Extension | Optional add-on to an app or runtime | Adds codecs, drivers or plugins |
| Remote | Repository configured on the system | Source of apps and updates |
| Manifest | Build recipe in JSON or YAML | Read by flatpak-builder |
| Portal | Desktop service for controlled access | File choosers, printing, screenshots |
Installations can be system-wide or per-user. A system-wide installation serves all accounts and usually requires administrative rights, while a per-user installation lives in the home directory and needs no elevated privileges. Each application keeps its settings and data in its own directory under ~/.var/app, which simplifies clean removal and backup.
Flatpak compared with other package formats
Flatpak belongs to a group of universal Linux formats, alongside Snap and AppImage, and differs from traditional distribution packages. The main differences concern dependency handling, sandboxing and update delivery.
| Format | Dependencies | Sandboxing | Updates | Main focus |
|---|---|---|---|---|
| Flatpak | Shared runtimes | Built in, permission based | Central, delta based | Desktop apps |
| Snap | Base snaps and bundled libraries | AppArmor confinement | Automatic from one store | Desktop, server, IoT |
| AppImage | Bundled in one file | None by default | Optional, per app | Portable single files |
| Distribution package | Shared system libraries | None by default | Package manager | Whole system |
| MSI | Bundled or system | None by default | Vendor or management tools | Windows software |
The practical consequence is that Flatpak is not a general replacement for system packages. It is poorly suited to kernel modules, system daemons and many command-line tools, because the sandbox and runtime model are designed for graphical applications that interact with a user session.
Permissions and the application sandbox
Flatpak permissions are declared by the packager as static permissions in the manifest and can be changed by the user with tools such as flatpak override or a graphical permission manager. The strength of the application sandbox therefore depends heavily on how restrictive these declarations are.
| Permission | Example option | Effect |
|---|---|---|
| Home directory access | –filesystem=home | Read and write user files directly |
| Network | –share=network | Allows internet connections |
| Display | –socket=wayland | Draws windows on the desktop |
| Audio | –socket=pulseaudio | Plays and records sound |
| Devices | –device=all | Access to cameras and other hardware |
| Session bus | –talk-name=… | Talks to selected desktop services |
A frequent misconception is that every Flatpak application is strongly isolated. Many popular packages request broad file-system access or the X11 socket for compatibility, and under X11 an application can observe other windows. Real isolation comes from narrow permissions combined with portals, a Wayland session and keeping the runtime updated.
Practical use, limitations and pitfalls
Typical administration requires only a few commands: flatpak install, flatpak update, flatpak list and flatpak uninstall --unused, which removes runtimes no longer needed by any application. Most desktop distributions also integrate Flatpak into their graphical software centers.
- Disk usage is higher at first, because the first application pulls in a runtime that can occupy several hundred megabytes, although later apps reuse it.
- Theme and font mismatches occur when the host theme is not available as a runtime extension.
- Outdated runtimes that have reached end of life no longer receive security fixes and should be replaced through app updates.
- Development tools such as IDEs may struggle to reach compilers on the host and need extra permissions or helper tools.
- Trust in the repository matters: verified publisher markings help, but community-maintained packages are not always made by the original developer.
In simple terms
Flatpak is a way to install programs on Linux that works the same on almost every version of Linux. Each program arrives in its own sealed box together with the parts it needs, so it does not depend on what the computer already has.
The box also acts as a fence. A program inside it can only reach the files, camera or network that it has been allowed to use. It is a bit like giving a visiting tradesperson access to the kitchen but not to the rest of the house.
A practical example
A school IT administrator manages fifty classroom computers running a long-term-support Linux distribution. Teachers want the latest version of an image editor and a geometry program, but the distribution repositories contain versions that are two years old. Upgrading the whole operating system mid-year would be risky.
The administrator adds the Flathub remote system-wide, installs both applications as Flatpaks and schedules flatpak update to run nightly. Both programs share one runtime, so the second installation downloads far less data than the first. Using a permission override, the administrator limits the image editor to the Pictures and Documents folders instead of the entire home directory. The outcome is current applications on a stable base system, without touching the operating system packages.