When we install software on our computers, we rarely think about the journey a new version takes before reaching us.
We download applications from websites, install package managers, add third-party repositories, or wait for someone else to package the latest release. These approaches can be convenient, but they also introduce another question:
Why should updating an open-source application depend on someone other than its original developer?
For desktop applications distributed through GitHub, GitLab, Gitea, Forgejo, and similar platforms, the release artifacts are often already available. Developers publish binaries, attach them to releases, and make them accessible to anyone.
Yet discovering and downloading those files can still be a surprisingly manual process.
That's the problem I'm exploring with Updainium.
The Desktop Update Problem
Consider a simple scenario.
You use an open-source application that you downloaded six months ago. The developer has released three new versions since then, including security fixes and improvements.
How do you find out?
Perhaps you bookmarked the repository. Maybe you follow the developer on social media. Or perhaps you periodically open the application's website to check whether a new version is available.
Now imagine doing this for ten, twenty, or fifty applications.
The problem isn't that downloading software is difficult. It's that keeping track of independently maintained applications becomes tedious when every project has its own release page, naming conventions, and distribution methods.
Package managers solve part of this problem, but they aren't always the ideal solution for every project.
Some applications aren't available in your package manager. Others depend on community-maintained manifests or repositories. And sometimes, you simply want the binary published by the project's own maintainers.
Package Managers Aren't the Enemy
Let's be clear: package managers are excellent tools.
Homebrew, APT, winget, and other package management systems make software installation and maintenance much easier. They provide convenient workflows and, depending on the ecosystem, additional verification and dependency management.
However, they introduce a distribution layer between the original project and the user.
Depending on the package and ecosystem, that layer might involve a third-party maintainer, a separate release schedule, or a packaging process that doesn't perfectly match the upstream project's releases.
That's not necessarily a bad thing. It's simply a different distribution model.
But there is another option: let users discover and download release files directly from the source.
Meet Updainium
Updainium is an open-source desktop application inspired by Obtainium, adapted for desktop software distribution.
Instead of manually checking every repository, you can use Updainium to track public projects across supported Git hosting platforms.
The idea is straightforward:
- Add a public repository.
- Configure the file extension you want to download.
- Let Updainium check the project's releases.
- Download the matching release asset when you need it.
For example, depending on the assets published by a project, you might look for .dmg files on macOS, .exe installers on Windows, or .AppImage packages on Linux.
You don't need every project to follow the same naming convention or distribute its software through a single centralized store. You choose the artifact type that fits your workflow.
The goal is to make upstream releases easier to discover and download.
Why I Built It with Tauri, Rust, and Svelte
Updainium is built with Tauri, using Rust for its backend and Svelte for its interface.
I wanted a desktop utility that could remain lightweight while still providing a native application experience.
Rust handles backend operations, including application logic and file handling. Svelte powers the user interface, while Tauri connects the two without requiring a traditional heavyweight desktop application stack.
This combination is a practical fit for a tool whose job is to monitor releases and download files rather than run a large collection of background services.
It also keeps the project hackable. The source is available under the GPL-3.0 license, so developers can inspect how it works, modify it, and contribute improvements under the terms of that license.
Direct Downloads Don't Automatically Mean More Security
There is an important distinction between downloading directly from a project's release page and knowing that a file is safe.
A direct download doesn't automatically guarantee authenticity, integrity, or security.
A compromised maintainer account, malicious release, or vulnerable application can still put users at risk. Likewise, downloading a binary from an upstream repository doesn't necessarily mean it has been independently audited.
That's why software distribution should be transparent about what it does and what it doesn't guarantee.
Updainium focuses on discovering releases and downloading matching files. It isn't a substitute for signature verification, checksums, reproducible builds, or a project's security practices.
Whenever a project publishes checksums or signed artifacts, users should take advantage of those verification mechanisms.
The point isn't to blindly trust the source. It's to give users a more direct route to the software they have chosen, while leaving room for independent verification.
What About APIs and Web Scraping?
Not every Git hosting service exposes the same information through a standardized API.
Some sources provide structured release data, while others may require Updainium to gather information from their web pages.
That creates a limitation worth acknowledging: scraping depends on the structure of the website. If a platform changes its HTML or release page layout, tracking can break until compatibility is restored.
This is an engineering trade-off, not something that should be hidden behind marketing language.
The long-term goal is to make release tracking reliable across supported platforms while remaining transparent about compatibility limitations.
A Different Philosophy for Desktop Software
Updainium isn't intended to become another platform that controls how you develop, distribute, or maintain software.
Its development follows a deliberately simple set of principles:
- No AI features.
- No telemetry.
- No subscriptions.
- No automatic installation or updates.
- No Contributor License Agreements (CLAs).
- No proprietary server components.
These aren't claims that every other software project should follow the same rules. They're decisions about the kind of tool I want to build and maintain.
For me, an update manager should help users stay informed and obtain software, not take control of their machines.
That's why Updainium doesn't automatically install updates. Discovering a new release and deciding to install it should remain separate actions.
Automation is useful, but it shouldn't eliminate user consent.
What's Next?
Updainium is still evolving.
The project is open to improvements that make release discovery, downloading, configuration, and everyday desktop use more reliable.
I'm particularly interested in feedback from developers who maintain desktop applications and users who prefer obtaining their software directly from upstream projects.
If you've ever had to maintain a collection of manually downloaded applications, I'd like to hear how you currently handle updates and what you'd improve about that workflow.
Try Updainium
You can explore the source code, inspect the implementation, report bugs, and follow development here:
- GitHub repository: https://github.com/livrasand/Updainium
- License: GPL-3.0
If you find the project useful, consider starring the repository or contributing a human-reviewed improvement.
Desktop software distribution doesn't need to be complicated to be useful.
Sometimes, the best improvement is simply making it easier to get the software you already trust—from the people who actually build it.
