This post is based on the BazelCon 2026 talk I gave with Antonio Di Stefano (Frekt.dev). You can watch the recording on YouTube below.
Bazel has used persistent workers for years to make compilation faster. A persistent test runner applies the same idea to tests: keep a long-running test execution process alive and reuse it across multiple tests, instead of paying its warmup cost every time.
We’re fond of Bazel, and particularly fond of the capabilities it offers developers. Faster builds, made more efficient through remote execution and caching, made more understandable through declarative configuration, queryability, and precise logging – these deliver benefits and solutions to developers once Bazel’s all set up and integrated into their daily processes.
But it’s a rare developer who enjoys spending their time and effort in build system configuration. Wouldn’t we rather be solving our customers’ problems? And the decision to migrate from an existing build system to Bazel is one that demands consideration of huge trade-offs; the labor and opportunity costs of engineering time spent on migration and adapting internal workflows to a new build system discourage the pursuit of its advantages.
Bazel makes your builds correct and reproducible. Making them fast, and keeping them fast as your codebase and your team grow, is a different problem. It's the very problem that EngFlow was created to solve. Our team spent years on the adoption side of Bazel, helping companies put it into production, contributing and creating Bazel's core features, and the pattern is almost always the same: teams love what Bazel does for correctness, then run straight into what it costs to operate for speed.
Today, that's much easier to reach. EngFlow, the platform that runs the largest managed Bazel fleet in the world, with over 3 billion build and test actions every week for teams like Arm, Databricks, and Canva, is now one install away for every team on Origin. Read more about this in Origins's announcement on X (Twitter) and Linkedin.
A conversation with Titus Winters · Notes From The Fleet series
I sat down with Titus Winters to talk about developer experience and infrastructure at scale. Titus co-wrote Software Engineering at Google; he is now a Senior Principal Scientist at Adobe. I expected a conversation about build systems. What I got was a line I've been thinking about ever since:
"The question is not what can you build with an incredibly fast, 80% accurate tool. It's what can't you build with an infinite army of incredibly fast, 80% accurate tools."
An infinite army of 80% accurate tools. That army doesn't have a code generation problem. It has a verification problem. Whether it helps you or buries you depends on the systems that check, integrate, and maintain everything it produces.
EngFlow and Deliveroo (a DoorDash company) recently co-hosted a Build Meetup at Deliveroo's London offices. The event came together thanks to Matt from Deliveroo's engineering management team and Vaibhav from EngFlow, who brought together engineers from Deliveroo, EngFlow, Jane Street, and the local build community.
While talks spanned Bazel, Buck2, and Dune, a central theme emerged: as enterprise codebases grow past tens of millions of lines, the main bottleneck moves from writing code to testing and packaging it.
Here is a breakdown of the three technical presentations from the event.
Back in June I was sitting on a train to Zurich. The plan was to meet colleagues and work together on figuring out how to migrate CMake projects to Bazel. I was looking forward to chatting with my colleagues in person, but I was not optimistic about the migration process. Truth be told, I was expecting to spend the week walking through the problems parsing the custom CMake language and CMake being Turing complete, maybe even look at a few concrete cases like generated files and configuration flags, finally conclude it couldn't be done, and return home with not much to show. Oh boy was I wrong.
The EngFlow fleet just crossed 3.5 billion actions processed per week. Fourteen months ago, that number was 250 million. That's roughly 14x growth in 14 months.
This isn't a vanity metric. It's a signal of the developer efficiency our platform enables, and of the scale at which we now operate, managing some of the world's most complex and demanding platform engineering workflows for enterprises including ARM, Asana, Block, BMW, Canva, Databricks, Plaid, and Zoox.
On July 28, 2026, Uber and EngFlow co-hosted a Build Meetup at Uber’s Seattle office. This wouldn’t have been possible without the help of Sergey Balabanov at Uber, who not only presented one of the talks, but also energetically arranged and helped support this event from the Uber side. Thanks again, Sergey!
And, even though nobody planned a theme for this particular meetup (our meetups are holistically focused on “Build, Scale, Investigate”), one showed up anyway. Code is getting cheaper to produce. Uber put it flatly: “AI is a problem, apparently.” Every talk examined some part of the machinery that turns abundant code into software you can trust. Let’s take a look!
Every build tells a story. Which targets took the longest? Where did cache misses cost you minutes? Who triggered the invocation, and what source changes drove it? At EngFlow, we believe that surfacing these answers — automatically and at scale — transforms build optimization from reactive firefighting into proactive engineering. Today, we're sharing how our build analytics platform evolved from early prototypes to a production-grade system providing tangible value to our customers.
Today, the new https://bazel.build/ website has finally launched. This is the first step in a larger evolution of Bazel's documentation story. Much of the content remains the same (the eagle-eyed among you may notice a few new pages), but this change marks a new era of Bazel documentation.
The Bazel site migration is more than just a fresh coat of paint. One of the underlying motivations for this change is to empower the Bazel community to make more changes to Bazel's documentation. Before the migration, Bazel's website was built on Google documentation infrastructure. While the capabilities of that infrastructure were largely sufficient for Bazel's needs up to now, the contribution experience was not.
Today's https://bazel.build/ is built on Mintlify. With this new platform, each incoming documentation pull request to Bazel is automatically greeted with a preview. For even faster iteration, you can build the site locally. These improvements eliminate guesswork, and better equip contributors to make changes to the Bazel docs with confidence.