Schedule

In modern CI/CD, the traditional docker build is often the slowest link in the chain. Because standard Dockerfiles rely on imperative, sequential execution, they struggle with cache invalidation and lack the fine-grained dependency tracking needed for massive monorepos.

This workshop introduces a Graph-Based approach to containerization. By using Bazel, rulesoci, and rulesimg, we treat container layers as pure, declarative artifacts. This move allows us to assemble images in seconds, completely independent of a local Docker daemon. Attendees will learn how to transition from legacy “black box” builds to a transparent, content-addressable architecture that ensures what you build in CI is byte-for-byte identical to what runs in production.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

Take the Bazel Bootcamp for an introduction to Bazel, including what makes Bazel different from other build systems, how to set up your project with Bazel, and the basics of building and testing your code.

The workshop is aimed at beginner Bazel users.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

In this 90-minute workshop, we share our learnings from years of working on and with Bazel-deployments at scale. Beyond various stories of debugging mystical build issues, this includes a practical exploration of advanced Bazel concepts, focusing on rule authoring, performance optimization, and remote execution.

Through a series of diagnostic “break-fix” scenarios, participants will resolve architectural issues involving directory artifacts, improper action tagging and inefficient dependency fetching. These exercises are designed to bridge the gap between basic Bazel usage and scalable build engineering by demonstrating how specific configuration choices directly impact build speed and reliability.

The curriculum extends into custom test infrastructure, covering the development of test rules, sharding, and code coverage integration. To conclude, we will examine the use of action templates and ctx.actions.map_directory to translate external build logic into native Bazel actions.

By the end of the session, attendees will have a tactical framework for authoring robust rules and optimizing Bazel for large-scale, distributed environments.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

In this hands-on workshop, you’ll build a real JavaScript and TypeScript project from scratch, including a Node.js service, a type-checked and bundled web app, a test suite, and a watch-mode so the day-to-day developer loop feels familiar.

The Aspect team has maintained Bazel’s JavaScript story since 2017. rulesjs and rulests are the result: modern rulesets and toolchains that understand Node and pnpm, pair cleanly with TypeScript, and run the fast Rust and Go-based tools that the JS ecosystem has standardized on (esbuild, SWC, Vite, Rspack). If you’ve tried Bazel for JavaScript before and didn’t like it, this is the version that finally feels native.

This workshop is for all JavaScript and TypeScript developers, whether you’re evaluating Bazel for your team or already using it and want a faster, more modern JS toolchain. No prior Bazel experience required.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

Learn how to write your own Bazel rules. In this workshop, you’ll discover how to add support for code generation tools and new programming languages. You’ll gain a deeper understanding of how Bazel builds projects using rules and actions. Plus, you’ll get practical insights on writing efficient, scalable rulesets optimized for remote execution.

This session is led by Jay, an expert in the field. He led the development of rules_go and Gazelle while at Google, authored the “Writing Bazel rules” series, and now focuses on optimizing remote execution and caching at EngFlow.

This workshop is aimed at beginner to intermediate Bazel users. You should be familiar with basic concepts like build files and labels, but prior experience writing rules or macros isn’t required.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

Bazel is famously extensible, but most of that extensibility goes inwards, towards defining new rules. In this hands-on workshop, you’ll write AXL extensions live. You’ll write a custom aspect subcommand, a Starlark BUILD generator that matches your code conventions, and a CI integration that posts lint findings as inline annotations on a pull request.

AXL (Aspect Extension Language) opens up the outside of Bazel: the CLI, developer workflows, BUILD file generation, and how build results surface back into your CI. AXL is a Starlark dialect that Aspect has built directly into our open-source CLI. You can use it to script custom commands, create BUILD generators in Starlark (instead of Go Gazelle plugins), drive GitHub status checks, and use Buildkite annotations from the Build Event Stream (including lint findings with suggested fixes on the PR diff), and replace the brittle Bash and Makefile layer that usually sits between engineers and Bazel build. For platform and developer-experience teams, it’s the task-runner abstraction you’ve been hand-rolling out of shell scripts.

Aimed at Bazel users of all experience levels, from newcomers curious about Starlark to platform and DevX teams looking to standardize how their engineers interact with Bazel. Comfort with BUILD files and labels helps; prior Starlark experience is not required.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

How fast should my builds run? A Journey to understand build optimization.

During this training session, EngFlow Engineer Ricard and Product Manager Jorge will guide you through theoretical and Practical exercises to estimate the optimal execution time of a given target. From Critical Path to Build graph analysis and HW constraints.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

Python on Bazel has historically been a challenge: slow setup times, broken IDE integrations, and unpredictable virtualenv behavior. rules_py changes the game. Paired with the UV package manager, it provides lightning-fast dependency resolution, hermetic environments and virtualenvs that your editor and debugger actually understand.

In this hands-on workshop, we will build a production-ready application using Django, the most popular framework for web development in the Python ecosystem. We will walk through the entire developer loop:

• Dependency Management: Leveraging UV for high-performance package resolution.
• Zero-Maintenance Infrastructure: Automatic BUILD file generation through Aspect’s Starlark-based generators, keeping your project in sync without manual intervention.
• Development & Quality: Implementing testing with code coverage and integrating linters/formatters.
• Troubleshooting: Navigating common Python-on-Bazel pitfalls, such as circular dependencies and complex import structures.
• Production Readiness: Packaging the application for the cloud using OCI image generation for byte-for-byte identical builds from CI to production.

Aimed at Python developers at all stages, from those evaluating Bazel for the first time to experienced users looking to upgrade to a modern, faster Python toolchain with rules_py 2.0. No prior Bazel experience required.

Registration is complimentary, but pre-registration is required. To register, add a Training Day session to your BazelCon registration: https://events.linuxfoundation.org/bazelcon/register/

A technical case study from OpenAI on why Bazel’s execution model—hermetic actions, explicit dependency graphs, remote caching, and remote execution—is foundational for operating large-scale agentic software factories with swarming and single problem optimizers.

Over the past few months at OpenAI, we have been exploring how to coordinate thousands of agents processing tens of millions of tokens per minute to perform work across the entire software development lifecycle: designing architecture, planning changes, writing code, running builds and tests, reviewing diffs, qualifying releases, monitoring production, triaging incidents, and proposing fixes.

At that scale, the ability to make forward progress becomes dependent on how quickly and reliably agents can receive feedback on their work. Builds, tests, static analysis, and other validation steps must be fast, repeatable, hermetic, and machine-readable so agents can rapidly and safely explore many candidate changes in parallel.

Bazel with BuildBarn provides these primitives and we hope to explain how we found it to be leveraged.

A Bazel remote cache is a content-addressed blob store with a small mutable index on top. So is a modern version control system. This talk reports a proof of concept that treats them as one.

We back Bazel's remote cache with Lore, an open-source (MIT) content-addressed VCS built at Epic Games for terabyte-scale, asset-heavy monorepos. Source and build artifacts dedupe against a single store, so the client has nothing to upload before an action runs. A translation cache maps REAPI digests onto Lore's chunked CAS addresses without re-hashing or duplicating bytes; we've built layers like it before, backing build and data caches with Lore. On the worker side, inputs are faulted in lazily through a virtual filesystem instead of downloading the full tree first.

I'll bring numbers on storage footprint, cross-branch reuse, and remote-execution latency, and be specific about what works and what doesn't. If you run a large monorepo, especially one heavy on binary assets, you'll leave able to reason about whether your source and build layers should share storage, and what it costs.

macOS has long been the hardest place to run a fast, sandboxed Bazel build: sandbox-exec is slow, symlink forests thrash
the kernel, and legacy sandboxfs is unmaintained. So we built a new one. Using FSKit — Apple's user-space filesystem
framework in macOS 26/27 — our sandbox is a filesystem, and it outperforms native macOS sandboxing.

The core idea is content addressing, end to end. Every file and directory is keyed by its Merkle digest, so identical
subtrees across actions share a single filesystem node and a single vnode. The kernel's name cache stays warm across
thousands of actions — positive and negative lookups survive between builds — and the "change frontier" gets discovered by
the kernel for free, no invalidation bookkeeping. Content is materialized lazily and deduplicated across the entire build
on one shared mount: each input byte is copied at most once, and never if it's never read. Outputs write through to the
host volume, keeping collection a fast same-volume operation.

We'll walk through the FSKit and in-kernel LiveFS internals that make this work, how it plugs into Bazel, and the measured
results.

I wish to present a new Starlark language feature that the Bazel team at Google have been working on for the past year, and which are planning to launch in Bazel 10 – optional static type checking in Bazel's Starlark interpreter. The syntax is a subset of Python's type annotation syntax, but with different semantics.

In particular, Starlark functions will be able to declare types of arguments and return values, providers will be able to declare types of their fields, and .bzl files will be able to declare the types of the exported values; leading to more readable and maintainable code in large rule sets.

I will present an introduction to the new syntax, and briefly talk about rollout and compatibility with older Bazel versions.

I had presented my preliminary ideas at an unconference at BazelCon 2025 in Atlanta, but the syntax and semantics have evolved significantly since.

The talk will be of interest to developers of Bazel rules and macros, to developers of related build systems (especially Buck2) and of tools that operate on .bzl files, and to those integrating a Starlark interpreter in non-Bazel applications.

By dumping a Bazel process from a known good state, you can jumpstart arbitrary related builds later on, skipping repeated analysis. This is what powers “warm bazel” CI runners.

“Warm bazel” systems typically need a full-blown VM or container management system, such as Podman and Docker. But did you know you need none of that overhead? With some creative programming, you can run your own personal warm bazel, right inside your development environment: we present horapha, a little hack that will snapshot and restore the bazel that you run as your daily driver, allowing you to always have a bazel server ready to run in each of your source trees, without the memory costs of keeping them running continuously.

This talk is a case study of building an ultra-hermetic local execution sandbox. What started as a frustration with sandbox escapes due to tools following symlinks takes unexpected twists and turns through building custom filesystems and Bazeling the Linux kernel.

This description is purposefully vague to avoid spoilers but you can read more here: https://github.com/hermeticbuild/actiond/

Many in the community are excited about typing and type-checking coming to Starlark. It has been a long journey, and adoption will take time. This talk challenges the status quo and shows how you can type-check Starlark in your codebase today.

Recent Bazel versions can parse type annotations in `.bzl` files, but rulesets often support much older versions. Open-source Starlark will therefore remain partially annotated, inconsistently annotated, or unannotated for a long time.

Our key insight is that moving type-checking into an external tool sidesteps this versioning problem. It also enables alternative adoption strategies, including out-of-line `.bzli` stubs, generated declarations, and types derived from existing docstrings.

We built a working prototype on ty, Astral’s open-source Python type checker. It discovers `.bzl` files, resolves main-repository `load()` graphs, reports cross-file errors, integrates with IDEs, and supports go-to-definition.

Starlark is Python-shaped, but Bazel Starlark is not Python. We will show the semantic traps we hit, how we solved them, and what the ecosystem needs to make fast, robust standalone type-checking work broadly.

We'll give an update on recent developments in the remote caching and execution space and give the community an opportunity to influence the direction of future efforts.

Every monorepo team eventually hand-wires the same plumbing: scripts that scrape test output,
`POST` commit statuses, paste lint failures into pull requests, and stash logs where a reviewer
might find them. Your CI shouldn't need that glue. Run on GitHub, GitLab, Buildkite, or CircleCI,
and a single task reports through each provider's native surface, with no per-provider code,
because built-in features plug into typed traits (`buildevent`, `buildend`).

We'll walk a real pipeline before and after: status checks; a live PR/MR summary that rolls up
every job's pass/fail with repro commands; inline lint comments with one-click fixes; Buildkite
annotations; CircleCI Tests-tab results; and test logs, profiles, the exec log, and
`format`/`gazelle` patches that upload on their own. The templates are yours, and you can surface
your own tips right on the status checks and PR comments, where developers already look, instead of
hoping they read the log. Because AXL (the Aspect Extension Language, a Starlark dialect) hands you
the build's output stream client-side, the reporting is yours to extend too. You'll leave knowing
exactly which glue code to delete.

Once you start relying on transitions, you quickly end-up with a lot of configurations. This is particularly true with build “all” (bazel build //…) scenarios, where all the variations of your build coexist in the same build graph. With a higher number of parameters to transition upon comes the risk of creating build actions that vary only in unneeded and unused config options. This talk will cover how we identified discrepancies in otherwise identical actions, the techniques we used to aggressively reduce redundancy, and the tools Bazel offers to do so.
During that journey we went as far as splitting our libraries into configurable parts that need all the configuration options, and non-configurable parts that depend only on the target platform. We pushed Bazel to the limit of its capabilities, even uncovering bugs in dark corners of the code.
Bazel tools are of three kinds: reset transitions, path mapping and option scopes. For each, we will show how we applied them, their advantages, and the footguns they carry. At the moment, we have 3M+ configured actions, but “only” 500k actual actions running, and we keep lowering that number.

Birds of a Feather session for C++ developers using Bazel to discuss the Bazel C++ Rules.

The Android Birds of a Feather is a session for interested Bazel Android Developers to discussion the status and future of rules_android, the Bazel Android Rules.

Test execution time can frequently be mostly taken up by test startup: whether that’s starting a JVM, spinning up an emulator, or waiting for initialization code to execute. There have been past attempts at using Bazel’s persistent worker system to enable persistent test runners, but they’ve been unused and eventually reverted because they were too hard to use and only supported some test rules.

Join Antonio and John as they discuss the history of persistent test runners and explain their attempt to re-create this feature and make it extensible to more types of tests.

EngFlow operates Bazel multiple remote-execution clusters for organizations in finance, autonomous driving, and frontier AI, executing two billion of actions per week. Across that fleet, clusters fail in predictable ways, and the warning signs show up in the metrics well before anything pages.

This talk is field notes from operating that fleet. We will show where clusters actually break: action-cache eviction outpacing workload growth, queue depth under bursts, retry amplification from flaky tests, and the leading indicators that separate deployments that absorb a 10x demand increase from those that go down during the release cut.

One demand curve is new: agent-authored changes, which arrive in bursts, and are starting to decouple build volume from headcount. GitHub raised its capacity target from 10x to 30x in five months for the same reason. Manual PR reviews are an artificial throttling mechanism, which, once is more automated, puts even more pressure on build and CI pipelines. The fleet data shows which Bazel properties carry that load in practice: hermeticity, granular dependency tracking, and remote execution, backed by capacity planning that treats CI demand as a forecast, not a surprise.

You will leave with a shortlist of metrics to put on a dashboard this month, the thresholds that predicted trouble in our fleet, and what the most resilient Bazel deployments we operate do differently.

Bazel exposes a lot of data about builds, but that data is often too large or too low-level to easily parse and act on. This talk will walk through some tools we’ve built at BuildBuddy to transform raw build data, like execution logs and timing profiles, into structured artifacts that can be more easily read by humans and agents alike. Whether it’s catching regressions around non-determinism or identifying the source of slow builds, we’ll show how we integrate these tools with agents to debug builds faster.

What happens to software development when writing the code is no longer the hard part? Generation got cheap; verification — from compile and test through human code review — is now the bottleneck. This talk is about adapting your workflows to that inversion, and how we're meeting it at Aspect: from the now-GA Aspect CLI to what we're building next.

Your Bazel build is mostly opaque. You run `bazel build`, wait, and get an artifact or an error. But when it's slow, or it rebuilds something you expected to be cached, it's hard to see why. Bazel actually emits all of this; the information is just scattered across the event stream, a separate profile, and query output you assemble by hand.

bviz brings it together. It consumes the Build Event Stream live, or replays a saved build offline, and presents it as one interactive surface: a terminal you can scrub through, a dependency graph across Bazel's target, configured-target, and action levels, and a trace viewer showing where the time went.

I'll walk through a real build with it, and show how each view answers a concrete question — what ran, what depends on what, and where the time was spent.

In large monorepos, calculating affected targets is a persistent bottleneck, gating everything from IDE syncs to merge queues and CI/CD pipelines. This talk introduces Tango (Target Analyzer V2), an open-source, stateless microservice (github.com/uber/tango) that replaces traditional, slow calculations—often taking 3–8 minutes—with sub-20-second execution. We will demonstrate how Tango pairs an Incremental Target Graph (ITG) mutation strategy with a deterministic cache keyed on repository state via git treehash. You’ll learn how this architecture eliminates redundant Git checkouts and heavy Bazel queries by identifying identical states across PRs. Finally, we’ll show how Tango’s provider-agnostic core allows the Bazel community to plug in custom version control, execution engines, and storage backends to unlock sub-second target analysis.

`platforms_contrib` is a new community-maintained module that aims to define standard constraints for all the nuances of a target or execution platform that the `platforms` module misses, covering microarchitecture levels, CPU features, libc versions and more.
This talk briefly explains the design of the new module and walks the audience through its main use cases.

You change one line in a shared library and your pipeline redeploys half the fleet. The graph isn't
wrong; every transitively affected target really is rebuilt. But treating "rebuilt" as "must
redeploy" is what turns a typo fix into a 40-service rollout. `aspect delivery` breaks that link:
it content-hashes each deliverable's actual build outputs, compares them against a state backend
(`deliveryd`), and runs the push or publish step only where the bytes changed. We'll trace the
model end to end, covering how the output hashing works, how stamping stays deterministic, and how
the `DeliveryTrait` hook enriches the manifest with metadata like image digests. Expect a live
demo where a one-line change stops cascading into a fleet-wide rollout and collapses to the handful
of services that actually changed. You'll leave knowing which transitively dirty deploys you can
stop shipping.

At Canva we run Jest unit tests on our TypeScript frontend monorepo through Bazel, which handles bundling, type-checking, and testing — ~18k test suites executed millions of times a day on Remote Build Execution. At that scale the bottleneck wasn't test execution; it was delivering each test's node_modules transitive closure — thousands of files, ~1.2GB — to every action.

My talk walks through the approaches we tried to bring that cost down — tarballs, splitting by change frequency, read-only filesystem images, and finally in-memory mounts — and what each did and didn't solve.

I'll be providing concrete production numbers at scale, behind each step, such as test timings and compute savings.

Applications built by Bazel consist of an executable and a runfiles tree, the collection of files the program needs at runtime (libraries, data, interpreters). Container images built from these applications today typically bundle the entire runfiles tree into a single layer. Change one source file and you invalidate the whole layer, pushing hundreds of megabytes for a one-line change.

RunfilesGroupInfo solves this by partitioning the runfiles tree into named, ordered groups: interpreter, standard library, third-party dependencies, data, and application code. Each group becomes a separate container image layer.

In this talk, we'll cover:

• Adopting the protocol: What language rule authors need to do to support runfiles groups in their *_binary rules and how packaging rules consume them
• Impact of runfiles grouping for typical applications: How layered images reduce push sizes, enable shared base layers between services, and speed up incremental deployments
• Smart merging: When you hit a layer limit, groups merge automatically using rank and weight metadata

This talk is about Hermetic LLVM, a zero-sysroot, LLVM-based C/C++ toolchain for Bazel, and the lessons learned while making cross-builds truly hermetic. The original goal was strict: build everything from source, including the compiler; avoid relying on sysroots; keep prebuilt exec tools lightweight; cross compile from and to any supported platform; and make remote build execution work without setup.

Today, the support matrix spans all major exec platforms for 18 targets platforms. Compiler runtimes are compiled from source for all targets, packaged as an explicit input closure, so cross-compilation and cross-linking are modeled together instead of being delegated to /usr, Docker images, or executor setup.

We will cover the challenges of modelling all this as part of Bazel's graph, using constraints to model the runtime environment, and using transitions to represent 4 different toolchain stages: from a small seed toolchain to a source-built, runtime-complete one. We will also discuss making cross remote build first class by supporting the full exec/remote-exec/target platform matrix, and bridging the cross-link gap beyond C/C++ for cgo, Rust, Python extensions, etc.

rules_rs is a new ruleset for Rust focused on improving the pain points experienced at scale: Cargo dependency updates, keeping Cargo and Bazel builds in sync, toolchains for cross and remote builds, and Windows support.

At OpenAI, Cargo-bazel repins have improved from 10 minutes to 100 ms and happen as part of the bazel build invocation. rules_rs operates directly on Cargo-native metadata, uses the Bazel downloader and lockfile facts, and avoids a Bazel-specific Cargo lockfile. Build configuration is read from Cargo.toml at build time so Bazel configuration stays in sync without needing to run Gazelle.

We reuse this mechanism to build Rust stdlib from source, which allows supporting Tier3 platforms and Miri, all of which has been open-sourced.

rules_rs provides a broad support matrix of Rust triples that can be targeted in a cross-build compatible way: Linux GNU/musl, macOS, Windows MSVC/GNU/GNULVM.

Finally, we will cover the challenges with build scripts and how to make them hermetic and cross-build friendly.

This is a practical talk for people already using Rust with Bazel and looking for relief on common pain points.

This talk starts with the motivation for content-defined chunking in Bazel, including the large blob problem, common build patterns, and why action-specific optimizations are not enough.

We will explain how FastCDC and RepMaxCDC work, then cover the history of the SplitBlob and SpliceBlob additions to the Remote Execution API. From there, we will walk through Bazel’s native CDC support and how it integrates with the Action Cache, CAS, remote caching, and remote execution.

We will also cover other deployment paths, including using bb-clientd to bring CDC to older Bazel versions and reuse chunks across invocations, as well as Buildbarn server-side approaches. Finally, we will share production results and lessons from BuildBuddy, Meroton, and EngFlow, along with expected savings, practical recommendations, and future work.

Automating build migrations by writing a direct translator is an infinite game of whack-a-mole. Build systems often use Turing-complete configuration languages, configure-time file generation, and fundamentally different rule sets, which are virtually impossible to map cleanly.

In this talk, we focus on proving equivalence. By framing migration as a 'guess-and-verify' problem, we can let an imperfect oracle generate the BUILD files (human, script, or AI), and use equivalence to check the solution, find differences, and drive a feedback loop to adjust the result.

We describe the inherent challenges of this method, and show how we pull it off via an imperfect, but functional intermediate representation, resulting in one-shot migrations from CMake and Maven to Bazel.

Ulf Adams presenting via pre-recorded video.

Agentic workflows are here to stay and their usage in every company has skyrocketed in 2026. From the perspective of writing code, all may seem good, but when we look elsewhere—the CI pipelines, the build tools, the metrics—things aren't great. Development at Snowflake is no different, and we also have the scale problem.

We were lucky to finish our Bazel migration ahead of this unexpected change in the industry, and we were even luckier to stabilize our RE infrastructure by migrating from our self-hosted OSS instance to a fully-managed offering.

In this talk, we will present insights we have gained along the way:

• The differences in how humans and AI use Bazel and how we can guide AIs to do better.

• The need to support multiple agents running builds in parallel: people naturally reach for git worktrees but then they quickly run into resource contention.

• The increasing costs that our fine-grained auto-generated build graph induces in CI.

• The benefits we've gained from moving from our self-hosted RE to a fully-managed offering, and how the provider has helped us tame the cost increases with resource right-sizing.

• Advice on metrics we can extract from agentic workflows.

In a repository you will inevitably have a significant number of build and test actions which are overdescribed. That is actions that depend on files which are not actually used by the action itself.
For C++ compilations, Bazel has an internal optimization to not rerun compilations when an unused header file was modified, but this is not universal for all action types and only lives in the in memory state of Bazel, comparing the current compilation with the last compilation.
When using remote execution we get a controlled build environment where all the developers actions are run. This opens the opportunity to perform this optimization across the full developer collective, but also the ability to extend it to all action types.
In this talk, we explain how we generalize this to all actions when using remote execution, removing 20% of all our action executions.

Shipping a visually broken UI chips away at your credibility, especially when you’re a design company.

Visual regression testing is the standard approach to catch unintended visual changes. Render a UI, screenshot it, then compare it against a known good version from the main branch. However this is fundamentally at odds with Bazel. Committing screenshots solves hermeticity, but that introduces a whole host of other problems which rapidly become untenable at scale.

In this talk, I’ll share Canva’s approach to Bazelifying 20,000+ visreg tests using the BES and CAS. The same approach hermetically tests any kind of large assets without breaking Bazel guidelines, ballooning the git repo size, or compromising the developer experience.

You want to reuse a library from another language's ecosystem in your Bazel build. Too often that requires custom Bazel build configuration, checked-in generated integration code, or externally-managed package installations. You end up trading either per-dependency engineering effort, or correctness and hermeticity.

Zig is not an easy case. Its package manager configures builds through `build.zig`: arbitrary, Turing-complete code, where even the set of available configuration knobs can depend on other parameters or the host system. The 0.17 build-system rework separates configuration from execution, but the configuration phase still involves arbitrary code. Vendoring starts to look attractive under these conditions.

This talk shows a better way. I'll demonstrate how ruleszig imports Zig packages automatically and hermetically, with support for cross-compilation and remote execution. You'll leave understanding how ruleszig pulls this off, and where the same approach fits other code-driven package managers.

Bazel is known for fast, correct builds, but "correct" must include "secure". The Supply-Chain SIG is on a mission to help the Bazel community secure their builds and account for every byte in their artifacts. Marking the 1.0 release of package_metadata and core tooling, this talk provides a technical guide to production-ready supply chain tracking.
Our goal is to provide extensibility points for organizations to inject data and policy checks without patching dependencies or relying on coarser, ecosystem-specific manifests (e.g., pom.xml, go.mod, package.json). We will demonstrate how to leverage the package_metadata framework to enforce these custom compliance rules and generate provenance, natively integrated with industry-standard SBOM formats (SPDX and CycloneDX).
We will also discuss our upcoming roadmap for tackling deeper ecosystem challenges, such as tracking rules, module extensions, or macro definitions and their dependencies, while mapping out the path toward strict build-level enforcement. This session delivers the concrete implementation patterns needed to ship trustworthy artifacts to your users.

This talk will present rules_py//uv, a novel implementation of interacting with the Python ecosystem from Bazel based on Astral's UV tool.

We will discuss the challenges of implementing package managers generally, Bazel's phasing model and how we leverage UV's lock information to efficiently configure packages and provide advanced build graph features such as supporting arbitrary crossbuilds, hermetic source builds of the Python interpreter and hermetic builds of 3rdparty libraries.

Our focus is not so much the rulset itself, but to share techniques for writing efficient Bazel-native package managers such as the need to identify and configure hermetic downloads, implementations of dependency cycle resolution, hub repositories with multiple dependency contexts, examples of implementing other advanced features like conditional dependencies and Gazelle-like strategies for achieving phase interleaving without doing so.

A good multi-configuration build system should be able to satisfy all of the following requirements.
1. One target often needs to build many ways, like different optimization levels, operating systems, and CPU architectures.
2. Different targets in a monorepo often do not share identical build configurations and need some different build configurations.
3. Every target should build out of the box with a single command and no extra flags.

This talk compares how Bazel and Buck2 support multi-configuration builds. While both work similarly at a high level and supports the same concepts of configured build graphs, constraints, and selects, the specific features they offer have diverged in recent years. We will cover what each system gives you to define a configuration, pick one at build time, make builds work out of the box, and run many configurations at once. We will also look at how both are working to cut the cost of duplicate build actions across configurations and what to possibly look forward to in the future.

With the 1.0 release of package_metadata and core tooling, the Bazel ecosystem has a solid foundation for supply chain security. But a framework is only as good as the community using it. This Birds of a Feather (BoF) session is an open, unscripted forum for ruleset maintainers, security engineers, and compliance teams to share real-world experiences and shape what comes next.

We want to hear from you. What are your biggest pain points when generating SBOMs (SPDX/CycloneDX) or chasing SLSA compliance? Where do existing ecosystem-specific manifests fall short in your production Bazel builds?

This is your space to directly influence the Supply-Chain SIG’s roadmap. We will openly discuss upcoming challenges, like tracking rules, module extensions, and macro definitions, and debate the path toward strict build-level enforcement. Bring your corporate compliance checklists, your technical edge cases, or just your questions. Let’s collaborate to figure out exactly what the community needs next to account for every byte.

Birds of a feather session for Swift / Apple platform development

Two years ago, modernizing a foundational framework across Uber's Java monorepo meant a multi-quarter, hand-rolled effort with bespoke tooling every time. Today, it's a repeatable platform built on Bazel.

We'll walk through how we migrated 75,000+ test classes from JUnit 4 to JUnit 5 touching 1.25M lines of code across 5,000+
diffs in four months and how we extended the same playbook to a harder problem: migrating services from Spring Boot 2 to
Spring Boot 4 incrementally, one service at a time.

The architecture is three Bazel-native pieces working together: aspects extract each target's classpath and source files,
OpenRewrite applies deterministic semantic refactors, and transitions let a single service run on the new framework while its
neighbors stay on the old one, containing the blast radius of any regression to exactly one service. For the long tail of edge
cases not worth encoding as recipes, we reach for AI-assisted refactors.

Attendees will leave with a concrete blueprint for turning one-off migrations into a platform capability and a clear view of
where deterministic transformations win, and where AI fills the gaps.

As always, we will discuss the state of IDE support in Bazel, the ongoing efforts by JetBrains, Google and others in maintaining the Bazel plugin for IntelliJ, CLion and other IDEs. All IDE plugin developers are welcome to contribute during the session; please get in touch with the speakers.

Discuss topics surrounding Bzlmod, Bazel's new external dependency management system.

Gazelle is an extensible BUILD file generator for Bazel. This talk shows how to support new rule sets by writing an extension with Gazelle's new v2 API, which supports better error handling and dependency resolution. We'll also talk about how Gazelle works with extensions, how to support offline indexing, and how to write extensions in languages other than Go.

This talk shows how to explode CUDA compilation into a fine-grained Bazel action graph. Instead of treating a CUDA compile as one large opaque action, we split host compilation, per-architecture device compilation, PTX-to-cubin assembly, fatbinary construction, fatbinary embedding, and linking into explicit actions. We will also discuss how to reduce unnecessary dependencies between host and device compilation, especially around CUDA kernel launcher generation.

Finally, we will show what this unlocks in practice: Dramatic speedup in CUDA compilation that scales with remote execution instead of being bottlenecked by a single compiler invocation.

Combined with a hermetic CUDA toolchain, we will show how this makes CUDA builds more reproducible, cacheable, and distributable. Bazel can then parallelize work across GPU architectures and compilation phases, execute actions remotely, and significantly reduce build times for CUDA-heavy codebases.

Watch mode is the inner loop of modern development: save a file, see a result.

In Bazel, that loop is usually powered by iBazel, a nifty tool built on a protocol from a different era. It tells your dev server *that* a build happened, but never *what* changed using 'stdout' as its signaling channel. The build tool never gets a word in.

This talk walks through a different design: the Incremental Build Protocol. A small, versioned, bidirectional protocol where the host and build tool actually talk. It hands the tool the exact set of files that changed, so it can make the optimal adjustment instead of guessing. It leaves your output streams alone for real program output and it lets both sides negotiate capabilities and report back when work succeeds or fails.

We'll look at the initial Go and JS implementations, how Watchman drives source change detection, and how the Bazel `execlog` let's you see exactly what changed in the build graph (not just that something did).

aspectrulespy 2.x rewrites the Python execution layer on Bazel. This session compares 1.x vs 2.x side-by-side: why the Rust-based venv/shim/unpack tools and Bash launchers reached their limits, and how 2.x replaces them with a real virtualenv assembled via Bazel symlinks at analysis time and a native hermeticlauncher that execves directly into the interpreter. We will cover venv → depgroup (PEP 735), opt-in .venv exposure, the new pyimagelayer/pylayertiermodel, and the concrete migration checklist. Attendees will learn how 2.x improves hermeticity, RBE caching, startup latency, and cross-platform maintenance, and how to prepare their projects for migration.

Adding support for a new language or rule in Gazelle usually means writing a Go extension against a low-level API, compiling it into your `gazelle_binary`, and often pulling in a CGo toolchain along with it. It's more work than it should be.

This talk shares a different approach: writing Gazelle `BUILD` generators as Starlark plugins. No new languages, nothing to compile. You just drop an `.axl` file into your repo and it becomes part of your BUILD generation.

You'll start with a basic generator that emits one target per source file in a few lines. Then work up to full dependency resolution: parsing source files to find imports and wiring up `deps` automatically. That includes cross-language dependencies, where a target in one language depends on targets generated by another.

By the end, you'll know how to add automatic `BUILD` generation for any language Gazelle doesn't support.

Many Python teams end up with one Dockerfile per service or job. Each repeats runtime knowledge the build graph already has: Python entrypoints, pip packages, apt packages, env vars, and hand-tuned layer ordering. Often, this leads to one base image carrying deps from many apps.

This talk follows an implementation arc from a monorepo full of Dockerfiles to a higher-level pyimage macro built on rulesdistroless, rulespython, rulesoci, toml.bzl, and custom aspects. The public API is small: pyimage(name = "myimage", pybinary = ":mymain").

The talk walks through the macro stage by stage: inferring apt deps and env vars with aspects; producing per-pip-package tar files so Bazel actions are shared across images; normalizing path prefixes so layer hashes line up across applications; ordering pip layers by size for faster image loading; flattening the long tail to stay under Docker's layer cap; and deriving size hints from distroless providers and uv.lock, so layer tuning works without per-image config or a global size map.

Attendees will leave with a practical pattern for making Python images simple to define, faster to build, and easier to scale across many applications.

Bazel ecosystems give teams flexibility, but flexibility at scale leads to divergent configurations, dependency drift, and growing operational complexity. What starts as local autonomy becomes an organisational liability: platform upgrades stall, security responses slow down, and improvements require coordinating hundreds of teams.

At Adobe, we chose to build a sealed Bazel platform where service teams own their application code but the platform owns build configuration, dependency management, remote execution, caching, and supply-chain policy – enforced, not suggested. The platform retains full control; owning the dependency graph centrally means the platform can deliver upgrades and security patches to 10k+ services across hundreds of engineering teams with a single change.

This talk covers the philosophy behind a sealed paved road, how we use Bzlmod to expose a versioned platform interface, how platform-owned rules and curated dependency repositories (@javadeps, @pythondeps) enforce consistency at scale and what we learned at fleet scale, including where sealed was the right call and where it wasn't.