How to List Installed Flatpak Apps and Runtimes
You installed a dozen Flatpak applications over the last few months. You need to find the exact ID for one of them, or you are running low on disk space and want to see what is actually consuming your storage. You type flatpak list and get a table back. It looks fine until you notice half the entries are labeled as runtimes, some apps live in /var/lib/flatpak, and others are tucked away in your home directory. The output gives you data, but it does not explain the layout.
What is actually happening
Flatpak does not install packages the way dnf does. It does not drop binaries into /usr/bin or libraries into /usr/lib. It builds isolated filesystem trees and stores them in a local registry. Every entry in that registry has an application ID, a branch, and a scope. The scope determines whether the installation belongs to the entire machine or just your user account.
Runtimes are the shared base environments. They contain GTK, Qt, system libraries, and common dependencies. Applications are the actual software binaries that sit on top of those runtimes. When you run flatpak list, you are querying the local metadata database. The command does not contact Flathub or any remote repository. It reads what is already on disk.
Think of it like a library. The runtimes are the reading rooms with the furniture and lighting. The applications are the books. You can have multiple reading rooms open at once. You can also have multiple editions of the same book. Flatpak keeps them separate so one update does not break another program.
Fedora ships with Flatpak enabled by default. The system stores admin-managed software in /var/lib/flatpak. Your personal installations go to ~/.local/share/flatpak. Configuration files follow the same split. System remotes live in /etc/flatpak/remotes.d/. User remotes live in ~/.config/flatpak/remotes/. Edit the user directory for personal changes. Leave the system directory alone unless you are managing a shared workstation.
Check the registry before you guess. Flatpak metadata updates independently of dnf. Run flatpak update to refresh the local index before auditing.
The fix and how to query the registry
Start with the default view to see everything Flatpak knows about.
Here is how to list all installed applications and runtimes in a readable table.
flatpak list
# Queries the local Flatpak registry
# Prints Application ID, Branch, and Installation path
# Default scope is user-local unless overridden
The output separates apps and runtimes visually, but the column headers can be misleading. The "Application" column actually shows the reverse-DNS style ID. The "Branch" column shows the release track, which is almost always stable on Fedora. The "Installation" column shows the storage scope. If you only care about the shared libraries, filter the view to runtimes.
Here is how to isolate the base environments and dependencies.
flatpak list --runtime
# Filters the registry to show only runtime entries
# Useful for auditing shared library versions
# Does not affect installed application binaries
Runtimes are named like org.gnome.Platform or org.kde.Platform. They follow a versioned branch scheme. You will often see multiple versions of the same runtime installed side by side. Flatpak keeps them around because older applications might still depend on them. You can safely remove orphaned runtimes later.
If you need to verify which runtime a specific application relies on, inspect its metadata directly.
Here is how to check the exact runtime dependency for a single application.
flatpak info org.gnome.Calendar
# Fetches local metadata for the specified app ID
# Prints the Runtime field near the top of the output
# Confirms the dependency chain without network access
Replace the example ID with your target application. The output will list the Runtime field explicitly. This tells you which base environment the app expects. If the runtime is missing, the app will refuse to launch and print a dependency error.
When you are writing scripts or piping output into grep, the default table format gets in the way. Switch to machine-readable mode.
Here is how to extract only the application IDs for scripting.
flatpak list --columns=application
# Dumps a plain list of IDs without table formatting
# Each ID appears on a new line
# Safe to pipe into grep, awk, or xargs
You can combine this with standard shell tools to find specific packages. If you are managing a shared workstation or a server, you need to distinguish between system-wide and user-specific installations. Flatpak stores them in separate directories.
Here is how to query the system-wide installation scope.
flatpak --system list
# Targets /var/lib/flatpak instead of the user directory
# Requires no root privileges for reading metadata
# Shows apps installed by the package manager or admin
Here is how to query your personal installation scope explicitly.
flatpak --user list
# Targets ~/.local/share/flatpak
# Shows apps you installed without sudo
# Default behavior when no scope flag is provided
The system scope lives under /var/lib/flatpak. The user scope lives under ~/.local/share/flatpak. Fedora's default configuration keeps user installations separate to avoid permission conflicts. You do not need sudo to read either scope. You only need sudo when installing to the system scope or modifying system-level permissions.
Run the list command once. Memorize the ID format. Reverse-DNS naming is not optional.
Verify it worked
Run the list command and cross-reference the output with your file system. Check that the paths match the scope you expect. Verify that the runtime versions align with the applications you installed. If you cleaned up unused runtimes, confirm that the disk space actually freed up.
Here is how to verify disk usage after a cleanup.
du -sh ~/.local/share/flatpak
# Calculates total size of the user Flatpak directory
# Shows human-readable output in megabytes or gigabytes
# Confirms whether orphaned runtimes were actually removed
Compare this number with the output from flatpak list --runtime. If the sizes do not match, check the system scope directory as well. Flatpak caches download artifacts in ~/.cache/flatpak. Clearing that cache can reclaim additional space.
Here is how to inspect the download cache size.
du -sh ~/.cache/flatpak
# Measures temporary download storage
# Safe to remove if you are short on disk space
# Flatpak will redownload files on next install
Fedora's package manager handles system updates. Flatpak handles sandboxed application updates. They do not share a transaction database. Run flatpak update after dnf upgrade --refresh to keep both ecosystems synchronized.
Check the actual directory sizes. Metadata lies, disk usage does not.
Common pitfalls and what the error looks like
The most common mistake is confusing the display name with the application ID. The Flatpak command line only accepts the reverse-DNS ID. If you type flatpak info Calendar, you will get an error.
Error: No remote matches 'Calendar'
The error message says "remote" because Flatpak tries to interpret unknown strings as repository names first. Always use the full ID like org.gnome.Calendar.
Another pitfall is branch mismatch. Some development builds use the master or nightly branch. If you install an app from a third-party remote, it might pull a runtime that conflicts with your system defaults. Flatpak will refuse to downgrade a runtime if another app depends on the newer version. You will see a transaction error that looks like this:
Error: Cannot uninstall runtime org.gnome.Platform//43 because it is still in use by org.gnome.Calendar
Do not force the removal. The dependency chain is intact for a reason. Update the dependent application first, then run the cleanup command.
A third issue is scope confusion. If you install an app with sudo flatpak install, it goes to the system scope. If you later try to update it without sudo, Flatpak will complain that it cannot modify the system directory. Always match the installation scope with the update command. Use flatpak update for user apps. Use sudo flatpak update for system apps.
When an app fails to launch, check the journal before reinstalling. Flatpak logs sandbox violations and permission denials directly to systemd.
Here is how to find recent Flatpak launch errors.
journalctl -xeu flatpak
# Filters systemd logs for Flatpak service activity
# Shows sandbox permission denials and runtime failures
# Use the x flag for explanatory context lines
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux or adding broad policy overrides. Most launch failures are missing portal permissions, not security policy blocks.
Read the journal before you reinstall. The error tells you exactly which permission is missing.
When to use this vs alternatives
Use flatpak list when you need a quick inventory of what is installed on the machine. Use flatpak list --runtime when you are auditing shared dependencies or preparing for a disk cleanup. Use flatpak info <app-id> when you need to verify the exact runtime version or check the application metadata. Use flatpak --system list when you are managing a shared workstation and need to see admin-installed software. Use flatpak uninstall --unused when you have removed applications and want to reclaim space from orphaned runtimes. Use du -sh ~/.local/share/flatpak when you need to measure actual disk consumption rather than metadata.
Trust the registry output. Manual file inspection drifts, the database stays accurate.