A diagram of a Linux operating system containing multiple Flatpak runtimes.

For many years, application developers who wanted to create desktop applications for Linux had to build their applications not just for a particular Linux operating system, but for a particular version of that operating system. Whether it was on the server-side or the desktop, developers wanted to create applications that reliably worked the same in development and production environments. They wanted to upgrade the production environment without having to rebuild and revalidate every running application.

Containers solved these requirements for server-side applications, but not for the desktop. That's why we need Flatpak, a container system just for desktop applications. In this article, I offer an overview of Flatpak, its integration with Red Hat Enterprise Linux (RHEL) 8.2, and what developers can expect from the new Red Hat Enterprise Linux Flatpak runtime.

Note: Red Hat is including Flatpak runtime and software development kit (SDK) images with Red Hat Enterprise Linux 8.2. Integrating a Flatpak runtime will allow application developers to build containerized desktop applications on top of Red Hat Enterprise Linux.

Flatpak: A dedicated desktop container system

Flatpak, which had its first stable release in August 2018, applies the same ideas and Linux kernel technology found in server-side containers to the desktop. Once a desktop application is packaged as a container image for use with Flatpak, which we call simply a Flatpak, it can be reliably used across different operating systems and versions. The user doesn't have to worry that differences in dependencies will cause the application to misbehave or stop working.

As a dedicated system for desktop containers, Flatpak enables transparent and reliable integration with the desktop user interface (UI). A wide range of integration just works—from launching applications to allowing applications access to the window system to accessing the user's files. Flatpak also introduces portals, which offer the application a safe way to access host services from within its sandbox. Portals make the user's decisions part of the user interaction. Whereas a traditional system might ask at installation time if an application should be allowed to print, with portals, the user simply accepts or cancels when shown a print dialog.

Flatpak runtimes

As with server-side containers, Flatpak isolates applications from the operating system. Each application uses its own libraries, not the operating system's libraries. Having a separate copy of all libraries for each desktop application would be prohibitive, however, so multiple applications can share a Flatpak runtime. A runtime is a filesystem image with system-level libraries and other files. As shown in Figure 1, a system can contain a variety of runtimes, with each being used by multiple applications.

A diagram of a Linux operating system containing multiple Flatpak runtimes.
Figure 1. A Linux operating system can contain multiple runtimes.

In addition to saving space, another big advantage of the runtime separation is handling security updates. If there is a security bug in a system library, we only need to update the runtime, and don't need to rebuild every application. A runtime can't possibly include every library that any application would want to use, so libraries can also be bundled with the application. An application typically uses a mix of libraries from the runtime and bundled libraries.

Why we need a Red Hat runtime

Presently, many existing applications use the Freedesktop Runtime, which provides a core set of libraries. Other applications use the GNOME and KDE runtimes, which add additional libraries specific to those Linux environments.

The Freedesktop Runtime is actively maintained—in particular, Codethink contributes considerable effort to keep it up to date. But each major version of the Freedesktop runtime is only supported for a limited period. When you reach that limit, you have to port your applications to a new version. Many application developers would like to have a runtime that is updated for a longer period of time. Enterprise users would also like to know that they can get support for the combination of the host system and the runtime.

For these reasons, Red Hat's Red Hat Enterprise Linux team has decided to release Red Hat Enterprise Linux (RHEL) 8.2 with a Flatpak runtime built from RHEL packages. This runtime follows the Red Hat Enterprise Linux lifecycle. We intend to continue providing security fixes for 10 years from RHEL 8's May 2019 release date.

In the near future, we will be distributing the runtime and SDK under terms similar to the Red Hat Universal Base Images (UBI). These terms allow developers to create applications that work with many Linux distributions. Users won't need to have a Red Hat Enterprise Linux subscription. Support will be available as long as the runtime is running on a Red Hat Enterprise Linux host.

Distributing Flatpaks and runtimes

Flatpak doesn't require all Flatpaks to come from a single, central store. Instead, a system can have any number of configured remotes, which serve as sources of Flatpaks. A user browsing Flatpaks via the flatpak command-line tool (CLI) or with GNOME Software will see Flatpaks from all of the configured remotes.

Currently, there are two types of Flatpak remotes. Originally, Flatpaks were distributed from an OStree repository. OStree is a Git-like system for managing binary operating system trees. It is used for operating systems like Fedora CoreOS, Fedora Silverblue, and Endless OS. You can export an OStree repository over HTTPS for remote download.

More recently, Flatpak gained support for downloading Flatpaks as container images from a container registry. The container images can be Open Container Initiative (OCI) container images, or they can be traditional Docker images. Having support for both formats allows using a wide range of container registries. For example, the Red Hat Container Catalog currently distributes Flatpaks as Docker images.

A graphical software installer like GNOME Software needs information like descriptions and icons. With the Docker and OCI registry protocols, there's no way to collect this required information for all of the images. Therefore, it's necessary to provide a separate JSON index to the Flatpaks on the registry. Work is underway to add Flatpak indexing support to Quay.io. This service will provide application developers with a convenient way to distribute their work.

Installing the Red Hat Enterprise Linux Flatpak runtime

Download the RHEL Flatpak repository file to add the repository to your system. On a recent RHEL or Fedora system, GNOME Software should offer to add the repository to the system. You can also use the command-line to add the repository:

$ flatpak remote-add rhel https://flatpaks.redhat.io/rhel.flatpakrepo

Next, provide the credentials for your Red Hat Enterprise Linux account:

$ podman login registry.redhat.io
enter your username and password

Note: If you don't have a Red Hat subscription, and you want to use the runtime for development purposes, then you can register for a free developer subscription.

Podman only saves credentials until the user logs out. If you want to save your credentials permanently, enter:

$ cp $XDG_RUNTIME_DIR/containers/auth.json $HOME/.config/flatpak/oci-auth.json

If you want to enable the RHEL Flatpak remote for a set of workstations within an organization, you should use a Registry Service Account. You can install credentials for such an account systemwide at /etc/flatpak/oci-auth.json.

Now install the Flatpak runtime:

$ flatpak install rhel com.redhat.Platform

The RHEL Flatpak remote will also contain applications in the future. These applications will appear in GNOME Software for browsing and installation together with applications from other Flatpak remotes.

Creating application images

Creating an application involves creating an application image that, at runtime, will be mounted at /app. The application image goes along with the runtime image, which is mounted at /usr. There are various ways to create these images. For example, Fedora creates Flatpaks out of Red Hat Package Managers (RPMs). RPMs are rebuilt and installed into a container image within Fedora's container build system. However, the most typical way to create a Flatpak is to use the flatpak-builder tool.

Using flatpak-builder

Developers use the flatpak-builder tool together with an SDK image to build application code along with any required libraries. As a developer, you would create a JSON or YAML manifest that lists the sources to build and install flatpak-builder. Then, flatpak-builder would build the source code inside an isolated Flatpak runtime environment. Instead of mounting a normal runtime at /usr, the SDK is mounted instead. The SDK is an extended runtime that contains compilers and other tools necessary to build applications. Each runtime has an accompanying SDK. To build an application for the org.freedesktop.Platform runtime, for instance, you would use the org.freedesktop.Sdk SDK. To build an application for the com.redhat.Platform runtime, you would use the com.redhat.Sdk SDK.

We intend the scope of the RHEL Flatpak SDK to be similar to that of the Freedesktop SDK. This allows developers to easily migrate applications built for the Freedesktop runtime to the RHEL runtime. Almost all the build tools and libraries in the Freedesktop SDK are also available in the RHEL Flatpak SDK.

Building a sample application

As a simple example, we will create a Flatpak of the GHex hex editor. This example is based on github.com/flathub/org.gnome.GHex, but adapted to use the RHEL Flatpak Runtime.

To start, create a directory named org.gnome.GHex. Inside the directory, create a file named org.gnome.GHex.yaml:

app-id: org.gnome.GHex
runtime: com.redhat.Platform
runtime-version: el8
sdk: com.redhat.Sdk
command: ghex
finish-args:
    # X11 + XShm
    - --share=ipc
    - --socket=x11
    # Wayland
    - --socket=wayland
    # Filesystem
    - --filesystem=host
modules:
  - name: ghex
    buildsystem: meson
    sources:
     - type: git
       url: https://gitlab.gnome.org/GNOME/ghex.git
       tag: 3.18.4
       commit: 228094e8d203ab62e49c33df2734fc9628c74775

Install the SDK image:

$ flatpak install rhel com.redhat.Sdk

Build the application:

$ flatpak-builder --repo=repo build-dir org.gnome.GHex.yaml

Install the resulting application:

$ flatpak --user remote-add --no-gpg-verify ghex-el8-repo repo
$ flatpak --user install ghex-el8-repo org.gnome.GHex

And now run it:

$ flatpak run org.gnome.GHex

Conclusion

Flatpak allows application developers to package their application in a way that can be used across Linux operating systems and operating system versions. By using the Flatpak runtime and SDK included with Red Hat Enterprise Linux 8.2, developers can build such applications on top of a familiar platform and take advantage of the Red Hat Enterprise Linux lifecycle. Users who need a stable and supported environment get this from the combination of the runtime with a Red Hat Enterprise Linux host.

For more detail about creating a build manifest for your application, see the Flatpak documentation on building. Also, see Bringing OCI images to the desktop with Flatpak, which describes how Flatpaks work with the OCI images and registries.

Last updated: February 11, 2024