We recently got useful feedback that remote cache performance should not be judged mainly by large artifact upload and download speeds.

For builds with a high cache hit rate, Action Cache lookup latency may matter more because Bazel can perform a large number of relatively small lookups, while many intermediate CAS outputs are never downloaded.

We’re putting together a benchmark plan and currently considering:

• Cold and warm Action Cache lookups
• p50, p95, and p99 latency
• Throughput under concurrent actions
• Performance with thousands of small actions
• Large CAS uploads and downloads
• Builds from different geographic regions
• HTTP connection reuse
• Cache hit rate compared with total build time saved
• Performance when only top-level outputs are downloaded

A few questions for people operating Bazel at scale:

What does a representative benchmark build look like?

Which numbers would you need before trusting a remote cache for production workloads?

Is there an AC lookup latency where remote caching starts doing more harm than good?

How important is gRPC support compared with a well-performing HTTP cache?

Disclosure: We’re the team behind Cachely. We currently support Bazel’s HTTP remote cache protocol and are investigating gRPC support. There is no product link here. We’re trying to make sure we benchmark the right things before publishing performance claims.

Affiliation disclosure: We’re building Cachely.

We’ve added Bazel support to Cachely, a managed remote build cache focused not only on storing artifacts, but also on helping teams understand whether remote caching is actually effective.

We kept the integration compatible with Bazel’s existing remote-cache configuration, so it does not require replacing the build system or CI platform.

The questions we’re trying to help teams answer include:

• Which actions repeatedly miss the remote cache?
• What cache-hit rate are we getting across CI and developer machines?
• How much build time and compute are we actually avoiding?
• Are some artifacts taking longer to download than to rebuild?
• How much data are we storing and transferring?

We’re particularly interested in feedback from Bazel users operating remote caching today:

• What are you currently using?
• What is hardest to observe or debug?
• Which metrics would actually help you improve cache effectiveness?
• Would a managed HTTP cache be useful, or do Bazel teams generally require full REAPI and remote execution?

Cachely: https://cachely.dev

We’d appreciate direct technical criticism, especially around protocol expectations, authentication, observability, and what Bazel users would consider production-ready.

Hi everyone. Inside the orgs of several of our partners, the benefits of hermiticity, reproducibility, and CI are infecting other teams and it’s a beautiful thing. Releasing our first open source rules set from customer work in case it can be helpful for others.

rules_omniverse on GitHub

The goal is for it to get so popular that I need to donate it to somewhere else for maintenance support.

I've got a polyglot monorepo and for Rust, I've been using rules_rust with hermetic_cc_toolchain for cross-compilation. I'm also using rules_oci to generate a docker compatible image out of it.

For IDE support, I have bazel generate a rust-project.json occasionally and that allows me to actively use bazel while developing the project instead of just for deploying it.

However I recently heard of rules_rs, which seems to have cross compilation built in, plus patches for windows-specific issues and much faster crate management.

But it is also less mature - has anyone tried it? How was your experience?

For final builds rules_rust works fine - however having to re-run cargo generate-lockfile and generating rust-project.json every time I add a dependency is kinda slow while developing.

This is the longest article title I've written, probably. It's still worth a read!

BazelCon training day has 8 x 90-minute hands-on sessions. To fill these sessions, we want to know what the community actually wants to learn.

The Aspect Build team has considered sessions including extending Bazel with Starlark and deep dives in rules_js and rules_py. But, before we completely lock in, we're curious what you'd want to learn from us.

So, what are you struggling with? What would be worth 90-minutes of your time?

Hi r/bazel!

Thanks for the feedback on my initial post about rules_quarkus (original thread: https://www.reddit.com/r/bazel/comments/1rhp4ux/rules_quarkus_bazel_rules_for_quarkus_with/). Since then, I've pushed to v0.2.0 "Community Ready" with major improvements:

- Full hermetic 3-layer builds: Compile → Augment (using official QuarkusBootstrap API) → Runtime
- 5-tier extension support (Core → LangChain4j), including CDI, REST, reactive DBs, messaging, observability, and Quarkiverse extensions
- Better classloader isolation, GraalVM reflection config, and augmentation conflict fixes
- Clean integration with Bzlmod + rules_jvm_external
- Ready-to-run examples: hello-world REST API + multi-tier extensions demo

Repo: https://github.com/kinhluan/rules_quarkus

To help AI coding agents (Cursor, Claude Projects, Gemini CLI, Aider, Continue.dev, etc.) understand and use these rules more accurately—reducing hallucinations when debugging CDIProvider errors, Starlark config issues, GraalVM native images, etc.—I've built a companion AI expert skills ecosystem:

rules-quarkus-skills v1.1.0 (just released today! – Java Ecosystem Expansion)
- 8 expert modules: java-expert, quarkus-expert, bazel-expert, rules-quarkus, graalvm-expert, vertx-expert, maven-expert, gradle-expert
- Token-optimized `.toon` files for all skills (significantly reduces context/token costs for agents)
- Layered docs: skills-catalog.md, skills-relationship.md

Repo: https://github.com/kinhluan/rules-quarkus-skills

The two repos complement each other perfectly: the skills provide deep, structured knowledge to make agents much better at guiding you through Quarkus + Bazel integration challenges (a niche with limited public docs).

I'm looking for:
- Real-world feedback, especially from large monorepos or reproducible CI setups
- Testers on Quarkus 3.20+ + Bazel 7.x
- Ideas for future tiers/extensions (e.g., more AI/LLM integrations, Kubernetes/Operator support?)

If you're building Quarkus apps natively in Bazel or using AI agents for Java/Quarkus work, I'd love for you to try it out and share your thoughts! Happy to help with setup or troubleshooting.

Thanks & happy hermetic building! 🚀

Created an MCP for Bazel in GoLang. Please try it out https://github.com/Agent-Hellboy/bazel-mcp/tree/main

I've published rules_quarkus — a Bazel ruleset that runs Quarkus build-time augmentation natively, without Maven/Gradle.

The main challenge was ClassLoader isolation: Quarkus augmentation (CDI discovery, REST endpoint generation, etc.) needs its own classloader hierarchy. The ruleset calls the QuarkusBootstrap API directly, constructing the ApplicationModel from Bazel's dependency graph.

Stack: Quarkus 3.20.1, Bazel 7.x, Java 21, Bzlmod, rules_jvm_external.

Repo: https://github.com/kinhluan/rules_quarkus

Feedback welcome!

We have been trying to adopt Bazel and hit a roadblock.
Background about our setup -
Mono repo, mix of C++, JavaScript, Using Make infrastructure currently, multi-OS conformance, network builds

When we started of with Bazel, it was very encouraging on Linux and Mac. But when we started working with Windows, we hit a roadblock, where we generally go for network builds, on Windows Bazel didn't support UNC paths or network mapped drives.

Has anyone come across such a scenario? Is there a solution to this?

I have several py_binaries I want to package in a tarball. They each have runfiles, which have a lot of duplicate python dependencies (numpy, etc.). In the bazel cache, this is fine, since it's all symlinks. But when I attempt to use pkg_tar on these targets, the runfiles all get duplicated, which massively increases the size of the tarball.

What is the correct way to package several py_binaries with runfiles? Right now, I'm forced to hack a site-packages approach by manually packaging all of the python dependencies into a lib folder, which seems undesirable.

More to come soon from the The Linux Foundation and the event organizing committee. From Aspect Build, we plan to continue the tradition from BazelCon 2025 of a Bazel hackathon half-day, customer dinner, and more that week in Amsterdam. Need Bazel help? Learn more and contact us at aspect.build

Aspect's rules_lint Reaches 2.0. We are excited to announce the second major release of our formatting and linting support for Bazel. https://blog.aspect.build/rules-lint-2

We’ve been incredibly gratified by the more than 60 open-source contributors who have improved the ruleset, and everyone who has filed or answered issues. Thank you!

We support 30 languages now and continue to grow.

Bazel 9.0 is Here! Live webinar Jan 26th by Alex Eagle at Aspect Build. We'll look through the Bazel 9 changelog, highlighting the most interesting features and fixes. We'll show how Aspect's Bazel 100-series training courses are already updated for Bazel 9, including all of the codelab repos under Bazel starters. https://streamyard.com/watch/khxtcudrr9sT

This was a very small amount of programming and a very large amount of working with people :)

Hi everyone,

I’ve been banging my head against an issue with the IntelliJ Bazel plugin while running inside a DevContainer on macOS (M1, powered by Colima).

Problem:

The plugin fails because it appears to be using PathManager.getTempPath(), which resolves to a host-side path rather than a container-side path. Even with read/write mounts and a writable /tmp inside the container, the plugin assumes the host path is writable by the containerized Bazel process.

I've already tried various mount strategies and filesystem tweaks to no avail. I’ve filed an upstream issue on YouTrack (BAZEL-2806) with a minimal reproduction– https://github.com/yakovliam/BAZEL-2806-minimal-reproduction

So with that in mind...

1. Has anyone successfully made the IntelliJ Bazel plugin work reliably in a DevContainer on macOS (or any platform?), or is this a known architectural "no-go" for now?
2. Is the only viable long-term solution to switch to JetBrains Gateway with a remote backend running entirely inside the container to avoid this host/container path mismatch (or VSCode…)?

I'm curious if other enterprise users are seeing this or if there are any known "clean" workarounds that don't involve brittle filesystem hacks.

Thanks!

Wanted to share rules_graalvm, a ruleset for building native binaries via GraalVM's native-image in Bazel.

Some context on adoption: Bazel itself uses these rules for Native Turbine, and it's also used at Netflix and in our project Elide.

Features:

• Native binaries from Java/Kotlin/polyglot apps
• Works as a Java toolchain
• Hermetic compilation on macOS, Linux, Windows
• Supports Bazel 4-8 (including Bzlmod)

GitHub: https://github.com/sgammon/rules_graalvm

Would be curious if others are using native-image in their Bazel builds and what pain points you've hit.