December 2025 Bazel Central Registry Outage

On December 26, 2025, Bazel users worldwide struggled with running their builds, as Bazel reported errors due to expired TLS certificates:

ERROR: Error computing the main repository mapping: Error accessing registry https://bcr.bazel.build/: Failed to fetch registry file https://bcr.bazel.build/modules/platforms/0.0.7/MODULE.bazel: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed

It was fairly simple to identify the cause, but hard to fix: Google's Xudong Yang reported that the process to auto-renew Bazel's TLS certificates had failed without sending notifications. Despite it being the day after a major holiday, the Bazel team managed to restore the certificates, about twelve hours after the issue was first reported.

This sort of failure is unfortunately fairly common: a similar issue happened in 2022. It's a well-known problem that TLS certificate expiry is all-or-nothing (See also "Expiry Times Are Dangerous.")

Sadly, knowing this is a reported issue does not help you when your builds are failing.

What can I do?

Luckily, Bazel users on Slack and GitHub quickly shared workarounds to use alternate URLs instead of the failing websites.

Bazelisk users can override the base URL used for downloads, either as an environment variable or in a .bazeliskrc file. The following configuration tells Bazelisk to download from GitHub directly, rather than trying to reach mirror.bazel.build.

BAZELISK_BASE_URL=https://github.com/bazelbuild/bazel/releases/download

Similarly, Bazel itself can be told to use the registry files directly from GitHub, rather than relying on bcr.bazel.build. The repository is the source of truth in this case, as the site is built from that data.

common --registry=https://raw.githubusercontent.com/bazelbuild/bazel-central-registry/main/

Both of these are useful as temporary workarounds: in the long run, the mirrors maintained by the Bazel team and Google are more stable and future-proof. But when builds are failing and you want things to Just Work, these are good approaches.

More downloads are failing!

Some rule sets have further dependencies on the Bazel domains that failed: they might be downloading tools to use or other needed files. Unfortunately, there's not an easy fix in this case, but some of the features of the Bazel downloader can be used to patch individual failing requests. (Thanks to Tom van der Woert on Bazel Slack for these directions.)

First, download a copy of the required file (possibly directly from GitHub, or by regenerating it from source: this part can't be easily automated and will require some discovery). Then save the file to a URL that you control and can serve from (if this is using a cloud provider, it should be publically available so that you don't need to worry about setting up .netrc credentials for Bazel).

Then, create a custom Bazel downloader config, such as .bazel_downloader.cfg, for your project, which can re-write the failing URLs for you:

# AWS
rewrite mirror.bazel.build/(.*) s3.us-east-1.amazonaws.com/example_bucket/$1

# GCP
rewrite mirror.bazel.build/(.*) storage.googleapis.com/example_bucket/$1

# CloudFlare mirrors some of mirror.bazel.build, but not the BCR itself.
# Using this means not needing to copy the files directly.
rewrite mirror.bazel.build/.* bcr.cloudflaremirrors.com/$0

Finally, tell Bazel to use your downloader config by adding the following to your bazelrc:

common --downloader_config=.bazel_downloader.cfg

Now Bazel will rewrite downloads for the failing file to the version you are serving.

Future Work

There are a number of things that the Bazel team and the community can do to try to mitigate issues like this in the future.

1. An early warning that TLS certificates are about to expire seems useful, even if that just warns that the auto-renewal should be watched more carefully.
   1. GitHub user @compumike has a blog post on automated TLS certificate checks and a comment on applying these to Bazel.
   2. Also, updating the schedule to avoid major holidays seems prudent.
2. The community should set up additional mirrors of the BCR hosted on separate infrastructure. Ideally, Bazel would be modified to use these community mirrors in addition to the Google-provided ones, allowing for easy failover when the BCR is down for whatever reason.
   1. EngFlow will work with the community and the Linux Foundation to set up a BCR mirror for better failover coverage.
3. Bazelisk and other rule sets that need to perform downloads should also set up failover outside of mirror.google.com. This is more technically complex, but also more robust, since it will allow for easier recovery.
   1. Bazel also needs to address #28158, so that downloads will correctly fail over to additional URLs on TLS errors.