Skip to content

Over 3 Billion Actions per Week: A Year Inside the World's Largest Bazel Fleet

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.

14x growth in build actions

14x growth in 14 months in build actions per week across the EngFlow fleet.

Three non-negotiables at 10x load

Over the past year, our customers have been pushing the scale limits of cloud providers, their own infrastructure, and ours. As they absorbed AI-driven surges in pull request volume and the early wave of agentic workflows, we found ourselves optimizing against three constraints simultaneously, all while absorbing up to 10x more load:

  • Performance: keep build and test times flat (or better) as volume climbs, not degrade proportionally with it.
  • Stability: handle bursty, unpredictable capacity spikes gracefully, without the queue collapsing under its own weight.
  • Cost-efficiency: make sure cloud spend doesn't scale linearly with action volume. 10x the load should never mean 10x the bill.

The first real signal of this new scale came from customer hackathons, where we watched AI-driven workflows generate bursts of load unlike anything in our historical traffic patterns. Those events exposed real gaps in our scaling and observability, and fixing them is what let our customers absorb a 50% increase in load with less than a 13% increase in cloud cost.

What we shipped to get there

A few of the changes that made the biggest difference:

  • Resolving issues in third party software, like Rust HTTP2 library and a Linux bug in EXT4 filesystem where the multi-block allocator was underperforming on large partitions (45T), which resulted in disabling RAID-aware allocation optimization.
  • Implementing Input deduplication, cloud-agnostic graceful worker shutdown, worker pull rolls, which together drove an 8x reduction in P95 build/test times.
  • Launching the content-defined chunking for our Content-Addressable Storage, cutting build artifact storage costs by 50%.
  • Shipping a production-grade build analytics pipeline and enhanced observability, giving customers the target-level visibility needed to find and eliminate redundant build and test work. Using this tooling, some of our customers achieved a 50% reduction in build duration at p90 and p95 without adding a single core.

2026 is the year of Bazel

As AI-accelerated workflows push development teams toward serious infrastructure investment, we're seeing a real acceleration in Bazel adoption. Bazel, which 16 of our team members helped create at Google and beyond and continue to contribute to, is becoming the default answer for build management at AI scale: the most robust, scalable build system with the widest open-source community support of any option out there.

Bazel has always been the serious answer for teams that hit real software scale. Companies like SpaceX, Uber, Stripe, and Databricks have been running it in production for years since its open source beta in 2015. For a long time, Bazel had a reputation for being powerful but difficult: the tool you adopted once your codebase, CI system, or engineering org had already outgrown traditional build tools. AI changes the timing. More generated code means more builds, more tests, more artifacts, more failures, and more pressure on the entire software delivery system. Problems that used to show up only at Google scale are now showing up much earlier for a much wider range of companies.

To meet customers where they are, the EngFlow platform provides remote caching, remote execution, and observability for Bazel, Buck2, CMake, Chromium, and AOSP. Given the uptick we're seeing in Bazel migrations specifically, we're now also offering migration services and AI migration tooling to accelerate that adoption (more on that in a future post). We're seeing this play out in the field with Iterable cutting its P90 build time from 42 minutes to 17 minutes after migrating its Scala backend from sbt to Bazel with EngFlow, the kind of foundation that makes AI-era PR volume absorbable instead of a fire drill.

The growth curve isn't flattening

At our company-wide summit in Munich this May, I presented this same chart with 1.75 billion actions per week. From May to August, our fleet volume doubled to 3.5 billion actions per week. In this video at our company-wide summit in Munich, our customers who are operating at tremendous scale, Canva and Snowflake, commented on the importance of implementing Bazel and EngFlow in order to be ready for the scale that they faced over the past 12 months. As that growth continues, so does our investment in performance, stability, and cost-efficiency, so our customers can keep absorbing AI-driven volume without it becoming a crisis in their developer infrastructure. What's your actions-per-week metric, and how fast is it doubling?

In this blog series, I'll keep unpacking the challenges and solutions behind build management at this scale. Next is my interview with Titus Winters on why robust and scalable developer infrastructure investment matters now more than ever.