chrlauncher: a portable Chromium launcher that keeps the browser updated

A launcher that owns the browser it starts

chrlauncher is a small and very fast portable launcher and updater for Chromium, written in C.

The division of labour is what makes it interesting. The Chromium build lives in a folder you control, the launcher starts it, and the launcher is also the thing that checks for new versions and installs them. So the browser is portable in the sense that it does not need to be installed into the system, and it stays current without an installer.

The system requirements are modest, which is part of the point of a program this size. Windows 7, 8, 8.1, 10 and 11 are listed, 64-bit and ARM64, and an SSE2-capable CPU. The Windows 7 note has been amended in the documentation: the KB2533623 update is struck through and replaced with the KB3063858 update, with x64 and x32 download links for it.

The project is MIT licensed with a LICENSE file at the root, the repository is not archived, and the last push was on 2026-10-07. The release history is worth noticing: v.2.7 on 2026-10-07, then v.2.6 from 2022-01-14, then v.2.5.7 from 2019-11-17. The version numbering is not semantic, and there was a long gap before the current release.

The source tree is a Visual Studio solution with a .vcxproj, a build.bat, a build_vc.bat for the C parts, a build_locale.bat for localisation resources, a bin directory, a src directory and a .gitmodules file, so some of the content is pulled in as a submodule.

Which Chromium build you get is a setting, not a decision you make at install time

The ini file has an option called ChromiumType, and the values are the most consequential part of the configuration. The documented options are:

ChromiumType=dev-official

dev-official is official development builds from the snapshots repository at storage.googleapis.com/chromium-browser-snapshots/index.html, in 32-bit and 64-bit. stable-codecs-sync is unofficial stable builds with codecs, from the Hibbiki releases, 64-bit and 32-bit. dev-nosync is unofficial development builds without Google services, from the RobRich999 Clang releases. dev-codecs-sync is unofficial development builds with codecs and without Google services, from the macchrome winchrome releases, 64-bit. dev-codecs-nosync carries the same description as dev-codecs-sync, also from macchrome. And ungoogled-chromium is unofficial builds without Google integration and enhanced privacy, based on the Eloston project, from the macchrome releases or the Eloston repository itself.

The differences between these are not cosmetic. The dev-official builds are the same binaries the Chromium project publishes as development snapshots, which means they are built for testing and are not validated by the Chromium team. The unofficial builds with codecs exist because official Chromium builds ship without proprietary codecs, which is a licensing decision upstream, and third parties rebuild to add them. The builds without Google services and the ungoogled build are for people who do not want Google's integration at all.

So the type you pick determines both what you can play and what you are running. The defaults to dev-official means the launcher is set up to follow development snapshots, which is the right default for the kind of user this tool serves and the wrong one for someone who wants a stable browser.

A related setting is ChromiumUpdateUrl, a custom update URL template, commented out by default with an example pointing at a chromiumbuilds.org endpoint.

The ini file, and the settings that decide how it behaves

Everything is configured through an ini file with a [chrlauncher] section, and the file is worth reading as a whole because the options interact.

The path settings come first. ChromiumBinary is the Chromium executable file name, chrome.exe by default. ChromiumDirectory is the binaries directory, relative to the chrlauncher directory or a full path with environment variables supported, defaulting to.\bin. ChromiumArchitecture is an integer where 0 is autodetect and the default, 64 is 64-bit and 32 is 32-bit.

ChromiumCommandLine is where the browser's own flags go, and the default is instructive:

ChromiumCommandLine=--flag-switches-begin --user-data-dir=..\profile --no-default-browser-check --disable-logging --no-report-upload --flag-switches-end

The --user-data-dir pointing at..\profile is what makes the profile portable alongside the browser, and --no-default-browser-check is there because the launcher handles the default browser role itself.

The update behaviour is a set of five booleans plus two integers. ChromiumAutoDownload is false by default, which means a tray tip appears when an update is found and you download it manually, and true means it downloads and installs automatically. ChromiumBringToFront is true by default, so the window comes to the front when a download starts. ChromiumWaitForDownloadEnd is true by default, so the browser starts only after the check, download and install are complete. ChromiumUpdateOnly is false by default, which means the launcher updates and then starts Chromium, and true means it downloads and installs without starting. ChromiumCheckPeriod is an integer where 2 means check once every two days, which is the default, 0 disables checking and -1 forces a check. ChromiumLastCheck caches the last checking timestamp, and ChromiumRunAtEnd is true so the browser starts once the install is over.

There is also an internal SDK section with commented-out options for a custom user agent and a proxy configuration, and a ChromePlusDirectory option that is commented out, with the note that a DLL hijack implements Chrome full portability as well as tab enhancements.

Command line overrides, and the updater role

There is a list of arguments that override the ini options, and the list is short because the ini already covers most of the ground.

-autodownload is auto download update and install it. -bringtofront brings the chrlauncher window to front when download started. -forcecheck forces update checking, which is the one that maps onto the -1 value of ChromiumCheckPeriod. -wait starts the browser only when check, download and install update is complete. And -update uses chrlauncher as updater but does not start Chromium.

That last one is the interesting design. The same binary can be the updater for Chromium without being the thing that launches it, which is the shape you want when the browser is started by something else, for example a script or a kiosk, and the update cycle should be handled separately.

The supported browser matrix is split by role. As a launcher, chrlauncher works with Chromium based browsers such as Google Chrome, Opera, Yandex Browser and Vivaldi, and with Firefox based ones such as Mozilla Firefox, Basilisk, Pale Moon and Waterfox. As an updater, Chromium only. So the Firefox family is a launch-only situation, and if you want automated updating for a Firefox based build you are out of luck with this tool.

There is also a default browser feature, where chrlauncher can act as the handler for links opened from other programs. The documented procedure is to start SetDefaultBrowser.bat as administrator, then go to the Control panel, Default programs, Set your default programs, choose chrlauncher and set all the checkboxes on.

The Chrome++ question, and the GPG signature

Two details are worth pulling out because they are the ones that change how you should evaluate the software.

The first is Chrome++. By default Chromium encrypts the profile with the user SID, and Chrome++ disables that. The documentation recommends it, and says that starting with version 2.7 of chrlauncher there is support for Chrome++, with the DLL hijack approach also implementing Chrome full portability as well as tab enhancements. The reasoning is about portability: a profile encrypted against a machine's SID cannot be moved to another machine, and Chrome++ removes that binding. The mechanism, a DLL hijack, is the kind of thing that deserves the attention any DLL hijack deserves, and the option is off by default and must be enabled explicitly through ChromePlusDirectory.

The second is the GPG signature. Binaries have a GPG signature named chrlauncher.exe.sig in the application folder, and the public key is published in the builder repository with a key ID of 0x5635B5FD and a fingerprint of D985 2361 1524 AB29 BE73 30AC 2881 20A7 5635 B5FD, listed on a key server.

For a program whose entire job is to download and install executables on your machine, verifying that signature is not optional diligence. The tool is asking for permission to replace your browser binary, and the trust chain runs through that key. The README also carries a donation section listing Bitcoin, Ethereum, Yandex Money and PayPal addresses, which is the project asking to be funded rather than a sign of anything.

The FAQ section in the documentation links to specific issue threads for practical problems, including what to do if you lose all settings and extensions when copying Chromium to another PC, and how to force a check for an update.

Editorial conclusion

chrlauncher fits someone running a portable Chromium on Windows who wants the browser to update itself without a system-wide installer, and who wants the configuration, the profile and the binary to live in a folder they can carry between machines. It is a poor fit if you are on anything but Windows, and a poor fit if you want the browser to stay exactly where it is, because the whole design assumes you own the update channel. Before adopting, check that the build type you set in ChromiumType matches the privacy expectations you have, because several of the options are unofficial builds from third-party repositories, and verify the GPG signature on the binary, chrlauncher.exe.sig, against key 0x5635B5FD before running it.

Frequently asked questions

Official sources

1. henrypp/chrlauncher on GitHub
2. Issues
3. License: MIT
4. README
5. Releases