You can now run BuildBuddy Workflows on a recurring schedule using standard cron expressions. This is useful for nightly builds, periodic integration tests, or any job that should run independently of code pushes or pull requests.

To schedule an action, add a schedule trigger with one or more cron expressions under triggers:

actions:
  - name: "Nightly tests"
    triggers:
      schedule:
        crons:
          - "0 2 * * *" # 2:00 AM UTC every day
    steps:
      - run: "bazel test //..."

Scheduled runs always execute against the latest commit on your repo's default branch. All cron times are interpreted as UTC, and the minimum supported interval between triggers is 15 minutes.

Starting June 1, 2026, BuildBuddy will automatically cancel in-progress Workflow runs when a newer run is triggered for the same action on a non-default branch. This helps avoid wasting resources on outdated runs when, for example, several commits are pushed in quick succession to a pull request branch.

This behavior only applies to non-default branches. Runs on your repo's default branch are not affected.

If you'd like to disable this behavior and allow concurrent runs for an action, set allow_concurrent_runs: true in the action's configuration.

We're excited to announce end-to-end content-defined chunking (CDC) support for Bazel remote caching in BuildBuddy.

With Bazel 9.1 and 8.7 support for --experimental_remote_cache_chunking, large outputs like linker artifacts can be uploaded and downloaded in content-defined chunks instead of as monolithic blobs. That lets BuildBuddy deduplicate similar artifacts across builds, reducing upload bandwidth and storage usage. In one benchmark on the BuildBuddy repo, this showed roughly 40% less uploaded data and a roughly 40% smaller disk cache. Breaking large blobs into smaller reusable pieces also means fewer long-running RPCs and more granular retries.

To enable it, add this flag to your .bazelrc:

common --experimental_remote_cache_chunking

To see the download-side savings, you should also set --disk_cache, since the downloaded chunks need to be stored somewhere in order to be reused locally. We also recommend setting --experimental_disk_cache_gc_max_age to a value below your remote cache TTL—for example, 3h, or 1d if your remote TTL is longer.

Bazel 9.1 and 8.7 support this flag.

BuildBuddy now exposes an MCP endpoint for coding agents and other MCP-capable clients.

MCP provides a way to let agents explore BuildBuddy data for mostly read-only workflows like build and test metadata, logs, artifacts, target statuses, and more.

You can connect agents like Codex, Claude Code, and Gemini CLI to:

https://YOUR-BUILDBUDDY-ORGANIZATION.buildbuddy.io/mcp

Authenticate with:

Authorization: Bearer <api-key>

BuildBuddy has supported passing short-lived secrets to remote actions via the env-overrides platform property, which redacts values from action cache entries. The new secret-env-overrides and secret-env-overrides-base64 properties extend this protection by also redacting values from workflow logs.

Pass secrets via remote exec headers so they're injected at invocation time without affecting the action hash:

bazel build //my:target \
  --remote_exec_header=x-buildbuddy-platform.secret-env-overrides=API_KEY=sk-abc123,OTHER_KEY=val

For values containing commas or special characters, base64-encode each KEY=VALUE pair:

bazel build //my:target \
  --remote_exec_header=x-buildbuddy-platform.secret-env-overrides-base64=$(echo -n 'CREDS={"token": "abc"}' | base64)

GPU support for self-hosted Linux executors is now easier to set up.

BuildBuddy's executor image now ships with GPU supporting tools (nvidia-cdi-hook), and the executor now supports configuring CDI devices so executors can pass through vendor-provided GPU device configuration to child containers.

bb explain shows a structural diff of two compact execution logs. It helps answer the common questions: "Why did Bazel re-execute that action?" and "What changed between these builds?"

It can highlight non-hermetic outputs and differences in inputs, environment variables, and arguments.

It works with your last two builds automatically, or you can point it at any invocation IDs:

bb explain
bb explain --old <OLD_INVOCATION_ID> --new <NEW_INVOCATION_ID>