Keeping chrlauncher working

The fix

Open chrlauncher.ini next to chrlauncher.exe and set:

ChromiumUpdateUrl=https://chromiumbuilds.org/api/chrlauncher/windows-%d-%s.txt

Make sure the line is not commented out; the default ships with a # in front of it. That is the whole change. chrlauncher substitutes your architecture and build type into the URL exactly as it did before, so switching ChromiumType keeps working.

Why this works on a static site

chrlauncher's update URL is a format string: it fills in the architecture and the configured build type, then parses the response as key=value pairs separated by semicolons. Because those values land in the path rather than a query string, every combination can be served as a plain file. Nothing dynamic is involved, which is also why it cannot go down the way a single API endpoint can.

Build types available

Set ChromiumType in the same file. The original woolyss names all still work and point at sensible current equivalents:

What the response looks like

$ curl https://chromiumbuilds.org/api/chrlauncher/windows-64-stable-codecs-sync.txt
version=152.0.7977.65;download=https://github.com/...;timestamp=...

The download value always points at a portable archive rather than an installer, because chrlauncher extracts the archive itself. sha256 and size are extra fields older clients ignore harmlessly.

A note on trust

This endpoint tells chrlauncher where to download from, and chrlauncher will install what it finds there. Every URL served points at the maintainer's own GitHub release, and the files are regenerated automatically from those releases several times a day. If you would rather not point an auto-updater at someone else's server, the alternative is to check the release feed and update by hand.

Other updaters

chrupd reads GitHub release APIs directly and never depended on woolyss, so it keeps working untouched. On Windows, winget or Chocolatey will also keep a Chromium build current without any of this.