Skip to content

Engineering Developer Tools at Scale: London Build Meetup

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.

Taming Go Linting at 40 Million Lines of Code: Beating the NoGo Bottleneck

By Frederic Marand, Deliveroo

Deliveroo's core monorepo recently expanded from 10 million to over 40 million lines of code. With hundreds of pull requests adding over 2 million lines per week, static analysis must run on every single build. More than half of Deliveroo's codebase uses Go, relying on Bazel's integrated NoGo tool for linting.

Frederic shared how Go linting became a major performance hurdle and how his team fixed it:

  • Profiling results: In a repository with over 100,000 Go packages, profiling showed that only 25% of linting time went to actual analysis. The other 75% was swallowed by process overhead—mainly decoding facts from earlier steps and running cross-package type checks.
  • Scope creep: Custom domain-specific analyzers added to feature branches inadvertently ran across the entire monorepo due to Bazel's dependency model. Removing these unneeded analyzers immediately restored baseline speed.
  • Workers and flags: Deliveroo used persistent workers and Bazel's remote action cache to stop re-decoding package facts on fresh processes. Frederic also highlighted an undocumented flag in rules_go (library.bzl) that lets teams run fast incremental linting passes without triggering full compilation runs.

Next-Gen Container Packaging with rules_mg: Saving 80% CI Storage Pressure with Lazy Push

By Utkarsh Jain, DoorDash

Building and publishing container images inside large monorepos puts massive pressure on CI runner disk space. Utkarsh from DoorDash's Code Scalability team showed why traditional Docker workflows struggle at scale.

Standard rules_oci pipelines force local CI runners to download all layer blobs from remote caches just to check registry states. At DoorDash's scale, this used up to 1 TB of temporary storage per runner, forcing frequent hardware upgrades.

DoorDash switched to rules_mg and its Lazy Push architecture to fix this:

  • Streaming metadata: Instead of downloading gigabytes of layer archives, rules_mg fetches only lightweight metadata. It compares manifests between the remote cache and the container registry, streaming missing layers directly between them without hitting the local runner disk.
  • 80% less disk use: Benchmarks showed an ~80% drop in runner disk usage, removing storage bottlenecks on build agents and speeding up deployments.
  • Parallel pushes: By splitting container publishing into parallel execution tasks, layer blobs stream directly from remote execution nodes to the registry during the build step.

Demystifying Bazel Platforms: Execution Targets and Hermetic Toolchains at Scale

By Yannic Bonenberger, EngFlow

Bazel Platforms are essential for modern build infrastructure, yet they are frequently misunderstood. As systems grow across multiple CPU architectures and languages, clear execution boundaries become critical.

Yannic explained how Bazel Platform configurations work under the hood. Platform definitions determine where build actions run and control how Bazel selects toolchains for compiling, linking, and testing. Setting up clear platform constraints eliminates host-machine dependencies, ensuring consistent cross-compiled build environments across distributed monorepos.

Scaling Infrastructure When Verification Is the Bottleneck

Code generation and iteration speeds keep accelerating. However, as repositories reach tens of millions of lines, verification—whether type-checking, linting, or container packaging—remains the primary operational bottleneck.

Tools like Bazel platform rules, persistent worker linting, and streaming container architectures show how infrastructure teams are adapting to keep up with that scale.

Want to co-host a meetup or see where we're heading next? Check out meetup.build. If you have questions about optimizing your Bazel builds, reach out to the EngFlow team.