Yatko (yatko.app) turns any public Github repo into clean download links that picks the right release asset for each visitor's OS and architecture. Swap the domain — one click to the right binary.
Free
Launch Team
EneyProactive AI for Mac. Free test, 20,000 credits.
Promoted
Git Releases
For a lot of beginners, Github can be quite complex and intimidating. And even for the advanced people, maneuvering through the Github Releases page to find the right installation file for their OS and architecture can be a hassle.
I've created Yatko for that reason. Yatko serves you the right installation file for your OS and architecuture. With Yatko, every installation is just one download button away. All you need to do is enter the name of the repo which you want to install on the frontpage, and Yatko will serve the download link to you directly.
That's not even the best feature of Yatko. Just change the domain name of any public Github repo to a Yatko link, for example https://github.com/cli/cli to https://yatko.app/cli/cli and you'll be taken straight to a much simpler installation procedure.
Yatko is open source as well! So check it out and please let me know if I can make any improvements to it. Contributions are welcome as well!
Website: https://yatko.app
Repo link: https://github.com/argval/yatko (Make sure to star it if you like it!)
@argval Great Launch Anurag!
Curious, How are you detecting OS/arch reliably across all the weird ways maintainers name their release assets?
@yashekbote Hi Yash! Good question!
Short answer: we do not rely on one naming convention. We score every asset in the release.
On the client side we read OS/arch from the User-Agent (and optional query params like `?platform=` / `?prefer=` / `?libc=`). Then we rank assets by filename heuristics: platform keywords (`win64`, `darwin`, `linux`, `appimage`, etc.), arch keywords (`amd64`, `aarch64`, `armv7`, …), preferred extensions per OS (`.exe`/`.msi` on Windows, `.deb`/`.appimage` on Linux, `.dmg`/`.pkg` on macOS), and filters for stuff that is not an installable binary (source tarballs, WASM builds, debug/symbol zips, obvious wrong-platform names).
This fixes one of those tiny GitHub UX problems that almost everyone has run into at some point. The domain-swap idea is particularly clever :) How do you handle repos with unusual release naming or multiple valid binaries for the same OS/architecture?
@andrasczeizel Hi Andras! Great question! I went through a lot of trial and error on exactly this. It doesn't rely on release tag names; we parse asset filenames (platform/arch keywords, extensions, and some normalisation for odd naming). When multiple binaries match the same OS/arch, we rank them (vanilla > debug/profile, explicit tags > generic names) and expose overrides like `?prefer=deb` or `?libc=musl`. The landing page also lists every asset if you'd rather pick yourself.
Best of luck in the launch day!
@alexcloudstar Thank you!
Tried the domain swap on two repos just now, yatko.app/cli/cli and yatko.app/argval/yatko, and both sit on "Loading release…" forever. Chrome 151 on macOS, and the network panel shows no request going out to api.github.com at all, so it's hanging before the fetch rather than getting rate limited. I'd look at the OS and arch detection path, that's the only thing running ahead of the call. Rough one to hit on launch day, flagging it early so you can catch it.
@asadmalik901 Hey Asad, thanks for flagging this issue.
It does not call api.github.com from the browser because that fetch happens on our backend. The caching issue was real though. Pages were re-rendering cold behind `Loading release…` page, and that is fixed now. `cli/cli` was that same issue; it just felt stuck until the server finished.
Also, Yatko only works for GitHub repos that actually have releases. Yatko's own repo `argval/yatko` does not have any yet, so that one should show "No releases yet."
Let me know if you are facing any other problem; we could have a chat over on LinkedIn or Twitter for the same.