RunsOn​

In the initial announcement, I mentioned we were using RunsOn, a just-in-time runner provisioning system, to build large apps such as Chromium. Since then, we have fully switched to RunsOn for all builds. Free GitHub runners available to open source projects are heavily overloaded and there are limits on how many concurrent builds can run at a time. With RunsOn, we can request an arbitrary number of threads, memory and disk space, for less than if we were to use paid GitHub runners.

We also rely more on spot instances, which are even cheaper than the usual on demand machines. The downside is that jobs sometimes get interrupted. To avoid spending too much time on retry ping-pong, builds retried with the special bot, retry command use the on-demand instances from the get-go. The same catch applies to large builds, which are unlikely to finish in time before spot instances are reclaimed.

The cost breakdown since May 2025 is as follows:

Once again, we are not actually paying for anything thanks to the AWS credits for open source projects program. Thank you RunsOn team and AWS for making this possible!

Caching​

Vorarbeiter now supports caching downloads and ccache files between builds. Everything is an OCI image if you are feeling brave enough, and so we are storing the per-app cache with ORAS in GitHub Container Registry.

This is especially useful for cosmetic rebuilds and minor version bumps, where most of the source code remains the same. Your mileage may vary for anything more complex.

End-of-life without rebuilding​

One of the Buildbot limitations was that it was difficult to retrofit pull requests marking apps as end-of-life without rebuilding them. Flat-manager itself exposes an API call for this since 2019 but we could not really use it, as apps had to be in a buildable state only to deprecate them.

Vorarbeiter will now detect that a PR modifies only the end-of-life keys in the flathub.json file, skip test and regular builds, and directly use the flat-manager API to republish the app with the EOL flag set post-merge.

Web UI​

GitHub's UI isn't really built for a centralized repository building other repositories. My love-hate relationship with Buildbot made me want to have a similar dashboard for Vorarbeiter.

The new web UI uses PicoCSS and HTMX to provide a tidy table of recent builds. It is unlikely to be particularly interesting to end users, but kinkshaming is not nice, okay? I like to know what's being built and now you can too here.

Reproducible builds​

We have started testing binary reproducibility of x86_64 builds targetting the stable repository. This is possible thanks to flathub-repro-checker, a tool doing the necessary legwork to recreate the build environment and compare the result of the rebuild with what is published on Flathub.

While these tests have been running for a while now, we have recently restarted them from scratch after enabling S3 storage for diffoscope artifacts. The current status is on the reproducible builds page.

Failures are not currently acted on. When we collect more results, we may start to surface them to app maintainers for investigation. We also don't test direct uploads at the moment.

In early August, a concerned community member brought to our attention that copyright notices and license files were being omitted when software was bundled as Flatpaks and distributed via Flathub. This was a genuine oversight across multiple projects, and we're glad we've been able to take the opportunity to correct and improve this for runtimes and apps across the Flatpak ecosystem.

Over the past few months, we've been working to enhance our tooling and infrastructure to better support license compliance. With the support of the Flatpak, freedesktop-sdk, GNOME, and KDE teams, we've developed and deployed significant improvements that make it easier than ever for developers to ensure their applications properly include license and copyright notices.

What's New​

In coordination with maintainers of the freedesktop-sdk, GNOME, and KDE runtimes, we've implemented enhanced license handling that automatically includes license and copyright notice files in the runtimes themselves, deduplicated to be as space-efficient as possible. This improvement has been applied to all supported freedesktop-sdk, GNOME, and KDE runtimes, plus backported to freedesktop-sdk 22.08 and newer, GNOME 45 and newer, KDE 5.15-22.08 and newer, and KDE 6.6 and newer. These updated runtimes cover over 90% of apps on Flathub and have already rolled out to users as regular Flatpak updates.

We've also worked with the Flatpak developers to add new functionality to flatpak-builder 1.4.5 that automatically recognizes and includes common license files. This enhancement, now deployed to the Flathub build service, helps ensure apps' own licenses as well as the licenses of any bundled libraries are retained and shipped to users along with the app itself.

These improvements represent an important milestone in the maturity of the Flatpak ecosystem, making license compliance easier and more automatic for the entire community.

Recommended Actions​

App Developers​

We encourage you to rebuild your apps with flatpak-builder 1.4.5 or newer to take advantage of the new automatic license detection. You can verify that license and copyright notices are properly included in your Flatpak's /app/share/licenses, both for your app and any included dependencies. In most cases, simply rebuilding your app will automatically include the necessary licenses, but you can also fine-tune which license files are included using the license-files key in your app's Flatpak manifest if needed.

For apps with binary sources (e.g. debs or rpms), we encourage app maintainers to explicitly include relevant license files in the Flatpak itself for consistency and auditability.

End-of-life runtime transition: To focus our resources on maintaining high-quality, up-to-date runtimes, we'll be completing the removal of several end-of-life runtimes in January 2026. Apps using runtimes older than freedesktop-sdk 22.08, GNOME 45, KDE 5.15-22.08 or KDE 6.6 will be marked as EOL shortly. Once these older runtimes are removed, the apps will need to be updated to use a supported runtime to remain available on Flathub. While this won't affect existing app installations, after this date, new users will be unable to install these apps from Flathub until they're rebuilt against a current runtime. Flatpak manifests of any affected apps will remain on the Flathub GitHub organization to enable developers to update them at any time.

If your app currently targets an end-of-life runtime that did receive the backported license improvements, we still strongly encourage you to upgrade to a newer, supported runtime to benefit from ongoing security updates and platform improvements.

Distributors​

If you redistribute binaries from Flathub, such as pre-installed runtimes or apps, you should rebuild your distributed images (ISOs, containers, etc.) with the updated runtimes and apps from Flathub. You can verify that appropriate licenses are included with the Flatpaks in the runtime filesystem at /usr/share/licenses inside each runtime.

Get in Touch​

App developers, distributors, and community members are encouraged to connect with the team and other members of the community in our Discourse forum and Matrix chat room. If you are an app developer or distributor and have any questions or concerns, you may also reach out to us at admins@flathub.org.

Thank You!​

We are grateful to Jef Spaleta from Fedora for his care and confidentiality in bringing this to our attention and working with us collaboratively throughout the process. Special thanks to Boudhayan Bhattcharya (bbhtt) for his tireless work across Flathub, Flatpak and freedesktop-sdk, on this as well as many other important areas. And thank you to Abderrahim Kitouni (akitouni), Adrian Vovk (AdrianVovk), Aleix Pol Gonzalez (apol), Bart Piotrowski (barthalion), Ben Cooksley (bcooksley), Javier Jardón (jjardon), Jordan Petridis (alatiera), Matthias Clasen (matthiasc), Rob McQueen (ramcq), Sebastian Wick (swick), Timothée Ravier (travier), and any others behind the scenes for their hard work and timely collaboration across multiple projects to deliver these improvements.

Our Linux app ecosystem is truly strongest when individuals from across companies and projects come together to collaborate and work towards shared goals. We look forward to continuing to work together to ensure app developers can easily ship their apps to users across all Linux distributions and desktop environments. ♥

Vorarbeiter is a German word for "foreman" and a living proof of my school-related trauma. The new service is a middleman between GitHub and GitHub Actions. It has been happily humming since April 21st, and largely does what Buildbot did: builds apps, with a sprinkle of publishing logic.

While what happens under the hood is solid, there is no UI yet. Flathub bot will still inform developers about build status for their pull requests, but there is little visibility of what happens post-merge.

Additionally, Vorarbeiter no longer allows to manually publish, cancel or delete builds. The publishing happens every hour regardless of the age of the build. The previous 3-hour-long delay was too conservative, and barely anyone was giving a final test for a post-merge builds. Similarly, cancelling builds doesn't seem as necessary as before. GitHub Actions runners are ephemeral and new commits on the same branch or pull request will automatically cancel the previous in-progress build.

Last but not least, because of limitations of the free GitHub Actions runners, some apps are designated as large builds. Large builds take place on machines provisioned in AWS, boasting faster CPUs and larger disks to accommodate heavier requirements.

While large builds do not incur costs per se thanks to the generous AWS credits for open source projects program, we still want to be mindful of how much credits we are spending, which is why we don't run large runners all the time. This is possible thanks to RunsOn, which handles all the magic for us. It receives pipeline events from GitHub and provisions new machines automatically within seconds, and tears them down the moment the build is finished. This is completely invisible to developers, but is both faster and more cost-effective, even if we were to pay the bill ourselves.

There is still more work to be done. I want to improve observability of the new service to make sure we can have automatic alerts when we have an abnormal build error rate or unprocessed publishing queue. In fact, we already notify maintainers and Flathub admins when a build triggered on the master branch failed, but there is potential to be more proactive here.

The unsolved challenge so far is caching. Every new pipeline re-downloads Flatpak runtimes, SDKs, and source code needed to build the app. Ideally, we should cache at least the runtimes, but with runners being ephemeral, we should also attempt to implement a distributed solution for ccache to reduce build times.

Given the challenging circumstances, this is more than good enough, though! If you encounter any issues with the new workflow, don't hesitate to open an issue in the project's GitHub repository.

Apps and updates can be fairly quickly published to Flathub, but behind the scenes each one takes a long journey full of safety nets to get from a developer’s source code to being used on someone’s device. While information about this process is available between various documentation pages and the Flathub source code, I thought it could be helpful to share a comprehensive look at that journey all in one place.

Flatpak Security & Sandboxing​

Each app on Flathub is distributed as a Flatpak. This app packaging format was specifically designed with security and safety at its core, and has been continuously improved over the past decade. It has received endorsements, development, and wide adoption from organizations such as Bambu Lab, Bitwig, CodeThink, Collabora, Discord, The Document Foundation, elementary, Endless, GDevelop, KiCad, Kodi, GNOME, Intel, KDE, LibreOffice, Mozilla, OBS Studio, Plex, Prusa Research, Purism, Red Hat, System76, Telegram, Valve, and many more.

From a technical perspective, Flatpak does not require elevated privileges to install apps, isolates apps from one another, and limits app access to the host environment. It makes deep use of existing Linux security technologies such as cgroups, namespaces, bind mounts, and seccomp as well as Bubblewrap for sandboxing.

Flatpak apps are also built from a declarative manifest, which defines the exact sources and environment to build from to enable auditability and as much reproducibility as possible.

Due to Flatpak’s sandboxing, apps don’t have permission to access many aspects of the host OS or user data they might need. To get that access, apps must either request it using Portals or use static permissions.

Portals & Static Permissions​

Most permissions can be requested and granted on demand via an API called Portals. These permissions do not need to be given ahead of time, as desktop environments provide the mechanisms to give user consent and control over them e.g. by indicating their use, directly prompting the user before the permission is granted, and allowing revocation.

Portals include APIs for handling auto-start and background activity; access to the camera, clipboard, documents, files, location, screen casting, screenshots, secrets like passwords, trash, and USB devices; setting global shortcuts; inhibiting suspend or shut down; capturing input; monitoring memory, network, or power profiles; sending notifications; printing; setting a wallpaper; and more. In each case, the user’s desktop environment (like GNOME or KDE) manages if and how a user is notified or prompted for permissions—and if the permission is not granted, the app must handle it gracefully.

Some permissions are not covered by Portals, such as basic and generally safe resources for which dynamic permissions wouldn’t make sense. In these cases—or if a Portal does not yet exist or is not widely adopted for a certain permission—developers may use static permissions. These are set by the developer at build time in the public build manifest.

Static permissions are intended to be as narrowly-scoped as possible and are unchanging for the life of each release of an app. They are not generally designed to be modified by an end user except in cases of development, debugging, or reducing permissions. Due to this, Flatpak always prefers apps to use Portals over static permissions whenever possible.

Shared Runtimes & Modules​

Every app is built against a Flatpak runtime hosted by Flathub. The runtimes provide basic dependencies, are well-maintained by the Linux community, and are organized according to various platforms a developer may target; for example, GNOME, KDE, or a generic FreeDesktop SDK. This means many apps—especially those targeting a platform like GNOME or KDE and using its developer libraries—don’t need to pull in external dependencies for critical components.

Runtimes are automatically installed with apps that require them, and are updated separately by the user’s OS, app store, or CLI when needed. When a dependency in a runtime is updated, e.g. for a critical security update, it rolls out as an update to all users of apps that use that runtime.

In some cases there are commonly-used libraries not provided directly by one of the available runtimes. Flathub provides shared modules for these libraries to centralize the maintenance. If an app needs to bundle other dependencies, they must be defined in the manifest. We also provide tooling to automatically suggest updates to app dependencies.

Submission & Human Review​

Once an app is developed, it must be submitted to Flathub for consideration to be hosted and distributed. At this stage, human Flathub reviewers will review the app to ensure it follows the requirements. Of note:

• Apps must be sandboxed with as narrow permissions as possible while still functioning, including using appropriate runtime permissions instead of broad static permissions when possible. All broad static permissions need to be justified by the submitter during review.

• Apps must not be misleading or malicious, which covers impersonating other apps or including outright malicious code or functionality.

• App IDs must accurately reflect the developer’s domain name or code hosting location; e.g. if an app is submitted that purports to be Lutris, its ID must be obviously associated with that app (in this case, Lutris.net).

The app’s Flatpak manifest is reviewed, including all static permissions. Each of the documented requirements are checked—and if a reviewer finds something out of place they request changes to the submission, ask for rationale, or reject it completely.

Automated Testing​

In addition to human review, Flathub also makes use of automated testing for a number of quality and safety checks. For example, our automated tests block unsafe or outright wrong permissions, such as apps requesting access to whole session or system buses or unsafe bus names. Our automated tests also help ensure reproducible builds by disallowing pointing at bare git branches without a specific commit.

Reproducibility & Auditability​

Once an app has been approved and passes initial tests, it is built using the open source and publicly-available flatpak-builder utility from the approved public manifest, on Flathub’s infrastructure, and without network access. Sources for the app are validated against the documented checksums, and the build fails if they do not match.

For further auditability, we specify the git commit of the manifest repo used for the build in the Flatpak build subject. The build itself is signed by Flathub’s key, and Flatpak/OSTree verify these signatures when installing and updating apps.

We mirror the exact sources each app is built against in case the original source goes down or there is some other issue, and anyone can build the Flatpak back from those mirrored sources to reproduce or audit the build. The manifest used to build the app is hosted on Flathub’s GitHub org, plus distributed to every user in the app’s sandbox at /app/manifest.json—both of which can be compared, inspected, and used to rebuild the app exactly as it was built by Flathub.

Verification​

Apps can be verified on Flathub; this process confirms that an app is published by the original developer or an authorized party by proving ownership of the app ID. While all apps are held to the same high standards of safety and review on Flathub, this extra layer helps users confirm that the app they are getting is also provided or authorized by its developer.

Over half of the apps on Flathub so far are verified, with the number regularly increasing.

App Store Clients​

Once an app is developed, submitted, tested, approved, built, and distributed, it appears in app store clients like Flathub.org, KDE Discover, GNOME Software, and elementary AppCenter—as well as the Flatpak CLI. While exact implementations vary and the presentation is up to the specific app store client, generally each will show:

• Static permissions and their impact on safety
• Open Age Rating Service rating and details
• If an app uses outdated runtimes
• Release notes for each release
• If static permissions increase between releases

Flathub.org and GNOME Software also display the app’s verified status.

Updates​

Once an app is accepted onto Flathub, it still remains subject to number of safety protections built into the flow:

• Flathub maintains ownership over the manifest repo, while app developers are invited as limited collaborators
• The manifest repo’s default branch is protected, preventing direct pushes without a pull request
• The manifest repo’s commit history cannot be rewritten, making it harder to sneak something in
• Flathub’s automated tests must pass before a PR can be merged and an update can be pushed
• Static permission changes are held for human review before an update is released to users
• Critical MetaInfo changes are held for human review, e.g. if an app name, developer name, app summary, or license changes

Special Cases​

There are a few special cases to some of the points above which I would be remiss not to mention.

Flathub has granted a select group of trusted partners, including Mozilla and OBS Studio, the ability to directly upload their builds from their own infrastructure. These projects have an entire CI pipeline which validates the state of their app, and they perform QA before tagging the release and pushing it to Flathub. Even for these few cases of direct uploads, we require a public manifest and build pipeline to enable similar reproducibility and auditability as outlined above. We also require the apps to be verified, and still run automated tests such as our linter against them.

Lastly, some apps (around 6%) use extra-data to instruct Flatpak to download and unpack an existing package (e.g. a Debian package) during installation. This process runs in a tight unprivileged Flatpak sandbox that does not allow host filesystem or network access, and the sandbox cannot be modified by app developers. These are largely proprietary apps that cannot be built on Flathub’s infrastructure, or apps using complex toolchains that require network access during build. This is discouraged since it does not enable the same level of auditability nor multi-architecture support that building from source does. As a result, this is heavily scrutinized during human review and only accepted as a last resort.

Even with the above, the vast majority of apps are built reproducibly from source on Flathub’s infrastructure. The handful of apps that aren’t still greatly benefit from the transparency and auditability built into all of the other layers.

Incident Response​

While we expect to catch the vast majority of safety issues with the above, we are also able to respond to anything that may have slipped through. For example, we have the ability to remove an app from the Flathub remote in case we find that it’s malicious. We can also revert, recall, or block broken or malicious app updates.

We take security reports and legal issues very seriously; please contact the Flathub admins to report an issue, or chat with us on Matrix.

In Summary…​

As you can see, Flathub takes safety very seriously. We’ve worked with the greater Linux and FreeDesktop ecosystem for over a decade on efforts such as Flatpak, OSTree, Portals, and even desktop environments and app store clients to help build the best app distribution experience—for both users and app developers—with safety as a core requirement. We believe our in-depth, multi-layered approach to safety has set a high bar that few others have met—and we will continue to raise it.

Thank you to all contributors to Flatpak, Flathub, and the technologies our ecosystem relies on. Thanks to the thousands of developers for trusting us with app distribution, and to bbhtt, Jordan, and Sonny for reviewing this post. And as always, thank you to the millions of users trusting Flathub as your source of apps on Linux. ♥

As the premier source of apps for Linux, Flathub serves a wide range of people across a huge variety of hardware: from ultra powerful developer workstations to thin and light tablets; from handheld gaming consoles to a growing number of mobile phones. Generally any app on Flathub will work on a desktop or laptop with a large display, keyboard, and mouse or trackpad. However, devices with only touch input and smaller screen sizes have more constraints.

Revealing the App Ecosystem​

Using existing data and open standards, we’re now highlighting apps on Flathub that report as being designed to work on these mobile form factors. This new On the Go collection uses existing device support data submitted by app developers in their MetaInfo, the same spec that is used to build those app’s listings for Flathub and other app store clients. The collection is featured on the Flathub.org home page for all devices.

Many of these apps are adaptive across screen sizes and input methods; you might be surprised to know that your favorite app on your desktop will also work great on a Linux phone, tablet, or Steam Deck’s touch screen. We aim to help reveal just how rich and well-rounded the app ecosystem already is for these devices—and to give app developers another place for their apps to shine and be discovered.

Developers: It’s Up to You​

As of this writing there are over 150 apps in the collection, but we expect there are cases where app developers have not provided the requisite device support data.

If you’re the creator of an app that should work well on mobile form factors but isn’t featured in the collection, take a minute to double-check the documentation and your own apps’s MetaInfo to ensure it’s accurate. Device support data can also be used by native app store clients across form factors to determine what apps are displayed or how they are ranked, so it’s a good idea to ensure it’s up to date regardless of what your app supports.

Buildbot has never been designed to do what Flathub needs: taking arbitrary inputs like application IDs and dynamically creating new pipelines. However, there's no misuse one cannot achieve if something is being configured in A Real Programming Language, and so, back in 2019, Alex Larsson piled a bunch of hacks so we could have not only dynamic configuration based on Flathub organization in GitHub, but also some custom views displaying latest builds.

Fast-forward to 2025, these hacks no longer work with the latest release of Buildbot, rendering our soft fork stuck on a version from 2021. For whatever reason, updating GitHub CI status stopped to work well, allowing people to merge untested code changes. It also requires periodical restarts because it grinds to a halt for no particular reason, dropping new builds in the meantime. The worst offense: I never liked it.

Interlude: Equinix Metal née Packet has been sponsoring our heavy-lifting servers doing actual building for the past 5 years. Unfortunately, they are shutting down, meaning we need to move out by the end of April 2025.

This perfect storm means we need to effectively re-architecture build infrastructure from scratch.

webhook-proxy​

Let's start from improving Buildbot reliability where it falls short. While GitHub shows delivery status of webhook events, and even provides a button to trigger another attempt, there's no public API exposing this data.

As there's no way I'm fixing Buildbot itself, I decided we need a middleman which will take care of redelivering if Buildbot's webhook endpoint responded with non-200 response.

webhook-proxy is a simple Python service which accepts payloads from GitHub, marks new pull requests as pending CI, then forwards unchanged events to Buildbot. Should Buildbot have a hiccup, it will open a circuit breaker and retry with exponential back off until it eventually succeeds.

It ain't much, but it's honest work.

justpak​

An important piece of the future Buildbot replacement is being agnostic of its CI/CD implementation. The idea is to provide only a business logic service, while actual building is delegated elsewhere. As such, it requires some relatively generic tool to execute tasks instead of maintaining two or more pipeline definitions for whatever is the CI/CD solution of the decade.

After evaluating modern make replacements, I settled on just. It seems simple enough for executing external commands, and has a nifty way of defining recipes with a specific shebang from the get-go, so it's all a single file even when using a mix of Python and Bash.

I copied all build steps done by the Buildbot workers to specific recipes to have a single entry point. Then I started doing back flips with GitHub Actions to see if this is a viable way in the first place; turns out it is, although not without some hurdles.

While GitHub Actions have a native way of executing all steps inside a Docker container, the host running said container is full of bloat and barely has any free disk space. bbhtt suggested how to remove unneeded files, which also meant each build step is prefixed with docker run as we want to re-use existing flatpak-builder-lint image instead of meddling with Ubuntu.

Then I went to GNOME GitLab to implement identical pipeline because I have no mouth and I must write YAML. GitLab has its set of quirks but after configuring its runners to stop dropping job output and kindly asking GitLab to stop unconditionally kill jobs whose logs exceeded a certain size, we've got the answer: it will blend!

Apps on the smaller size can be safely built on GitHub Actions, but anything larger like Chromium, LibreOffice or KDE runtime will need some special treatment by being routed to GNOME GItLab. It's still not as fast as existing infrastructure is, but it will no longer be existing in a quarter, so there's nothing to be complaining about here. As both GitHub Actions and GitLab CI allow triggering workflows through API, it will be also easy to integrate with some external system.

The work-in-progress repo can be found here.

I was initially panicking about replacing aarch64 runners, but it turns out GitHub is providing that since September 2024. Build times are in line with the table above, meaning we are only worried about outliers. I have submitted Flathub to Works on Arm program, and if it gets accepted, we will handle that similarly to x86_64.

The rest of the owl​

It's all cool and dandy, but the crucial part is still missing: a service encapsulating business logic. Buildbot encapsulates starting new builds, figuring out where they should go (Is it a test build? Is it a beta build?), retries for failed builds and managing publishing, all of that with a fancy UI.

There's no punchline here: I'm only starting the legwork to figure out which language and framework to use. If you would like to see something specific implemented, don't hesitate to request it here.

At the beginning of the year we announced an incredible milestone for Flathub: over one million active users. But we didn't slow down; in February we attended FOSDEM, then announced improved app moderation and app brand colors in preparation for some new features. Those efforts ultimately launched with the new homepage and featured app banners in April.

Milestones​

We're back with some new milestones thanks to the continued growth of Flathub as an app store and the incredible work of both our largely volunteer team and our growing app developer community:

70% of the most popular apps are verified​

Over 1,000 apps have been verified by their developers on Flathub, including 70% of the top 30 most popular apps. Developers of verified apps are ultimately in charge of their own app listings, and their updates are delivered directly to Flathub users while passing our automated testing and human review of things like permission changes.

100+ curated quality apps​

Over 100 apps are now passing our quality guidelines that include checks like icon contrast on both light and dark backgrounds, quality screenshots, and consistent app naming and descriptions so users get a better experience browsing Flathub. These guidelines are what enable us to curate and display visually appealing and consistent banners on the new home page, for example.

This means that between late February and July, the developers of over 100 apps went out of their way to improve—and sometimes make significant changes to—their apps' metadata to get ready for these new guidelines and features on Flathub. We're proud of these developers who have gone above and beyond, and we look forward to even more apps opting in over time.

Developers, if you'd like to see your app featured on the home page, please ensure you are following these guidelines! We've heard from app developers that getting your app featured not only gives a bump in downloads, but can also bring an increase in contributions to your project if it's open source.

4 million active users​

Six months ago we passed one million active users based on a simple if conservative estimate of updates to a common runtime version we had served. Using that same methodology, we now estimate we have over 4 million active users!

As a reminder, this data is publicly available and anyone can check our work. In fact, I personally would love if we could work with a volunteer from the community to automate this statistic so we don't have to do manual collation each time. If you're interested, check out this GitHub issue.

Over 2 billion downloads​

Those users have been busy, too: to date we have served over two billion downloads of different apps to people using different Linux flavors all around the world. This is a huge community of people trusting Flathub as their source of apps for Linux.

Thank you!​

Thank you to our download-happy community of users who have put their trust in Flathub as their source of apps on Linux. Thank you to all of the developers of those apps, and in particular those developers who have chosen to follow the quality guidelines to help make Flathub a more consistent and engaging space. And thank you to every contributor to Flathub itself whether you are someone who fixed a typo in the developer documentation, helped translate the store, contributed mockups and design work, or spent countless hours keeping everything running smoothly.

As a grassroots effort, we wouldn't have become the Linux app store without each and every one of you. ❤️

The verified apps utilizing automerge-flathubbot-prs before May 28th have been grandfathered and no explicit action is required from the maintainers. If your app does not meet these criteria, you can still request an exception by creating a pull request to the flatpak-builder-lint repository. Exception requests will be judged on a case-by-case basis on providing valid reasons.

The automerge-flathubbot-prs feature has been introduced back in 2019 to reduce maintenance overhead of applications dependent on non-redistributable data. If an extra-data source used by the app disappears because of an update, the automation would ensure that it is still possible to install the app, without requiring manual intervention from the maintainers.

Over time, the feature has started to be misused as a general purpose automation for publishing updates without proper testing. This has led to a number of issues where apps became broken overnight, which could have been easily prevented if the update was tested before merging.

What are brand colors?​

App brand colors are an easy and effective way for app developers to give their listing a bit more personality in app stores. In combination with the app icon and name, they allow setting a tone for the app without requiring a lot of extra work, unlike e.g. creating and maintaining additional image assets.

Why now?​

This idea was first implemented in elementary AppCenter, and later standardized as part of the AppStream specification.

While it has been in AppStream itself for a few years, it was unfortunately not possible for Flathub's backend to pick it up until the recent port to libappstream. This is why many apps are still not providing this metadata—even if it was available from the app side we were unable to display it until now.

Now that we can finally pick these colors up from AppStream MetaInfo files, we want to make use of them—and they are essential for the new banners.

Adding brand colors​

Apps are expected to provide two different brand colors for light and dark. Here's an example of a MetaInfo file in the wild including brand colors.

This is the snippet you need to include in your MetaInfo file:

<branding>
  <color type="primary" scheme_preference="light">#faa298</color>
  <color type="primary" scheme_preference="dark">#7f2c22</color>
</branding>

In choosing the colors, try to make sure the colors work well in their respective context (e.g. don't use a light yellow for the dark color scheme), and look good as a background behind the app icon (e.g. avoid using exactly the same color to maintain contrast). In most cases it's recommended to pick a lighter tint of a main color from the icon for the light color scheme, and a darker shade for the dark color scheme. Alternatively you can also go with a complementary color that goes well with the icon's colors.

What's next?​

Today we've updated the MetaInfo quality guidelines with a new section on app brand colors. Going forward, brand colors will be required as part of the MetaInfo quality review.

If you have an app on Flathub, check out the guidelines and update your MetaInfo with brand colors as soon as possible. This will help your app look as good as possible, and will make it eligible to be featured when the new banners ship. Let's make Flathub a more colorful, exciting place to find new apps!

If your application no longer passes the build validation stage in either Buildbot (for apps maintained on GitHub) or flat-manager (for direct uploads), make sure to look for specific messages in the log. Explanations for various error messages can be found in the documentation. If you are interested in running the linter locally or integrating it with your own CI, please refer to the project page.

We have also started moderating all permission changes and some critical MetaInfo changes. For example, if a build adds or removes a static permission (as seen in the finish-args array in the manifest) or changes the app’s user-facing name, it will be withheld for manual human review. Reviewers may reject a build and reach out for clarification about the change.

Flathub has also switched to a modern, well-maintained AppStream library, known as libappstream. This enables developers to use all features described in the AppStream 1.0 specification, including specifying supported screen sizes for mobile devices, or video snippets to accompany static screenshots. It also improves the validation of AppStream metadata. Many thanks to Philip Withnall, Luna Dragon and Hubert Figuière for their work on this across the Flatpak stack, and Matthias Klumpp for implementing knobs needed by Flathub in the library itself.

This work has been ongoing since 2021. At one point along the way we briefly switched over to libappstream, but had to revert due to unexpected breakage; however, today we are finally ready with all blocking issues addressed! While we were focused on closing the gaps to prevent potentially broken builds from being published, we regret that we failed to provide a heads-up about the coming validation changes. Any future breaking changes will be properly announced on this blog, and going forward we will also inform maintainers of affected apps about required changes in advance.

BoF: Saturday 16:00 CET​

The FOSDEM website describes BoFs pretty well:

BOF stands for Birds Of a Feather who, as the saying goes, flock together. FOSDEM has three meeting rooms that may be booked in 30 or 60 minute blocks for discussions. All the meetings are public so anyone who is interested can attend if there is enough space.

We've reserved a BoF room for Saturday, February 3 at 16:00 local time (CET, UTC+1); seating is on a first-come, first-served basis, so arrive promptly! We'll be meeting to discuss recent developments around metadata and build validation, other upcoming changes, and anything else on the minds of the attendees. Check the event for the exact room details (and any scheduling changes).

We hope to see you there!

Stands​

Various Flathub and Flatpak folks can also be found around associated stands:

• Kodi: building H, level 1, stand 4
• GNOME: building H, level 1, stand 5
• KDE: building H, level 1, stand 6
• Fedora Project: building AW, level 1, booth 4
• Linux on Mobile: building AW, level 1, booth 7

Find us to chat about Flathub, app submission and maintenance, Flatpak, and the Linux desktop app ecosystem.

Milestones​

To date, Flathub has served a total of 1.6 billion downloads of over 2,400 apps and their updates.

Since introducing verified apps last year, over 850 apps have been verified by their original authors; more than one third of all apps, with that number constantly increasing.

And finally, we're thrilled to announce that Flathub has surpassed one million active users. 🎉️

How We Measure Growth​

We have a public dashboard that shares some basic statistics, powered by an open source script. We don't track individual metrics from end user machines; instead, we look at downloads of specific artifacts from the Flathub infrastructure itself. This gives us a count of installs and updates over time, downloads per country (based on the origin of requests), and some derivative data like downloads of apps in different categories.

But how can we measure how many active users we have?

Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base FreeDesktop SDK runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub.

This methodology reveals that over the past few months there have been over a million updates of each of the latest FreeDesktop SDK runtime releases, meaning we've passed the one million active user mark.

If you'd like to explore more of this data yourself, there's this handy dashboard by Kristian Klausen (source), or you can always chat with us in #flathub on Matrix.

What's Driving Growth​

We attribute the growth of Flathub to a few developments over the years, and especially the last several months:

1. Popular app availability: Since we started Flathub, we've seen apps like Firefox, Google Chrome, Discord, VLC, Spotify, Telegram, Microsoft Edge, Steam, OBS Studio, Zoom, Thunderbird, and many more make their way into the store. These are many of the apps people want and expect, especially if they're coming to a Linux desktop for the first time. Each time another popular app hits Flathub, it makes both Flathub and Linux that much more compelling to users.

2. Verified apps: We've heard that some folks have held off installing specific apps or even using Flathub altogether because they didn't want a third-party maintainer redistributing an app they rely on; verifying apps solves this by assuring users their favorite app is actually coming from its developer. With an ever-increasing number of apps choosing to get verified—including both big names and many newer indie apps—the trust and adoption of Flathub increases.

3. Steam Deck: It's not just a meme; we suspect Flathub being included as the default app source for the Steam Deck's desktop mode has had a large positive effect on the usage of Flathub. Just look at some of the most popular apps: retro game emulators, game compatibility tools, gaming-oriented chat services, alternate game launchers—all the kinds of apps you'd expect Steam Deck users to want. And in fact, "game" is the single most common category of app on Flathub. It turns out selling "multiple millions" of devices has an impact on the ecosystem!

4. Linux distro adoption: In addition to shipping on Steam Deck, Flathub now comes included out of the box on at least Clear Linux, Endless OS, KDE Neon, Linux Mint, Pop!_OS, and Zorin OS—and as of Fedora 38, Flathub is available in its entirety when enabling third-party software sources. Flathub is the preferred app store for Linux, and its grassroots adoption across the Linux desktop ecosystem proves that.

5. New apps: Last but definitely not least, we've entered a thrilling chapter of Flathub as an ecosystem. It's not just another source to get popular, big-name apps you'd expect to be able to get anywhere else; Flathub has become the preferred app store for a growing number of indie, open source developers. Developers are increasingly submitting their own new apps and directing their users to Flathub; from all 50+ GNOME Circle apps to apps like Endless Key, Librum, Lightwave Explorer, Live Captions, and Planify, Flathub is the best way to get apps into the hands of Linux users.

And of course a large part of Flathub's continued growth has been due to the incredible work of the Flathub admins, contributors, and volunteers who have helped ensure Flathub remains the trustworthy and reliable service it has always been known as.

Here's to What's Next!​

It's easy to pat ourselves on the back for these milestones (and it's well deserved!), but equally important is to look forward. Over the coming months we're excited to continue tackling the roadmap we laid out last year, including continued work towards payments and the new organizational structure for Flathub.

We're also increasing our engagement with third-party developers and ISVs to share why they should bring their apps to the million-plus Flathub users on Linux, continuing to improve documentation, and working towards curation and improved presentation of apps. There's a lot more coming and always more to do; if you want to get involved, chat with us in #flathub on Matrix.

Thank you for reading, and happy downloading!

Today, Flathub has over 2,400 apps, including many of the big names you would expect. In the early days our goal was mostly to make it easy to get the latest version of popular apps via Flatpak, and we can safely say this has been achieved: not only can you get pretty much any app on Flathub, they are often directly maintained by the developer—and it's the primary channel many new app developers choose for shipping their apps.

More Apps, More Problems​

However, having lots of apps comes with some new (in this case nice to have) problems. While there are a lot of beautiful modern apps, there are also a lot of apps with low quality metadata, ugly icons, or out of date screenshots. This means that looking at the new and updated lists on the Flathub home page you get the impression that most of the apps on Flathub are low quality.

One of the biggest reasons for the prevalence of low quality app metadata is probably that historically people were not discovering new apps from their repositories very often. Instead, they were mostly installing the same few classics with well-known brands (VLC, Blender, etc.), or relying on word of mouth for discovery. Now that new apps are being released on a weekly basis, app metadata becomes much more important for introducing people to these new apps.

The unfortunate result of the status quo in metadata quality is that many apps don't look inviting for new users, and it's difficult to find truly high quality apps among the rest.

So how can we make Flathub a place for people to discover awesome apps? We've thought about this quite a bit, and landed on a two-pronged approach:

1. Raise the bar for metadata for all apps
2. Introduce curation to highlight the best apps

Raising the Bar​

As a first step towards improving metadata quality across the board we have added new, detailed documentation for app metadata. This new page goes over all the most important aspects, and which common mistakes to avoid. These include, for example:

• App icons that fill the entire canvas
• Summaries repeating the app name
• Screenshots with no window shadow

We're also introducing a new review system for app metadata, where editors rate which of the criteria a specific app meets. As an app developer you can see the state of your metadata on the app page on Flathub.

If editors flagged issues with your app you can address them in the next release. Once the new release is on Flathub you can request a re-review. The status of your app will be updated accordingly.

If you are not an icon designer, getting your icon to meet the guidelines can be challenging. Luckily there are designers from the community you can ask for help! The GNOME App Icon Design and KDE Visual Design Group Matrix rooms are good examples of places to ask.

This does not affect the app review process for apps being published on Flathub. We will continue to accept apps that don't fully meet the new quality guidelines. However, we do want to highlight apps that meet the guidelines, and try to show them in more prominent places on the website.

Curation​

Our hope is that with better documentation and developer outreach we can get to a solid set of apps with high quality metadata: Short descriptions, good icons, correctly sized screenshots with good content, and so on. Once we have that, we have a lot of new possibilities with regard to curation. For example, we've been exploring having app banners with app icons and screenshots on the home page. Other ideas we'd like to experiment with in the future include curated lists of apps, seasonal/topical recommendations, and editorial blog posts.

Our current plan is to start off with some simple banners on the homepage and iterate from there. The moderation backend for this already exists, and we're planning on rolling out the frontend soon.

At this stage our focus is on the Flathub website, but of course eventually we want to make this data available to native app store clients as well.

This effort will also help to improve the Flathub-wide search and the discoverability and attractiveness of apps on Flathub from the rest of the internet.

What's Next?​

As of today, if you have an app on Flathub you can log in on the website, and see the app metadata ratings for your apps. Please have a look at your apps' ratings and the new documentation and make sure your app's metadata is in shape when we start rolling out banners over the coming weeks :)

If you run into issues or have questions please contact us in #flathub on Matrix.

It's early days for all of this, but we're excited to continue working in this direction. Watch this space!

Please read through it and send us feedback if you find anything missing or unclear. You can also send us a pull request if you want to help us improve it.