What OSTree Deduplication Means Inside Flatpak
OSTree operates fundamentally as a content-addressed object store, diverging sharply from traditional package management architectures. Every file committed to the repository undergoes processing to generate SHA-256 cryptographic checksums. These calculations produce 256-bit object keys mapping directly to individual files on the disk. This architecture ensures data integrity while enabling deduplication across the entire software ecosystem. Traditional systems rely on external manifest files to track ownership and state. OSTree relies on the intrinsic cryptographic identity of the content itself.
Flatpak utilizes this underlying storage model to manage applications and their complex dependencies. Traditional package managers extract full, isolated directory trees for every installed program, leading to substantial redundancy. Flatpak commits applications and runtimes as OSTree references. When multiple applications require identical files, the system resolves these shared dependencies by creating hard links. These links point directly to the single physical instance of the data residing in the central repository.
Disk cost is dominated by unique runtime objects rather than the raw count of installed applications that share those objects. Deploying about a dozen text editors, media players, or development tools that all target the same base platform requires minimal additional storage. Most storage is consumed during the initial runtime deployment. Subsequent application installations add lightweight metadata and a handful of unique application-specific assets.
How Flatpak Pins Apps to a Shared Object Store
Tracing the path from a high-level Flatpak reference down to the physical disk reveals the mechanics of this shared object store. When an administrator deploys a new application, the system evaluates the required OSTree reference against the local repository. This repository resides under the /var/lib/flatpak/repo/objects/ directory structure. The deployment process identifies which 256-bit object keys are currently missing from the local store by comparing the remote commit against the local state.
The system only downloads and writes the missing objects. If a newly installed application includes library files that match existing objects in the repository, the matching files become additional hard links. The operating system filesystem handles these multiple directory entries pointing to the same underlying inode—a process transparent to the running application. Because Flatpak mounts these filesystems as read-only during application execution, the integrity of the shared hard links remains protected from accidental modification.
Runtime and extension references constitute the primary bulk of these shared objects. Multiple applications pin against these large shared trees to function correctly. As applications update and shift to newer runtime versions, older dependencies become orphaned. Stale runtime objects may persist for about 30 to 60 days before manual garbage collection clears them out.
Deployment Scope Constraints
These observations apply strictly to standard system-wide installations under /var/lib/flatpak, excluding custom user-repo layouts or non-standard installation prefixes.
Where GNOME and KDE Runtimes Overlap on Disk
Administrators frequently deploy applications from both the GNOME Platform/Sdk family and the KDE/Freedesktop runtime lineage. Each of these ecosystems lands as separate OSTree references on the disk. Cross-desktop storage savings appear only where file contents match byte-for-byte.
You will see deduplication across freedesktop.org base libraries, Mesa GL drivers, and common fontconfig caches. These foundational components share identical source code and compilation outputs across different desktop environments. Similar package names across higher-level libraries yield no storage benefits if the compiled binaries differ in any way. A minor version bump in a shared library alters the SHA-256 checksum, resulting in a new object key and duplicating the storage requirement.
Qualitative patterns emerge quickly on production workstations. Many applications built on a single desktop stack share heavily, keeping the overall footprint compact. Mixing GNOME-oriented and KDE-oriented applications grows a second large object set on the disk. The initial installation of a KDE application on a predominantly GNOME system triggers a large download, as the local repository lacks the necessary Qt-based object keys. Subsequent KDE applications will then deduplicate against that newly established runtime.
How Administrators Should Measure the Real Footprint
Administrators sometimes parse the “download size” and “installed size” metadata exposed by remote repositories to estimate disk impact. This metadata does not account for local deduplication state. A remote repository might advertise a large installed size for a complex application, but if the local system already holds most of those specific object keys within an existing runtime, the actual disk impact is negligible.
Measure the OSTree repository and deployment directories directly to understand the real footprint. At the block level, allocation changes should be measured in roughly 4 KB increments to capture physical disk usage. Relying on apparent file sizes will overstate storage consumption due to the extensive use of hard links.
Use a practical sequence to audit storage. List the currently installed references to establish a baseline of active runtimes and applications. Inspect the repository object growth immediately after adding a new runtime or application to observe the delta. Prune unused references by executing flatpak uninstall --unused, followed by running du -shc /var/lib/flatpak/repo to verify the reclaimed space. For deeper technical context on this storage model, review the Flatpak under-the-hood documentation.
Cases Where Deduplication Barely Moves the Needle
Multi-version runtime drift reduces deduplication efficiency. Maintaining concurrent installations of Freedesktop Platform 22.08 and 23.08 leaves large, non-overlapping object sets on the disk. The compilation toolchains and base libraries differ significantly between major releases, resulting in little checksum overlap.
Retaining multiple minor versions of the KDE Application Platform (e.g., 5.15-21.08 through 5.15-23.08) fragments the object store, as compiled binaries differ enough to prevent checksum matching despite identical source code. This fragmentation consumes disk space as applications update at different cadences, pinning older runtimes and preventing garbage collection.
Hard boundaries exist between architecture branches. An x86_64 runtime shares no objects with an aarch64 runtime. Per-user Flatpak installations and system-wide installations maintain separate object stores, preventing deduplication between a user's private applications and the system's global applications.
Proprietary applications frequently bundle private library trees directly in /app/lib. These isolated libraries offer little checksum overlap against public runtimes. Deduplication efficiency drops sharply on build fleets where nightly flatpak-builder runs generate thousands of unique, unpruned commit objects that share no lineage with stable release runtimes.
Developers packaging complex software often statically link dependencies rather than relying on the shared runtime environment. When a popular communication tool statically compiles its own version of WebRTC or custom audio codecs, those binaries bypass the OSTree deduplication engine. The system treats these statically linked blobs as unique objects, even if the same source code exists within the Freedesktop base runtime.
Commit to Runtime Consolidation Before Adding Apps
Standardizing on fewer runtime families generally reclaims more space than removing individual applications. Use the minimum number of runtime families your workload requires before bulk-installing applications.
Administrators managing constrained disks should schedule systemd timer jobs for runtime pruning roughly every 7 to 14 days. Automating this garbage collection prevents stale object keys from accumulating indefinitely. After clearing out unused runtimes and extensions, reinstall only the applications that pin the retained stack.
Commit to strict runtime consolidation to maintain a lean deployment. Standardize your application selection around a single primary desktop environment runtime. Enforce regular garbage collection schedules to eliminate stale object keys. Removing individual applications without maintaining runtime hygiene will not reclaim the bulk of OSTree-held space.
