Build Meetup Amsterdam 2026: Bazel, Buildbarn, Bonanza

On Wednesday 28 January 2026 I went to the Build Meetup Amsterdam, organised by EngFlow and hosted by Uber at its Amsterdam office. The welcome screen carried both logos, and the agenda slide was titled “Uber x EngFlow Meetup Agenda”. It was an evening about build systems: Bazel, remote execution, monorepos and the build pain that every large codebase shares.

This blog has never covered Bazel, so this is also my first post on the topic. Everything below comes from the slides I photographed and the short opening remarks I recorded.

The agenda

The evening ran from a 5:30 pm check-in and coffee reception to an 8:30 pm close. After the 6:00 pm opening remarks came three scheduled talks of 15 minutes each, a break at 6:50 pm, three lightning talks of 10 minutes each, and from 7:30 pm an unconference with networking and food.

The agenda: three 15-minute talks, three 10-minute lightning talks, then the unconference.

The scheduled talks were “Into the python-verse: supporting multiple python versions in a bazel monorepo” (Uber), “Bonanza: a distributed build system” (the Buildbarn creator) and “The many caches of Bazel” (EngFlow). The lightning talks were “Using Bazel to speed up development cycles by perform[ing] data and ML contract testing” (Booking), “Why Maven build is slow and how to make it faster?” (Miro) and “Isolated builds and workspaces are for designers just as much as engineers”. I have photos of four of these six, so those are the ones I write about below.

Opening: Build Management at Scale with EngFlow

The EngFlow speaker who opened the evening explained why the meetup existed at all. EngFlow is a fully remote company without its own office, so it works with hosts, Uber in this case, to bring events to different cities. She said she had worked at Google from 2016 to 2020 on the Bazel project and co-created the first BazelCon, and that being part of the Bazel community is “part of our company DNA”. BazelCon happens once a year, and meetups like this one are a way to hear people’s problems and the common trends between companies in between.

Build Management at Scale with EngFlow, shown on a BazelCon 2025 slide template.

The “Build Management at Scale with EngFlow” slide listed what the company offers and claims:

• Remote Execution and Caching, Build Forensics, Bazel Training & Support
• The “largest concentration of core Bazel creators and experts”
• Clusters of 100–200,000 cores, with 35% cloud cost savings over other options (EngFlow’s figure)
• Trusted by auto, AI, finance, software and hardware companies

The customer logos underneath included Arm, Brave, Canva, Databricks, Lyft, Perplexity, Snap Inc. and Zoox. A later slide announced the “BSI: Build Scale Investigate” world tour: Amsterdam in January, London in February, New York in March and Munich in May.

The host from Uber then introduced Uber Tech AMS. The slide described a “diversely growing community” of 700+ members from 50+ nationalities, and the speaker named the organisations based in Amsterdam, including Payments, Platform, Earner and Maps.

Into the python-verse: multiple Python versions in a Bazel monorepo

The first talk was “Into the python-verse: supporting multiple python versions in a bazel monorepo” by Alex Preobrazhenskiy from Uber.

Alex Preobrazhenskiy (Uber) opening the first talk of the evening.

I only photographed the title slide, so I can’t report the details of Uber’s approach. The problem itself is well known: in a monorepo, one service wants a newer Python while another can’t move yet, and the build has to handle both at the same time. For background, Bazel’s official rules_python supports this. You register several Python toolchains in MODULE.bazel, and a py_binary or py_test can choose its version with the python_version attribute. In the docs’ own words, “multiple versions can be specified and used within a single build”.

Bonanza: a distributed build system

The second talk was “Bonanza: a distributed build system” by Ed Schouten, introduced on the slide as “Buildbarn creator”. Buildbarn is an open-source build farm that implements the Remote Execution API, the protocol that lets clients like Bazel send build and test actions to a remote cluster and share a central cache of results.

He started with what most Buildbarn users run today. The “Typical Buildbarn based remote execution cluster” slide split the world in two:

• At desk: Bazel and its local output base.
• In the cloud: bb-frontend, bb-storage, bb-scheduler and bb-worker, plus bb-portal and an artifact store.

bb-storage stores the Content Addressable Storage and Action Cache. bb-remote-execution provides the scheduler and workers. bb-portal is a web UI that displays builds from the Build Event Protocol.

Left: today’s split between desk and cloud. Right: “Moving the boundary”.

The next slide, “Moving the boundary”, showed the same diagram with yellow arrows pushing the line between “at desk” and “in the cloud” towards the developer’s side. That is the idea behind Bonanza. Its README calls it “an experimental build system that takes the remote execution model introduced by Bazel to the extreme”: Bazel uses remote execution only for build actions, while Bonanza “uses it for everything”. It reads BUILD.bazel files and ordinary .bzl rule definitions, works with Bazel Central Registry modules, and ships a bonanza_bazel tool that aims to be a drop-in replacement for the Bazel command line. The README also says it’s still highly experimental and can’t cache build results yet.

Bonanza’s evaluation framework: Skyframe-style, but built on Protobuf messages.

The slide on Bonanza’s evaluation framework was the one I found most interesting:

• It is “like Bazel’s Skyframe”, Bazel’s parallel evaluation and incrementality model, “but everything is Protobuf messages”.
• The client receives the full build graph after every build. As a result there is no need for a separate Build Event Stream, and no need for debugging flags like --toolchain_resolution_debug, --sandbox_debug or --verbose_failures.
• Recent work: centralised build graph caching, which the slide compared to Bazel’s “Skycache” (BazelCon 2025), along with “interesting ideas around ‘mega cache lookups’”.

Today, much of what you learn about a Bazel build comes from the Build Event Protocol and from those debug flags. A build graph that the client simply gets back after every run changes where build debugging happens.

Lightning talk: why Maven builds are slow

After the break, Sergey Chernov from Miro gave the lightning talk “Why Maven build is slow and how to make it faster?”. The slide I captured, “Split large modules to smaller”, showed one large module whose compile and test-compile phases depend on many upstream modules. Below it, the same work was split into smaller modules, each with its own compile and test-compile. The two takeaways next to the diagram were “Smaller modules have smaller set of upstream dependencies” and “Now built in parallel!”.

Splitting large Maven modules so they build in parallel.

Lightning talk: isolated builds are for designers too

The last lightning talk was “Isolated builds and workspaces are for designers just as much as engineers” by Jeff Hodsdon. His “Context” slide told a short history: “Digg was LAMP”, “Designers wrote html and css”, “Devs made it into php”, and now “Designers are back writing code” and “Designers desire ‘real’”. The last bullet was the point of the talk: “Supporting this with Bazel’s hermetic nature”. A later slide showed two IDE screenshots side by side, one of them labelled “Dev”.

Designers are back writing code, and hermetic builds let them work on the real thing.

The 7:30 pm unconference, networking and food closed the evening.

My take

From a platform engineering angle, the common thread was where the build runs and who pays for it. The EngFlow numbers and the Buildbarn diagrams describe the same idea: CI and developer builds stop being something each laptop and each CI runner does from scratch, and become a shared service with a cache, a scheduler and a worker pool. Teams already treat Kubernetes clusters and artifact registries as platform products. Remote build execution belongs in the same category, with an owner, SLOs and a cost model. Bonanza pushes this furthest, because analysis also moves into the cluster. That’s appealing for monorepo CI, where ephemeral runners often start from a cold Bazel server and redo analysis before any action runs. It also means your build cluster becomes as critical as your source control, so I’d want the same redundancy and observability for it.

The two lightning talks were a useful reality check. Many teams aren’t on Bazel and won’t be soon, and Sergey Chernov’s advice (smaller modules, fewer upstream dependencies, more parallelism) applies to Maven, Gradle and to how you split CI jobs. Jeff Hodsdon’s talk made a point I agree with: hermetic, reproducible workspaces aren’t just for backend engineers. If designers and other “occasional” contributors can get a working environment without a setup wiki, that’s a developer-experience win the platform team should measure and offer.

Related

• Bazel Multiple Python Versions with rules_python
• Bazel Remote Cache with bazel-remote: Setup and Debugging
• Debug Bazel Build Failures: BEP, Exec Logs, Sandbox
• Buildbarn on Kubernetes: Bazel Remote Execution Lab
• Speed Up Maven Builds: Modules, -T and the Build Cache
• Measuring Developer Experience
• Platform Engineering Metrics: How to Measure Success (2026)
• Tekton: Cloud-Native CI/CD Pipelines on Kubernetes
• Platform Engineering Amsterdam: This is FIN(e)TECH Meetup Recap