Mozilla Update Infrastructure

Firefox, Thunderbird, and Mozilla VPN updates rely on backend service known as Balrog. Periodically, these applications check for updates by pinging an URL1 which contains information about both the application running, and details of the system it is running on. If Balrog finds an update based on the provided information, it returns a simple XML response with a link to the update file, and some metadata about it.

Watershed Updates

Most of the time, an update will take an application directly from whatever version it is currently running to the latest version of that application. This is greatly preferred, both to save time, bandwidth, reduce restarts, and increase security by ensuring we get to the latest version of something as quickly as possible. Unfortunately, sometimes we must route through an intermediate version first, typically the version that is currently running does not provide Balrog with enough information to accurately serve a correct update to the latest version. These are colloquially known as “watershed” updates. (This name comes from the fact that these updates change something about the update process itself, making them a kind of “watershed moment” for updates.)

At the time of writing (August, 2023), we currently have the following watershed updates in place for Firefox’s release channel:

Desupport Updates

From time to time we stop supporting a platform, hardware or library that we depend on. When we do this, we must ensure we don’t update affected users to a version that they can no longer run. This can take two forms:

  • In the distant past, we would simply stop serving updates altogether, leaving users on their current version.

  • More recently, we will first move users to our esr channel - generally giving them another year of support before ending updates altogether.

Below is a list of desupports and moves to esr that we’ve done on the Firefox release channel:


Here is a sample URL:


While not directly related to the watershed, it is notable that due to LZMA MAR support shipping in the previous version (56.0), which was not a watershed for Linux and Mac, we shipped two different sets of MARs for 57.0, 57.0.1, 57.0.2, 57.0.3, and 57.0.4: we had bz2 MARs, which builds older than 56.0 were served, and a separate set of LZMA MARs that were shipped to 56.0 and higher. More details on this can be found on this awfully complicated spreadsheet that was produced around that time.