Ubuntu 26.04 LTS “Resolute Raccoon” shipped on April 23, 2026, built on Linux 7.0 and GNOME 50, with a desktop that runs on Wayland only. The 26.04.1 point release landed just this week, so many people who waited for it are now upgrading. Flatpak is not preinstalled on Ubuntu, but it is fully supported and sits in the standard repositories. You install it with a single apt command. Then you add Flathub and reboot or log out.

Here is a scenario that comes up often. A designer needs the current release of a graphics tool, but the version in the Ubuntu archive is frozen at whatever was current in the spring. The snap is available, but it has a different sandbox model and a different update cadence, and the designer doesn’t want it. Or a team runs a fleet of mixed workstations and wants the same build of an application on Ubuntu, Fedora and Debian. Flatpak covers both cases.

Ubuntu’s own store has also changed. The App Center now shows debs and snaps side by side, and the old Software & Updates application is gone. Its functions moved into App Center and a new Security Center. That is why Flatpak needs a few deliberate steps. Nothing on the default desktop will guide you to it.

This guide covers the full path. It starts with the basic install, then covers system-wide versus per-user setups, permissions, automation, disk usage, troubleshooting and hardening. It also covers when Flatpak is the wrong tool. Each step comes with the reasoning, so you can adapt the commands instead of pasting them blindly.

What Flatpak Does and When to Use It

Flatpak is a distribution-neutral application packaging and sandboxing system. An application ships with a runtime, a shared set of libraries such as the GNOME or KDE platform. Anything else it needs is bundled inside the app. The app runs in a sandbox, and you grant access to the filesystem, network, devices and session services through permissions.

This differs from apt in a way that matters operationally. A deb depends on the libraries of the host distribution, so the package must be rebuilt for each release. A Flatpak carries its own dependencies. The upstream developer can publish one build and reach every distribution that supports Flatpak.

Flatpak vs Snap vs APT on Ubuntu

The right tool depends on the job. Nginx, PostgreSQL, PHP-FPM and anything that binds to a port on a production box belongs in apt, or in a container if you need version isolation. Flatpak is built for graphical desktop applications. Trying to run server daemons through it creates more problems than it solves.

For desktops, though, it is a strong choice. You get newer application versions than the Ubuntu archive offers, and the sandbox limits what a misbehaving app can touch. You can also keep the base system on the LTS release while application versions move independently.

Prerequisites and Pre-Flight Checks

Verify the basics before installing anything. It takes about thirty seconds and saves debugging later.

Confirm the release:

lsb_release -a
cat /etc/os-release

You should see Ubuntu 26.04 and the codename resolute. Then check that the system is current and has enough free space:

sudo apt update
sudo apt full-upgrade -y
df -h / /var /home

Space deserves attention. Flatpak’s system-wide store lives under /var/lib/flatpak, and a per-user store lives under ~/.local/share/flatpak. A single large runtime such as the GNOME or KDE platform can run to several hundred megabytes, and each app adds its own data on top. On a machine with a small /var partition, that fills up faster than you would expect. Plan for at least 5 GB free for a light setup, and more if you plan to install heavy applications such as office suites, video editors or IDEs.

Check whether Flatpak is already there (some derivatives ship it):

flatpak --version

If the shell says the command is not found, continue to the next section.

Step-by-Step: Install Flatpak on Ubuntu 26.04

Step 1: Install the Flatpak Package

The flatpak package is in the Ubuntu repositories, so no extra sources are needed:

sudo apt update
sudo apt install flatpak

Confirm the install:

flatpak --version
which flatpak

The command should print a version number and the path /usr/bin/flatpak. There is a PPA that offers newer Flatpak builds, and some guides compare it against the archive package. For most systems the archive version is the right pick. It receives security updates through the normal Ubuntu channels. A PPA is worth considering only if you need a specific fix that hasn’t reached the archive.

Step 2: Install the GNOME Software Plugin (Desktop Only)

On a desktop, you may want to install and update Flatpak apps from a graphical store. Flathub’s official Ubuntu instructions use gnome-software-plugin-flatpak for this.

There is a wrinkle on 26.04. Ubuntu’s default store is App Center, which is snap-focused and does not manage Flatpaks. If you want a store that shows Flatpaks, install GNOME Software alongside it. A community-recommended command installs GNOME Software with the Flatpak plugin and leaves out the snap plugin, so the two ecosystems don’t compete inside one interface:

sudo apt install gnome-software gnome-software-plugin-snap- gnome-software-plugin-flatpak

The trailing minus after gnome-software-plugin-snap tells apt to skip that package. If you want the snap plugin too, drop that piece:

sudo apt install gnome-software gnome-software-plugin-flatpak

On a headless server or a minimal workstation, skip this step. The command line is all you need, and GNOME Software pulls in a lot of dependencies.

Step 3: Add the Flathub Repository

Flatpak by itself has no application source configured. Flathub is the main public remote, and you add it with one command:

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

The --if-not-exists flag makes the command safe to repeat, which is handy in provisioning scripts. Run with sudo, it registers Flathub system-wide, so every user on the machine can install from it.

If you want a strictly personal setup, add the remote at user scope instead:

flatpak remote-add --user --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Verify the result:

flatpak remotes --show-details

Look for flathub in the list, with the correct URL and the scope (system or user) you intended.

Step 4: Log Out or Reboot

The official setup finishes with a restart. There is a real reason for this. Flatpak adds export directories to XDG_DATA_DIRS through a profile script, and your session only reads that at login. Until then, installed apps may not appear in the launcher, even though they run fine from the terminal.

On a workstation, logging out and back in is usually enough. If you want a clean slate:

sudo reboot

Step 5: Install and Run Your First Application

Test the whole chain with a small app:

flatpak install flathub org.gnome.Calculator
flatpak run org.gnome.Calculator

Flatpak first pulls in the required runtime, then the app. It lists everything it will download and asks for confirmation. Add -y to skip the prompt in scripts:

flatpak install -y flathub org.mozilla.firefox

The app ID is the reverse-domain name, like org.mozilla.firefox. Search for it before you install, since the display name and the ID often differ:

flatpak search "video editor"

You can also browse Flathub in a web browser and copy the install command from the app page.

System-Wide vs Per-User Installation

This is where experienced admins make decisions that beginners skip. Flatpak has two installation scopes, and mixing them is one of the most common sources of confusion later.

System-wide installs go to /var/lib/flatpak. Every user sees the same apps and runtimes. The benefit is disk efficiency, because shared runtimes are stored once. The cost is that installs and updates require root, or a polkit authentication prompt.

Per-user installs go to ~/.local/share/flatpak. Only that user sees them, no root is needed, and each user carries their own copy of shared runtimes. On a multi-user machine that duplication adds up quickly.

A practical rule of thumb:

• Shared workstations, lab machines and classroom setups: system-wide.
• Single-user laptops where you want to avoid sudo: either works. System-wide saves space if you ever add a second account.
• Locked-down environments where users cannot get root: per-user, provided policy allows it.

Flatpak commands accept --system and --user flags to make the scope explicit:

flatpak install --system flathub org.libreoffice.LibreOffice
flatpak install --user flathub org.videolan.VLC
flatpak list --app --columns=application,installation

The installation column shows which scope each app lives in. If an app seems to be missing, check the other scope before reinstalling. A remote added with --user is invisible to a --system install, and vice versa. That mismatch is the cause of many “No remote refs found” complaints.

Everyday Flatpak Commands Worth Memorizing

A handful of commands cover about 95 percent of daily use.

flatpak list                      # everything installed, runtimes included
flatpak list --app                # apps only
flatpak info org.mozilla.firefox  # version, origin, permissions, size
flatpak update                    # update all apps and runtimes
flatpak uninstall org.mozilla.firefox
flatpak uninstall --unused        # remove orphaned runtimes
flatpak run org.mozilla.firefox   # launch from the terminal
flatpak ps                        # running Flatpak instances
flatpak kill org.mozilla.firefox  # stop a stuck app

flatpak uninstall --unused deserves regular use. Removing an app does not remove its runtime. Over months, old runtime versions pile up, particularly after major GNOME or KDE platform bumps. Running the cleanup once a month keeps /var/lib/flatpak from ballooning.

To keep a specific version, mask updates or pin a commit:

flatpak mask org.example.App
flatpak update --commit=<hash> org.example.App

Pinning matters when an update breaks a workflow and you need the previous build while upstream fixes it. Find older commits with flatpak remote-info --log flathub org.example.App.

Permissions and Sandboxing in Practice

The sandbox is the main reason to choose Flatpak over a plain deb. It is only as good as the permissions you leave in place, though.

Inspect what an app can do:

flatpak info --show-permissions org.mozilla.firefox

You will see entries for sockets (X11, Wayland, PulseAudio), devices, filesystem paths and session bus access. Some apps ask for broad access such as --filesystem=host or --filesystem=home. That is sometimes necessary, since a file manager or an IDE is not much use without file access. Sometimes it is just convenience on the packager’s side.

Tighten permissions per app with overrides:

flatpak override --user --nofilesystem=home org.example.App
flatpak override --user --filesystem=~/Documents/Shared org.example.App
flatpak override --user --unshare=network org.example.App

Check your overrides:

flatpak override --user --show org.example.App

Reset them if things go wrong:

flatpak override --user --reset org.example.App

Prefer a graphical tool? Flatseal is a popular permissions manager, available on Flathub as com.github.tchx84.Flatseal. It is useful when you need to adjust many apps and don’t want to memorize flags.

One practical observation: if an app can’t see a folder on an external drive, or a USB device doesn’t show up, the sandbox is the first suspect. Grant the specific path or device rather than switching everything to host. Least privilege is boring advice, but it is the whole point of using a sandbox.

Wayland and Ubuntu 26.04

Ubuntu 26.04 has no X11 GNOME session at all. Most current Flatpak apps handle Wayland natively, and the rest fall back to XWayland. If an older app misbehaves, look at its socket permissions:

flatpak info --show-permissions org.example.App | grep -i socket

Apps that request fallback-x11 will use XWayland when Wayland is unavailable. If one app renders blurry text or has drag-and-drop issues, try forcing the Wayland socket with an override:

flatpak override --user --socket=wayland org.example.App

Behavior varies by application and toolkit. Test it, and revert with --reset if it makes things worse. Screen sharing, screenshots and global shortcuts go through XDG desktop portals, so the xdg-desktop-portal-gnome package must be present. It is installed by default on standard Ubuntu desktops.

Keeping Flatpak Apps Updated

Snaps refresh themselves. Debs update through apt and Ubuntu’s unattended-upgrades. Flatpak does neither out of the box unless you use GNOME Software, which checks for updates in the background on a desktop. On a machine without that, updates happen only when you run flatpak update.

That gap is easy to forget, and it is a genuine security concern. A sandboxed browser with a months-old engine is still a browser with known vulnerabilities.

Automating Updates with a systemd Timer

For workstations and shared machines, a systemd timer is cleaner than cron. Create the service unit:

sudo tee /etc/systemd/system/flatpak-update.service > /dev/null <<'EOF'
[Unit]
Description=Update system Flatpak applications
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/flatpak update --system --noninteractive --assumeyes
ExecStartPost=/usr/bin/flatpak uninstall --system --unused --noninteractive --assumeyes
Nice=10
IOSchedulingClass=idle
EOF

Then the timer:

sudo tee /etc/systemd/system/flatpak-update.timer > /dev/null <<'EOF'
[Unit]
Description=Daily Flatpak update

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target
EOF

Enable it:

sudo systemctl daemon-reload
sudo systemctl enable --now flatpak-update.timer
systemctl list-timers flatpak-update.timer

A few choices here are deliberate. Nice=10 and IOSchedulingClass=idle keep the job from competing with real work if a machine is in use at 03:30. RandomizedDelaySec spreads load across a fleet. If fifty machines all hit Flathub on the same minute, you create your own traffic spike. Persistent=true catches up on a missed run if the machine was off.

Check the outcome:

journalctl -u flatpak-update.service --since today

Per-user installs need a matching user timer under ~/.config/systemd/user/, using --user in the command.

One caution for shared environments: auto-updating everything overnight can change an application the morning before a deadline. If stability matters more than freshness, mask critical apps and update them on your own schedule.

Performance Tuning and Resource Considerations

Flatpak is not heavy, but it has a footprint you should understand.

Disk I/O and Storage

Flatpak uses OSTree, which stores files as content-addressed objects and hard-links them into deployments. This deduplicates identical files across runtimes and apps. Updates download only the changed objects, so a routine update is often much smaller than the full app.

Measure it:

du -sh /var/lib/flatpak
du -sh ~/.local/share/flatpak
du -sh ~/.var/app/*

The last path is important. Per-app user data (configs, caches) lives in ~/.var/app/<app-id>/. Uninstalling an app leaves it behind unless you delete it explicitly:

flatpak uninstall --delete-data org.example.App

For servers or VMs with tight storage, put /var/lib/flatpak on its own partition or logical volume. That stops a runaway install from filling the root filesystem. With LVM it is a two-minute job, and it makes disk monitoring much simpler.

On SSDs and NVMe storage, the many small files OSTree writes are not a problem. On old spinning disks, the first install of a big runtime feels slow. Schedule bulk installs for off hours and use ionice if the machine is doing other work:

sudo ionice -c3 nice -n 10 flatpak install -y flathub org.kde.Platform//6.8

RAM and CPU

Sandboxing itself adds little CPU overhead, because bubblewrap uses kernel namespaces rather than virtualization. Memory use is dominated by the application. One point to keep in mind: two apps built against different runtime versions load different copies of shared libraries. Twenty apps on twenty different runtimes will use more RAM and disk than twenty debs sharing system libraries. Standardizing on a few runtime versions keeps things tidy.

The first launch after an update can feel slower. Font caches, shader caches and icon caches are rebuilt. This is normal and passes after the first run.

Network

Flathub serves content through a CDN, and downloads are usually fast. On constrained links, or when many machines pull the same updates, consider a local mirror or a pre-seeded repository. Flatpak supports offline installs from a local repo or from a .flatpak bundle, and you can create a mirror with flatpak create-usb or ostree-based tooling. For a fleet of more than a dozen desktops, this saves noticeable bandwidth.

For a proxy environment, Flatpak honors the standard proxy variables in most cases, but the system helper runs as a service. If installs fail behind a proxy, set the proxy for the system helper via a systemd drop-in:

sudo systemctl edit flatpak-system-helper.service

Add:

[Service]
Environment="http_proxy=http://proxy.example.local:3128"
Environment="https_proxy=http://proxy.example.local:3128"

Then reload:

sudo systemctl daemon-reload
sudo systemctl restart flatpak-system-helper.service

Troubleshooting Common Flatpak Errors

Most problems fall into a few categories. Work through them in order.

Apps Don’t Appear in the Menu

The usual cause is a session that started before Flatpak’s environment was set up. Log out and back in, or reboot. If that doesn’t help, check the data directories:

echo $XDG_DATA_DIRS | tr ':' '\n' | grep -i flatpak

You should see paths such as /var/lib/flatpak/exports/share and ~/.local/share/flatpak/exports/share. If they are missing, confirm the file /etc/profile.d/flatpak.sh exists (it is created by the package). A minimal, non-standard shell setup can skip it.

“No remote refs found” or “Remote ‘flathub’ not found”

This is almost always a scope mismatch. The remote was added at one scope, and the install command is targeting the other. Compare:

flatpak remotes --system
flatpak remotes --user

Then either add the remote at the right scope or pass --system or --user to your install. If the remote exists but the app can’t be found, refresh metadata:

flatpak update --appstream

TLS, Certificate or Download Errors

Messages such as “Unable to load summary” or SSL failures often come from three places: wrong system time, a proxy that intercepts TLS, or a temporary network problem. Check the clock first:

timedatectl status

If NTP sync is off, fix it:

sudo timedatectl set-ntp true

Behind a corporate proxy, set up the drop-in shown earlier and make sure the proxy’s CA certificate is installed in the system trust store with update-ca-certificates. Then retry with verbose output:

flatpak install -vv flathub org.example.App

Corrupted Repository or Failed Install

An interrupted download or a power loss can leave the local repo in a bad state. Flatpak includes a repair command:

sudo flatpak repair --system
flatpak repair --user

It verifies objects and reinstalls whatever is broken. Run it before doing anything drastic.

“Not enough disk space”

Check where the space is going:

df -h /var
flatpak uninstall --unused
du -sh /var/lib/flatpak/repo /var/lib/flatpak/runtime /var/lib/flatpak/app

If /var is simply too small, move or resize it. Deleting random files under /var/lib/flatpak by hand is a bad idea and usually makes things worse. Use flatpak repair afterward if you suspect damage.

Permission Denied or Polkit Prompts Failing

Over SSH or in a session with no polkit agent, graphical authentication fails. Use sudo flatpak ... with --system, or switch to --user installs. On desktops, confirm a polkit agent is running:

ps aux | grep -i polkit | grep -v grep

Files or Devices Inaccessible Inside an App

Give the app the exact access it needs, as covered in the permissions section. For example, to allow a media player to read an external drive:

flatpak override --user --filesystem=/media/$USER org.videolan.VLC

Fonts, Themes or Cursor Look Wrong

Flatpak apps don’t automatically use your host GTK or Qt theme. Install the matching theme as a Flatpak (search flatpak search gtk3-theme or the relevant KDE style), or set an override to expose your theme directories:

flatpak override --user --filesystem=xdg-config/gtk-3.0:ro
flatpak override --user --filesystem=xdg-config/gtk-4.0:ro

App Crashes on Launch

Launch it from the terminal to see the error output:

flatpak run --verbose org.example.App

Then try, in order: resetting overrides, clearing the app’s data (after backing it up), and finally reinstalling. Also check whether the problem is tied to a recent update. If it is, rolling back with flatpak update --commit=<hash> buys time.

Conflict with GNOME Software or App Center

Ubuntu 26.04 has changed how software management works, and App Center focuses on debs and snaps. If you don’t see your Flatpaks there, that is expected. Use GNOME Software with the Flatpak plugin, or the command line. Running two graphical stores is fine, but they won’t share a view of every package format.