BuildBuddy: a Bazel build event viewer that doubles as a remote cache and result store

Two lines in .bazelrc and a URL per build

The getting started section is short enough to quote. You add two lines to your .bazelrc file:

build --bes_results_url=https://app.buildbuddy.io/invocation/
build --bes_backend=grpcs://remote.buildbuddy.io

The first flag says where the results should be viewable, and the second says which backend to send the build events to. The bes prefix is the build event service, and the grpcs scheme is the secure gRPC transport that the BuildBuddy backend speaks.

What you get for those two lines is a BuildBuddy URL printed at the beginning and end of every Bazel invocation, containing that build's results, and you can command click or double click those to open the results in a browser.

That is the whole onboarding, and it is genuinely unusual for a build tool. Most observability setups for Bazel involve exporting a profile, uploading a log or configuring a plugin. Here the build itself reports to a server and hands you the link.

The hosted service is offered free for individuals, open source projects and teams of up to three, and the documentation covers hosting an instance on-premises or in your own cloud. The core is open sourced under the MIT Licence, and the server is written in Golang and React and can be deployed as a Docker image.

The build summary and the target overview

The first feature is the build summary and logs, described as a high level overview of the build including who initiated the build, how long it took, how many targets were affected and so on. The build log is what makes it easy to share stack traces and errors with teammates, which the documentation says is what makes collaborative debugging easier.

That last point is the actual value proposition. A build failure that only exists in the output of one person's terminal is a bottleneck. A build failure with a URL that anyone can open, showing the same stack trace, is not.

The second feature is the target overview, which lets you see which targets and tests passed or failed and dig into more details. For a large graph, that is the difference between a wall of test output and a list of the six things that broke.

The third is detailed timing information, from a Timing tab that pulls the Bazel profile logs from your build cache and displays them in a human readable format. Bazel's own profile output is a wall of chart data, and the Timing view is the version a person can read to find out which action was slow.

So the first three features form a deliberate progression: what happened, what broke, and why it took so long.

Invocation details and why they are the most useful view

The invocation details feature shows all of the explicit flags, implicit options and environment variables that affect your build, and the documentation is explicit about the case it serves. It is particularly useful when a build is working on one machine but not another, because you can compare these and see what is different.

That is the feature most likely to earn its keep on a team, and it is not the one people expect a build viewer to lead with. The failure mode it addresses is mundane and expensive: a developer who cannot build locally, cannot tell why, and files a bug report that turns out to be a stale environment variable. A view that shows the effective configuration makes that a two-minute check.

The build artifacts feature gives a quick view of all the artifacts generated by the invocation, and clicking on one downloads it. The documentation notes the download works with either the built-in BuildBuddy cache or a third-party cache running in GRPC mode that supports the bytestream API, naming bazel-remote as an example.

The raw logs view is the escape hatch, described as a complete view of all of the events sent up via Bazel's build event protocol. The invitation at the end is telling: if you find yourself digging in here too much, let us know and we will surface that info in a nicer UI. The raw event stream is the ground truth, and the project treats people hitting it repeatedly as a signal about which higher level view is missing.

The remote cache, test logs and the enterprise split

The remote cache support is described as an optional built-in Bazel remote cache to BuildBuddy implementing the GRPC remote caching APIs. It allows BuildBuddy to optionally collect build artifacts, timing profile information, test logs and more. Alternatively, BuildBuddy supports third-party caches running in GRPC mode that support the bytestream API, with bazel-remote named again.

So there are two ways to run a cache. BuildBuddy can be the cache, or BuildBuddy can sit next to a cache you already run, which is the arrangement for teams that have a dedicated caching service and want the UI on top of it.

Viewable test logs surface test logs directly in the interface when you click on a test target, and the documentation notes that this requires the GRPC remote cache.

The rest of the features are quality of life and integration. Dense mode packs more information into every square inch if you want higher information density. BES backend multiplexing is the build_event_proxy configuration option, which lets you specify other backends that your build events should be forwarded to, which is the answer for a team already pointing bes_backend at another service. Slack webhook support lets you message a Slack channel when builds finish, described as a way of getting a quick notification when a long running build completes or a CI build fails.

The repository layout is where the open core versus enterprise split becomes visible. There is an enterprise directory alongside the server, app, cli, codesearch, proto, rules and tools directories, and the release history shows a steady cadence with v2.316.0, v2.315.0 and v2.314.0 published in the first two weeks of October 2026 alone. The last push was on 2026-10-22.

The engineering behind the project

The repository is a large Bazel-built monorepo, and the build system is part of the story rather than a detail.

There is a .bazelversion file, a MODULE.bazel with its lock file, a WORKSPACE file, a deps.bzl and a rules directory, and a buildfix.sh script alongside buildpatches. The Go side declares go 1.27.2 in its go.mod, and the module uses replace directives to point several dependencies at BuildBuddy's own forks, including dragonboat, goutils, vfs, throttled, terminal-to-html and kythe. That is a signal about the project's priorities, since a fork of kythe and a fork of the terminal-to-html converter are not things a team adds casually.

The front end is React 18 with TypeScript, and the dependency list is where you can see what the UI actually does. Recharts is the charting library, d3-scale and d3-time handle scales, dagre-d3-react is the graph layout library, which is what draws a target dependency graph, and monaco-editor is the code viewer. diff and diff-match-patch are the diffing libraries, react-window and react-virtualized-auto-sizer handle long lists, and protobufjs decodes the build event stream in the browser. There is a separate codesearch directory in the repository, and a Go CLI built with bubbletea, bubbles and lipgloss, the same terminal toolkit stack used by many Go CLIs, and a rules directory for the Bazel rules themselves, plus proto, terraform, deployment and k8s_on_prem.sh for the on-premises path. The Python requirements are minimal, with packaging and requests only.

Where BuildBuddy is the wrong choice

The first limitation is that it only helps if you use Bazel. The whole value proposition is the build event protocol and the remote caching APIs, and neither exists for Make, Gradle, npm or Cargo. A team whose builds are fine should spend its effort on CI log retention rather than on this.

The second is that the open core and the commercial product are not the same thing, and the README says so plainly: the core is open sourced in this repository under the MIT Licence, and the repository contains an enterprise directory. What is in the enterprise directory is not described in the visible documentation, so a team evaluating this has to work out from the code and the pricing pages which features they need. That is a real procurement question and the README does not answer it.

The third is what you send where. Adding bes_backend to your.bazelrc means every build reports its events, including the invocation details that show every flag, every implicit option and every environment variable, to a backend. If that backend is the hosted service, your build graph and its configuration leave your network. For most teams that is fine, since the same flags are visible in CI logs anyway, but for a team whose build encodes something sensitive it is a decision to make deliberately rather than a default.

The comparison with the alternatives is worth stating. bazel-remote does the cache without the viewer. BuildBuddy does both in one server, and the price of that is the dependency and the enterprise split. For a team that already runs a cache and wants a UI on top, multiplexing is the way in.

Editorial conclusion

BuildBuddy fits a team running Bazel at scale that wants a shared view of build failures, timing data and artifacts without stitching together CI logs, and that wants the same server to act as a remote cache. It does not fit a project that does not use Bazel, or a team that needs only CI log retention and can get it from the CI provider. Before deploying, decide which parts of the open core you need versus the enterprise directory, read the invocation details view first because it is what answers the why does this work on my machine question, and remember that pointing a build at a hosted backend sends your build metadata to that backend, which matters if your build graph is sensitive.

Frequently asked questions

Official sources

1. buildbuddy-io/buildbuddy on GitHub
2. Issues
3. Project website
4. README
5. Releases