The missing app problem
You just switched to Fedora and want to install a popular desktop application. The app is not in the default repositories, or the version available through the package manager is significantly outdated. You search for a solution and find a reference to Flatpak. You try to run the installation command and the terminal immediately complains about a missing remote. You need the sandboxed runtime environment and the central application catalog before you can proceed.
What is actually happening
Flatpak is not a simple package format. It is a complete application distribution system built around strict isolation. Every Flatpak application runs inside a sandbox that restricts access to the host filesystem, network stack, and hardware devices. The application only receives access to specific resources through a portal system. Portals act as controlled gateways for file dialogs, web browsing, and device access. This design prevents applications from silently reading your home directory or modifying system files.
Flathub serves as the centralized repository for these sandboxed applications. It hosts the application bundles alongside their shared runtimes. Runtimes contain the base libraries and frameworks that multiple applications can share. This means you do not need to download a separate copy of GTK or Qt for every single program. Fedora ships with the Flatpak command-line tools disabled by default. The distribution keeps the base system lean and relies on traditional RPM packages for core utilities. Adding the Flathub remote tells your system exactly where to fetch the application bundles and how to verify their cryptographic signatures.
The sandbox model changes how updates work. Traditional RPM packages update alongside the operating system. Flatpak applications update independently. You can run a major Fedora release upgrade without touching your sandboxed apps. You can also update a single Flatpak app without rebooting or risking dependency conflicts. The tradeoff is that sandboxed apps cannot access host libraries directly. They must bundle everything they need or request access through portals. This isolation is the feature, not a bug. It stops broken dependencies from taking down your desktop.
Setting up the runtime and repository
The installation process requires two distinct steps. First, you install the Flatpak command-line interface and the underlying runtime libraries. Second, you register the Flathub repository as a trusted remote source. Run the following commands in your terminal.
sudo dnf install flatpak
# dnf pulls the flatpak package and its dependencies from Fedora's official repos
# The package provides the CLI, the sandboxing daemon, and the portal integration
# sudo is required because system-wide installations write to /usr/lib and /var/lib
The base package is now installed. You still cannot download applications because the system does not know where to look. Add the Flathub remote with the next command.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# remote-add registers a new repository source with the flatpak configuration
# --if-not-exists prevents the command from failing if you already added it previously
# The URL points to the official Flathub metadata file containing GPG keys and branch info
Flatpak stores system-wide configuration in /var/lib/flatpak/repo/. User-specific installations live in ~/.local/share/flatpak/. The command above registers the remote for all users on the machine. This is the standard approach for desktop workstations. If you are managing a shared server where users should not install desktop applications, skip this step entirely. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The same principle applies to Flatpak configuration directories. Let the tools manage the metadata.
Verifying the configuration
Run the remote list command to confirm the repository is registered correctly.
flatpak remotes
# Lists all configured remotes and their priority levels
# A successful setup shows flathub with a priority of 1 or higher
# Missing output means the remote-add command failed silently or was run with incorrect permissions
You should see flathub in the output. The next step is to refresh the package index. Flatpak does not cache the full repository metadata until you explicitly request it. Run an update to pull the current application list.
flatpak update
# Downloads the latest metadata from all configured remotes
# This step is required before installing any application for the first time
# The command will report nothing to update if you have not installed apps yet
Restart your graphical session after adding the remote. The Flatpak portal integration hooks into your desktop environment at login. A fresh session ensures that file dialogs and device access requests route correctly through the sandbox. Reboot before you debug. Half the time the symptom is gone.
Managing permissions and updates
Flatpak applications request access to specific directories through portals. A file dialog will show a restricted view by default. Click the parent directory button to expand access. This behavior is intentional. The sandbox prevents background scanning of your entire home folder. You can inspect and modify permissions for any installed app using the flatpak override command.
flatpak override --user --talk-name=org.freedesktop.secrets com.example.App
# --user scopes the override to your account instead of applying it system-wide
# --talk-name grants the app permission to communicate with a specific D-Bus service
# The final argument specifies the exact application ID to modify
Use --user overrides when testing permissions or troubleshooting a single application. System-wide overrides affect every user on the machine and can introduce security gaps. Run flatpak override --show com.example.App to see the current permission matrix. The output shows which directories, devices, and D-Bus names the app can access. Remove unnecessary permissions with --unset. Trust the package manager. Manual file edits drift, snapshots stay.
Updates follow a different cadence than system packages. dnf upgrade --refresh is the normal weekly maintenance command for RPM packages. flatpak update handles sandboxed applications. They do not interfere with each other. You can safely run both commands in the same terminal session. The only overlap occurs when an app exists in both formats. The desktop environment will prioritize the native RPM version for menu integration. This causes confusion when updates only apply to one version. Remove the native package if you intend to use the sandboxed variant. Run journalctl first. Read the actual error before guessing.
Common pitfalls and error patterns
The most frequent issue involves desktop integration failing to recognize newly installed applications. If you install an app and it does not appear in your application menu, log out and log back in. The desktop environment caches the available applications at session start. The cache does not update dynamically for sandboxed apps.
You may also encounter permission prompts that look alarming. Flatpak applications request access to specific directories through portals. A file dialog will show a restricted view by default. Click the parent directory button to expand access. This behavior is intentional. The sandbox prevents background scanning of your entire home folder.
Conflicting installations happen when you install the same application through both DNF and Flatpak. The system will prioritize the native RPM version for desktop integration. This causes confusion when updates only apply to one version. Remove the native package if you intend to use the sandboxed variant.
Error: Cannot install app with ID com.example.App: No such remote 'flathub'
This error appears when the remote configuration file is missing or corrupted. Re-run the remote-add command. Check /etc/flatpak/remotes.d/ if the command succeeds but the remote still does not appear. Manual edits to that directory rarely work because Flatpak validates the GPG signature on the metadata file. Trust the package manager. Manual file edits drift, snapshots stay.
Another common failure involves missing runtimes. Flatpak applications declare which runtime they require. If the runtime is not installed, the application will refuse to launch. The error message will explicitly name the missing runtime ID. Install it with flatpak install flathub <runtime-id>. The runtime installation happens automatically during the first app install, but network interruptions or disk space shortages can break the process. Check available disk space before installing large applications. Snapshot the system before the upgrade. Future-you will thank you.
When to use Flatpak versus alternatives
Use Flatpak when you want a sandboxed desktop application that updates independently of the operating system release cycle. Use DNF when you need system utilities, kernel modules, or applications that require deep integration with host services. Use RPM Fusion when you require proprietary codecs or hardware drivers that Fedora cannot distribute legally. Use native tarballs or AppImage when you need a completely self-contained binary that ignores system libraries entirely. Stay on the upstream Fedora repositories if you only deviate from the defaults occasionally.