The missing app store
You just installed Fedora Workstation. The desktop is clean, the terminal works, and dnf handles your base system packages without complaint. Then you try to install Discord, Spotify, or a specific creative tool. The default GNOME Software window shows a handful of apps, but the one you want is missing. You search the terminal, run dnf install discord, and get a package not found error. The app exists, but it lives outside the official Fedora repositories. You need Flathub.
How Flatpak and Flathub actually work
Fedora ships with flatpak preinstalled, but it starts with an empty remote list. A remote is just a URL pointing to a repository of sandboxed applications and their shared runtimes. Flathub is the community-maintained remote that hosts thousands of desktop apps. Think of it like a CDN for desktop software. Instead of compiling from source or trusting a random binary from a third-party site, you pull a verified, sandboxed bundle that runs in an isolated environment.
Flatpak separates applications from their dependencies. An app like org.gimp.GIMP bundles its own GTK version, but it shares a common org.gnome.Platform runtime with other GNOME apps. This keeps the base system clean and prevents dependency hell. When you install a Flatpak, the files land in either /var/lib/flatpak for system-wide access or ~/.local/share/flatpak for your user account. The sandbox restricts network and filesystem access unless the app explicitly requests permissions or you grant them through GNOME Software or flatpak override.
Fedora's package management philosophy treats the base system and desktop apps as separate concerns. dnf manages the kernel, system libraries, and core utilities. Flatpak manages user-facing applications that change faster than the OS release cycle. They do not interfere with each other. A botched Flatpak installation cannot break your boot process. A broken dnf transaction can. Keep them in their lanes.
Run flatpak --version to confirm the client is active before adding remotes.
Add Flathub and install your first app
Open a terminal and run the remote addition command. The --if-not-exists flag prevents duplicate entries if you accidentally run it twice. The command requires root privileges because it modifies the system-wide remote configuration.
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
# --if-not-exists prevents duplicate remote errors
# flathub is the local alias you will reference in future commands
# the URL points to the official Flathub repository manifest
Next, install GNOME Software's Flatpak integration and a test application. GNOME Software provides the graphical interface that most desktop users expect. It handles permission prompts, updates, and sandbox management without requiring terminal commands.
flatpak install flathub org.gnome.Software
# pulls the Flatpak version of GNOME Software from the flathub remote
# the first run will prompt to install required runtimes
# accept the prompts to download the shared GNOME platform
Restart GNOME Software after the installation finishes. The app store will now show a significantly larger catalog. You can browse, search, and install apps directly from the GUI. The terminal remains the fastest path for scripted deployments or headless servers.
Convention aside: flatpak update is the normal weekly maintenance command for sandboxed apps. dnf upgrade handles the base system. They are different commands. Run them separately to keep your system predictable.
Verify the remote registration before installing production workloads.
Verify the remote and installed apps
Confirm that Flathub is registered and check what is currently installed. The remote-list command shows all configured sources, while list displays your local app inventory.
flatpak remote-list
# prints all configured remotes and their URLs
# verify that flathub appears with the correct dl.flathub.org address
# an empty output means the remote failed to register
flatpak list
# shows installed applications and their associated runtimes
# check the origin column to confirm apps came from flathub
# runtimes appear with a type of runtime instead of app
If the remote shows up but apps fail to download, your firewall might be blocking outbound connections to dl.flathub.org. Flatpak uses standard HTTPS traffic on port 443. Run curl -I https://dl.flathub.org/repo/flathub.flatpakrepo to verify connectivity before troubleshooting the package manager.
User-level installations skip the sudo requirement and land in ~/.local/share/flatpak. System-level installations land in /var/lib/flatpak and require root. Choose user-level for personal laptops and system-level for shared workstations. The package manager tracks both locations independently.
Check the remote list before debugging download failures.
Common pitfalls and error messages
Flatpak errors usually fall into three categories: missing runtimes, permission denials, or stale caches. The most frequent blocker is a missing platform runtime. When you install an app, Flatpak checks for the required runtime. If it is absent, the installation pauses and waits for confirmation.
Required runtime not found: org.gnome.Platform/x86_64/44
Install runtime 'org.gnome.Platform/x86_64/44' from 'flathub'? [Y/n]:
Press Y and hit enter. The runtime download can take several minutes depending on your connection speed. Do not interrupt it. A partial runtime will cause every app that depends on it to fail.
Permission errors appear when an app tries to access hardware or directories outside the sandbox. The error usually reads Flatpak app failed to start or shows a generic crash dialog. Check the actual logs instead of guessing.
flatpak run --command=bash org.gnome.Software
# drops you into the app's sandbox for debugging
# use this to test network access or file permissions manually
# exit the sandbox when you are done to avoid leaving a lingering shell
Stale cache issues happen after a network interruption or a corrupted download. Clear the local cache and retry.
flatpak uninstall --unused
# removes runtimes that no installed app requires
# frees disk space and resolves version mismatch errors
# does not touch your actual applications or user data
flatpak update
# refreshes the remote metadata and upgrades installed apps
# run this weekly to keep sandboxed apps patched
# equivalent to dnf upgrade but scoped to Flatpak packages
When an app crashes repeatedly, run flatpak repair to fix broken symlinks and stale metadata. The command scans the local Flatpak database and rebuilds broken references. It runs in seconds and rarely causes issues.
Run flatpak repair before reinstalling. Half the time the symptom is gone.
Flatpak versus RPM versus Snap
Use RPM when you need tight integration with the base system, kernel modules, or low-level services. Use Flatpak when you want sandboxed desktop applications that update independently of the OS release cycle. Use Snap when you are running Ubuntu or Debian and cannot switch package managers. Stay on native RPMs for system utilities like vim, curl, or networkmanager. Trust the package manager. Manual file edits drift, snapshots stay.