A lot of us ship binaries through GitHub Releases because it is right there in the repo. It looks easy, it is free, and for many open source projects it is the default.
But once you start relying on it for real distribution, things get messy. GitHub Releases is fine for attaching a zip or tarball, but it was never designed to be a proper release hosting platform.
Pain points with GitHub Releases
1. Poor user experience
Users have to click through the release page and manually pick files. Direct URLs exist but they are long and brittle. If you want to provide installation through a package manager, GitHub Releases gives you nothing.
2. No download insights
You cannot see how many times a binary was downloaded. You cannot compare which platforms or versions people care about. If you are building multiple artifacts, you are essentially guessing which ones are worth the effort.
3. Limited automation
GitHub Actions lets you attach artifacts to a release, but that is where it stops. There is no API for download stats. There is no support for APT or YUM repos. You end up gluing together scripts to do things that should be built-in.
What developers actually need
For projects that ship binaries, we really need:
- Easy hosting and sharing of binaries
- Real download analytics
- Support for package managers like APT and YUM
- CI/CD integration without friction
- A service focused on binaries, not an afterthought to code hosting
That is why I started building ZipZen. It is lightweight release hosting made for developers. You get reliable binary hosting, zero-config APT/YUM package repositories, and download statistics (though detailed stats will come soon).
GitHub Releases will frequently be the default option for attaching a file, but if you care about your users and your workflow, the cracks start to show. If you are running into the same pain points, maybe ZipZen is for you.
Curious what others think: do you stick with GitHub Releases or use something else for binaries?
Top comments (0)