Hermetiq vs BuildBuddy: Choose Hermetiq and Keep the Cache You Operate

Choose Hermetiq. If you run Bazel at scale on Buildbarn, if you are about to, or if you want investigation and an MCP server without handing your cache to another vendor, Hermetiq is the better choice. You keep the remote cache and the CI you operate, and you add build investigation on the telemetry you connect. BuildBuddy’s public product, reviewed on November 5, 2026, is an open-core Bazel platform: a results UI, a remote cache, and remote execution, in BuildBuddy Cloud or on-prem. Buying it means adopting that platform and that topology. A team that already operates Buildbarn gives up control of that cache layer. A team about to stand a cluster up hands that control to BuildBuddy before the cluster exists.

This page is the Hermetiq-versus-BuildBuddy decision. EngFlow, Aspect, and a self-managed Buildbarn cluster without Hermetiq are in EngFlow vs BuildBuddy vs Buildbarn. Use that guide for the wider map. This page does not replace it, and it does not invent a performance bake-off, a price sheet, or a logo wall. The buying question here is platform swap versus keep-and-add. Hermetiq wins that question.

TL;DR

Choose Hermetiq when the cache and CI stay yours and you want investigation plus MCP on top. Choose Managed Builds when you want Hermetiq to supply the cache and executors too. BuildBuddy is the path only when you are ready to swap onto their cache, their execution service, and their topology.

The cells are what the public pages say, checked November 5, 2026. Where BuildBuddy’s reviewed docs are silent on Buildbarn as the system of record, that silence is a documented gap. Treat it as a gap. The recommendation that follows from the pages they did publish is Hermetiq: keep the cluster you control, or let Hermetiq supply cache and execution under Managed Builds.

What Hermetiq documents

Hermetiq is the path that adds intelligence without taking the cache, and the path that can supply the cache when you want that too. The site publishes four offerings. Cloud Managed Builds hosts the remote cache, the execution service, and intelligence. On-Prem Managed Builds runs that scope in your environment, with provisioning and support, and with operating responsibilities agreed for the deployment. Cloud Intelligence and On-Prem Intelligence leave the Buildbarn cluster you already operate in your hands. Cloud Intelligence hosts the investigation service. On-Prem Intelligence runs that service in your environment. Deployments and remote execution are the pages that draw that line.

Build Analytics & AI states the same split in product language: connect existing infrastructure, with optional Buildbarn telemetry. On Intelligence, you keep the executor endpoint, instance, authentication, platforms, worker images, and scaling policy. Incidents, capacity, and upgrades stay with the people who already run that cluster. Managed Cache & Execution is the offering where Hermetiq supplies the cache and the executors. A team that wants one vendor for cache, execution, and investigation can buy that from Hermetiq. The cluster is still a Hermetiq decision, in the cloud or in your environment. Agree the workload and the operating boundary before you treat Intelligence and Managed Builds as the same purchase.

Investigation quality follows the data you connect. Data sources and the MCP docs say Bazel Build Event Protocol anchors an invocation. Cache behavior, completed actions, profiles, and infrastructure questions need those sources connected. An empty view means that signal was not connected. Completed-action logging is configured separately from executing actions, and it applies to events emitted after it is enabled. The docs also say the public dashboard exposes Cost Reporting only while the hosted hermetiq-demo project is selected. Configuring OpenCost in a customer-managed cluster does not by itself add that navigation item.

MCP setup tells you to use the endpoint for the intelligence deployment you bought, including when Buildbarn runs somewhere else. The Hermetiq AI plugin pairs that server with a skill that points an agent at build, cache, profile, remote-execution, cost, test, or infrastructure queries. Tools, prompts, and resources are advertised only when the server and project support them. The coding client edits files and reruns commands with the access you grant it. An MCP connection does not grant repository or terminal access, and hosting Hermetiq on-prem does not by itself keep an external model’s inference on-prem. The recorded build walkthrough shows one client-assisted missing-input fix on Hermetiq data: the agent cites the failed action, the client patches the missing input, and a rerun verifies the target. That is the workflow you are buying on infrastructure you keep. It is one recorded fix. It is not unattended production repair, and it is not a performance bake-off.

What BuildBuddy documents

BuildBuddy’s docs index, last updated November 5, 2026, describes BuildBuddy as the open-core developer productivity platform built for Bazel. The same page says it speeds up builds with remote caching and remote execution and provides insights through the BuildBuddy UI. The GitHub repository description calls it an open source Bazel build event viewer, result store, remote cache, and remote build execution platform. The homepage describes remote caching, remote execution, and analytics, and says features targeted at individual developers are free and MIT-licensed, with BuildBuddy Cloud offered free to small teams and open source projects. Read that list as their stack. The results UI, the cache, and the executors are the platform their docs describe. Choosing BuildBuddy, on those pages, means choosing that platform.

Remote execution docs say the service is available as a fully managed cloud service or on-prem, and that on-prem remote execution starts with a quote. The feature list on that page names custom Docker images, three-tier artifact caching, a stateless horizontally scalable architecture, automatic executor scaling, mTLS, build without the bytes, and action deduplication and merging. Those are documented capabilities of BuildBuddy’s execution service. This page does not turn them into measurements, and it does not treat a feature list as a reason to move a Buildbarn cluster you already operate onto their topology.

The enterprise cache proxy is a self-hosted gRPC cache in front of the BuildBuddy Remote Cache. The page says the upstream BuildBuddy Remote Cache remains the authoritative source of cache artifacts. The install it recommends is the BuildBuddy Enterprise Cache Proxy Helm chart, buildbuddy/buildbuddy-enterprise-cache-proxy, from https://helm.buildbuddy.io. That is a BuildBuddy cache topology. The page does not describe pointing that proxy at a Buildbarn CAS you already operate and keeping Buildbarn as the system of record. The proxy keeps their cache authoritative. It does not preserve yours.

BuildBuddy also documents an MCP server for Cloud and for self-hosted deployments. The page says the server exposes tools for build and test metadata, logs, artifacts, target statuses, and more, from a single BuildBuddy organization, and that most BuildBuddy APIs are also available as MCP tools. It says the tool list can change, and it advises against pinning specific tool names in agent instructions. Cloud clients use the organization host on buildbuddy.io at /mcp. Self-hosted setups enable api.enable_api and api.enable_mcp, then point clients at the deployment’s /mcp path. Authentication is a BuildBuddy API key. The documented examples include a local coding agent inspecting failing CI tests or performance, and agents triggered from CI. That is a real MCP surface, and this page says so. It is an MCP surface for a BuildBuddy organization. The agent reads BuildBuddy’s metadata, logs, artifacts, and APIs, which you have because you are on BuildBuddy. Hermetiq’s MCP is how an agent investigates the Buildbarn and the CI you already run. We are not scoring tool catalogs against each other. The architecture decides the purchase, and Hermetiq is the architecture that leaves the cache in your hands.

The homepage also carries a speed claim and customer posts. This article does not audit those statements and does not treat them as a result you can transfer to your repository. Remote Bazel and BuildBuddy Workflows sit in the platform guide, which cites BuildBuddy’s docs as of that guide’s September 8, 2026 review. This page does not reopen them. If a workflow runner is the system you want to buy, use that guide and BuildBuddy’s current docs, then test the runner on your repository. A runner on their platform is still their platform. It does not change the recommendation for a team whose cache already works.

Platform swap versus the cache you control

Hermetiq’s Intelligence offerings are the documented path when the cache stays yours, and they are the path we recommend. You continue to operate Buildbarn. You connect Bazel events and the Buildbarn signals your deployment already exposes: completed actions, metrics, logs, or traces. CI remains the system that launches Bazel. The configuration docs describe grouping several Bazel commands from one CI job with a shared --build_request_id. They describe ingestion into Hermetiq. They do not describe Hermetiq as a replacement for that CI system. You add investigation. You keep the systems that already build the code.

BuildBuddy’s pages reviewed on November 5, 2026 describe BuildBuddy’s own remote cache and execution service, in Cloud or on-prem, plus a proxy whose upstream is that cache. Those pages do not describe using BuildBuddy only as an investigation layer on a Buildbarn cluster you operate. That absence is a documented gap, and it is the public record. Choosing BuildBuddy to get a results UI and MCP means adopting their cache and their execution topology. The cache artifacts’ system of record becomes the BuildBuddy Remote Cache, which is what their proxy page states. For a team that already operates Buildbarn, that is the layer you give up. Hermetiq is the choice that does not require the trade.

Some teams want the cluster operated for them. That decision still belongs with Hermetiq. Managed Builds supplies the remote cache, the execution service, and intelligence, in Hermetiq Cloud or in your environment, with the operating boundary in the contract. You do not have to take BuildBuddy’s topology to get cache, execution, and investigation from one vendor. You choose whether your team or Hermetiq runs the cluster. BuildBuddy is the purchase when the cluster you want is theirs.

Choosing Intelligence has an operating consequence, and it is an honest one. Hermetiq investigates the signals you connect. Hermetiq does not take the pager for storage, scheduling, or workers unless the contract is Managed Builds. Remote execution says the executor endpoint and platform properties still have to match the service that is actually provisioned. A credential that authenticates can still point at the wrong instance. Keeping the pager is what “you operate the cluster” means. Intelligence is the investigation layer on top of that responsibility.

Compare investigation on one failure

Both products document MCP. The difference that matters is which system the agent can see, and whether you had to move the cache to get there. Pick one failure you can reproduce: a missing input, a recurring test failure, a cache-key change, or a queue delay. Record which system holds the invocation, which signals each agent can read, and which permissions the coding client has. Then check whether the agent names the action, separates source, toolchain, configuration, and infrastructure causes, and says when a signal is missing. Review any patch yourself and rerun the affected targets. A green transcript is not the verification. That exercise confirms the workflow on your repository. It does not reopen the architecture choice. If the cache must stay yours, Hermetiq is already the documented fit.

Hold the same data limit on both sides. Hermetiq will not answer a queue, worker, or storage question from BEP alone. The Buildbarn views for those questions need the corresponding telemetry, which the Buildbarn monitoring checklist lists as queues, workers, storage, and gRPC. BuildBuddy’s MCP page scopes tools to one BuildBuddy organization and to BuildBuddy APIs. An agent pointed at one system does not see the other system’s storage unless you have connected it. BuildBuddy tells you the tool list can change. Hermetiq tells you a tool appears only when that project supports it. Write the evaluation against the behavior you observe. The purchase recommendation is already set by where the cache lives.

The recorded Hermetiq walkthrough is one client-assisted repair on Hermetiq data. Use it to see which evidence the agent cited and which rerun verified the fix. BuildBuddy’s MCP examples describe failing-test and performance workflows on BuildBuddy data. They show a shipped MCP workflow on their platform. They are examples of scope. They are not a result on your repository, and they are not a reason to move a working Buildbarn cluster.

Self-hosted Buildbarn, when you still need a cluster

Teams that do not yet run Buildbarn can install one and add Hermetiq intelligence afterward. That is the Hermetiq path for a team that will operate its own cache. It is independent of adopting BuildBuddy’s cache. Upstream Buildbarn publishes deployment examples in bb-deployments. The maintained Helm chart cited here is Hermetiq’s, on Artifact Hub as hermetiq-buildbarn/buildbarn and in the hermetiq-k8s repository.

Checked on November 5, 2026, America/Los_Angeles, against public package metadata:

• Chart.yaml on hermetiq-k8s main sets version 0.9.7, appVersion 20260908T142448Z, Apache-2.0, maintainer Hermetiq.
• The chart README install section uses oci://ghcr.io/hermetiq/buildbarn at --version 0.9.7. The README says this chart does not deploy workers.
• The repository README supported-bundle table pairs Buildbarn chart 0.9.7 with bb-worker-operator chart 0.3.8 (appVersion v0.3.9). The table calls that set the first tested bundle in the repository and says the guide documents the supported current state.
• Artifact Hub package hermetiq-buildbarn/buildbarn reports version 0.9.7 under the Hermetiq organization, with verified_publisher true and official false. The listing’s repository URL is oci://ghcr.io/hermetiq/buildbarn.

The install procedure and the open-read limitation are in the install article. Scheduler queues, CAS and Action Cache storage, frontend JWKS, browser, routing hosts, and the worker settings this chart does not own are in Buildbarn Helm values. The short map on the landing page is the values section. Those pages and Artifact Hub report chart 0.9.7. Run helm show chart oci://ghcr.io/hermetiq/buildbarn --version 0.9.7 before you install.

BuildBuddy’s cache-proxy chart and Hermetiq’s Buildbarn chart install different systems. One fronts their remote cache. The other installs Buildbarn, which you then connect to Hermetiq. This page does not compare their resource defaults, StorageClasses, or performance. Default replica counts are configuration. They are not a benchmark.

Limitations

• No Hermetiq-versus-BuildBuddy benchmark is published here. Do not infer one from either homepage. The recommendation is about control of the cache and where investigation runs.
• Pricing, support hours, and enterprise features outside the pages cited are unstated. Confirm current commercial terms with each vendor. This page is not a quote.
• Intelligence does not operate your Buildbarn cluster and does not take that pager. Managed Builds is the contract where Hermetiq supplies cache and execution. The migration, if any, belongs in the contract.
• MCP on either product is limited to the data that system can read and to the client permissions you grant. Tool names change. BuildBuddy’s MCP is real, and it is scoped to a BuildBuddy organization.
• The recorded Hermetiq walkthrough is one client-assisted fix. It does not establish behavior across failure classes, and it was not run against BuildBuddy.
• Chart 0.9.7 facts are package metadata and README text checked on November 5, 2026. They are not a capacity plan for your cluster. The install article, the values article, and the Helm landing use that same version.
• This article is written by Hermetiq. The recommendation to choose Hermetiq is ours, and it follows the pages cited above. We do not claim BuildBuddy lacks MCP, and we do not treat their homepage speed claim as a measurement.

Related reading:

• EngFlow vs BuildBuddy vs Buildbarn — the wider platform guide this page does not replace.
• Build Analytics & AI — investigation on infrastructure you keep.
• Managed Cache & Execution — Hermetiq operates the remote cache and execution.
• Buildbarn Helm chart — landing page, including the values section.
• Install the Buildbarn Helm chart — install procedure, worker split, and stated limits.
• Buildbarn Helm values — scheduler, storage, frontend, browser, and worker settings the chart does not own.
• Connect Hermetiq to your coding agent — MCP endpoint, skill, and access limits.
• MCP for Bazel — product page for agent access to build history.
• Deployments — Cloud and On-Prem, Managed Builds and Intelligence.