What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
To publish a Flatpak app with ongoing updates, build it with flatpak-builder, then publish the exported app in a Flatpak repository—most often Flathub, or a repository you host yourself. Keep that repository’s metadata and signing information current. Once a new version is available in a remote users have configured, they can get it through a software center or by running flatpak update.
Choose where to publish your Flatpak
Flatpak’s publishing documentation describes three routes: Flathub, a repository you host, or a single-file bundle. For releases that need to reach users as updates, choose a repository: both Flathub and self-hosting use this model. Flatpak calls Flathub the convenient and effective option for many applications. Flatpak’s publishing overview and its repository documentation explain the options.
| Route | Best fit | What to account for |
|---|---|---|
| Flathub | Publishing through the primary Flatpak hosting service, especially when users already have its remote configured. | Follow Flathub’s app submission and build requirements; publishing is not simply copying files into a repository. |
| Self-hosted repository | Control over repository hosting and the release workflow. | You are responsible for serving repository metadata and handling signing information correctly. |
| Single-file bundle | Direct download, offline handoff, removable media, or an email attachment. | It is not a repository-based update channel for ongoing releases. |
Flathub is a repository route, not an alternative to repository-based updates. If users already have its remote configured, publishing your app there makes it available through that remote, subject to Flathub’s requirements. A bundle is useful when a recipient needs a file they can carry or receive directly, but it does not provide the same update experience. See the documentation for single-file bundles.
Build the app and export it to a repository
A Flatpak manifest specifies the application ID, runtime, branch, modules, and module sources. Choose a runtime and its matching SDK: the runtime supplies the environment the app runs against, while the SDK supplies development tools and headers. The Flatpak building introduction describes how the manifest-driven build works.
#1 Best Overall
- Prepare a manifest with the app ID, branch, runtime, and modules needed for your application.
- Run
flatpak-builder <build-dir> <manifest>, substituting your build directory and manifest filename. - Let the build complete:
flatpak-builderfetches and verifies module sources, builds and installs modules, applies the app’s sandbox configuration during finalization, and exports the result to a repository. - Choose whether to publish that repository through Flathub or serve it yourself.
Exporting the app is only the build stage. A self-hosted release also requires current repository metadata, a reachable repository location, and correctly distributed signing information; a plain web directory is not by itself a complete release workflow.
Host your own Flatpak repository
Serve the exported repository from a web server, then update its metadata whenever you add builds. Give users the repository location and the signing-key information needed to trust it. Flatpak’s repository hosting instructions describe hosting routes that include GitLab Pages and GitHub Pages; check the current provider’s limits and configuration before relying on either.
Rank #2
Make installation and remote setup easy
A .flatpakref describes an app ID, branch, repository URL, and runtime-repository information. It can let someone install an app without first adding the remote manually; installation may add the repository automatically or ask the user to add it. The file should include the base64-encoded GPG key used to sign the repository.
A .flatpakrepo provides repository details and signing-key information so a user can add the remote. Distributing one of these files alongside clear installation instructions gives users a practical way to configure access. See Flatpak’s documentation on repositories and reference files.
Account for repository transfer behavior
Archive-z2 repositories store a file per application file, which can result in many HTTP requests. Enable HTTP keep-alive on the web server to support that request pattern. Static deltas can speed transfers by packaging data between revisions, but require additional server storage; generate them with flatpak build-update-repo --generate-static-deltas if that trade-off suits your repository. These are hosting optimizations, not prerequisites for every small repository. The hosting documentation covers these server considerations.
Publish a release and deliver updates
For each release, add the new application version to the repository and update its metadata. Users who have configured that remote can then receive the version. Flatpak repositories are versioned, and downloads can transfer only the changed parts between versions. The Flatpak basic concepts documentation describes how updates work.
- Command line: users run
flatpak updateto check for and install updates. - Software center: a graphical software center can check for and install updates from configured remotes.
Do not assume every desktop immediately installs every release automatically: availability and installation depend on the user’s configured remote and software-center behavior. For a self-hosted repository, stale metadata or missing signing information can prevent a release from being discovered or trusted, so include both in the release process.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors
