Skip to main content
In this lesson we introduce Flatpak: a modern, distribution-agnostic way to package, distribute, and run desktop applications on Linux. Flatpak provides sandboxed application environments, shared runtimes, and a remote-based distribution model (for example, Flathub) so apps run consistently across different distributions and versions.
A dark presentation slide with the title "Flatpak – Introduction" on the left and a large blue Flatpak cube logo on the right. It looks like an opening slide for a Flatpak introduction.
Why Flatpak exists Developers commonly build apps for a specific distribution and version. Differences in library versions and system components can cause apps to fail when run on other distributions. Flatpak solves this by packaging the application together with the libraries it needs (or by reusing a shared runtime), and by isolating the app in a sandbox so it behaves consistently and securely across environments.
A slide titled "Challenges Flatpak Addresses" with two circular icons and labels: "Distribution-specific application builds" and "Application deployment difficulties." Each icon is blue-accented with a small arrow beneath it.
How Flatpak sandboxing works Flatpak applies container-like isolation to desktop applications:
  • Each Flatpak app runs inside its own sandbox, separated from the host filesystem and other processes by default.
  • If an app needs external resources (files, network, devices), it must request permission through the portal system; portal mediation grants or denies access.
  • Common libraries are provided via shared runtimes so apps don’t need to duplicate every library, reducing disk usage while preserving isolation.
Think of an app as living in a playpen. To use the host’s files, network, or hardware (camera, printer), it must ask the parent (the portal system) for access. Some capabilities (like access to the user’s Downloads folder) may be commonly granted; others require explicit approval.
A stylized diagram titled "Flatpak Sandboxing" showing an app inside a sandbox/playpen within a Linux host system, connected to host resources via a portal. Labels explain concepts like restricted space, mediated access (permission via portals), and shared runtime.
When to use Flatpak vs your distribution package manager (DNF) A simple analogy: DNF maintains the house (the operating system)—kernel, system libraries, drivers, and services—while Flatpak brings portable furniture (sandboxed desktop applications) into the house without changing its structure. Use cases:
  • Use Flatpak for sandboxed desktop applications that need portability and consistent behavior across distributions (browsers, editors, multimedia apps).
  • Use DNF (or the distro package manager) to manage system-level software, kernels, system libraries, and services.
Comparison at a glance:
A dark-themed slide titled "Flatpak vs DNF" showing a three-column comparison table with headings "Aspect", "DNF 5", and "Flatpak." The table lists differences like role, purpose, typical use, and environment (e.g., system management vs installing sandboxed desktop apps).
Flatpak remotes (repositories) Flatpak downloads apps and runtimes from remotes—analogous to distribution repositories for DNF. Remotes host catalogs of applications and runtimes; Flathub is the most popular public remote. On many enterprise distributions (for example RHEL), Flathub is not enabled by default, so adding a remote is the Flatpak equivalent of enabling a repository.
Remotes like Flathub provide a broad catalog of runtimes and applications. On RHEL-derived systems, you typically add Flathub explicitly to access that catalog.
A dark-themed slide titled "Flatpak Remotes" showing a side-by-side diagram comparing Flatpak (with a Remote block, app icons and Flathub) to DNF (with Repositories and boxes labeled EPEL and Repos). A wavy equals sign between them indicates they are analogous.
Install Flatpak and add remotes — recommended workflow
  1. Install the Flatpak client (system-wide or per-user).
  2. Verify Flatpak is available.
  3. Inspect configured remotes.
  4. Add remotes (for example, Flathub).
  5. Search, install, update, list, and remove apps as needed.
Example commands (use sudo for system-wide operations):
Common Flatpak commands (quick reference) Important install/update flags Demo walkthrough (example session)
  1. Install Flatpak and verify the version:
  1. Add Flathub and confirm configured remotes:
  1. Search for VLC across remotes:
  1. Install VLC from Flathub (system-wide):
  1. Verify installed Flatpak items:
  1. Update Flatpak applications and runtimes:
  1. Run an installed Flatpak app:
  1. Inspect detailed information about an installed app:
Typical flatpak info output includes fields such as ID, Ref, Arch, Branch, Version, License, Origin, Collection, Installation, installed size, runtime, sdk, commit IDs, subject, and date. Example (truncated):
  1. Uninstall an application:
A dark-themed presentation slide titled "Summary" showing bullet points that explain RPM, DNF, repositories, and Flatpak as package management concepts. Each point is marked with a blue circular icon on a rounded dark panel.
Summary
  • RPM is the package format used for distribution packages.
  • DNF is the distribution package manager responsible for system-level software, dependencies, and updates.
  • Repositories (repos) provide trusted sources for distribution packages—Flatpak’s equivalent is remotes.
  • Flatpak is a cross-distribution application distribution system that bundles apps with runtimes and runs them in sandboxes to provide portability and isolation.
Together, DNF/repos and Flatpak/remotes let administrators and users manage both system software and sandboxed desktop applications effectively. Further reading and references
  • Flathub: https://flathub.org/
  • Flatpak documentation: https://docs.flatpak.org/
  • RHEL Flatpak guidance and enterprise considerations: consult your distribution’s documentation for best practices on enabling and managing remotes on RHEL-derived systems.

Watch Video

Practice Lab