Buildfarm
Buildfarm is an open-source stack that implements the Remote Execution API for remote content storage, action-result caching, and asynchronous action executi…
What Buildfarm is
Buildfarm is an open-source stack that implements the Remote Execution API for remote content storage, action-result caching, and asynchronous action execution. It is compatible with Bazel, Buck2, Pants, and other build systems that support the API. Its Content Addressable Storage can retain content, and it can cache ActionResults for reuse.
Workers can execute actions, serve as CAS shards, or take on both roles; each worker needs local filesystem storage. Documented storage options include in-memory, external gRPC, HTTP/1 proxy, persistent worker disk, and sharded CAS. Additional capabilities include configurable instances, progressive and flow-controlled CAS reads and writes, pluggable external CAS endpoints, and RequestMetadata attribution. Buildfarm requires a backplane to share information among cluster members, and its quick start uses Redis. Setup documentation covers Linux and container-based startup, with server and worker deployments spread across machines. Authentication can be configured with self-signed TLS certificates. Execution can be configured to require sandboxing; FuseCAS remains experimental and may be unreliable under substantial load.
Good
- Supports Bazel, Buck2, Pants, and API-compatible systems.
- Offers remote caching and asynchronous action execution.
- Workers can execute actions, shard CAS, or do both.
- Supports sandboxing and Linux cgroup resource limits.
- Server and worker deployments can span machines.
Watch out
- Requires a backplane, with Redis used in the quick start.
- Workers require local filesystem storage.
- FuseCAS is experimental and may be unreliable under substantial load.
- Linux cgroups require OS-specific support.
Who it suits
Buildfarm suits teams using Bazel, Buck2, Pants, or another Remote Execution API-compatible build system that need remote caching or execution. It is aimed at deployments with server and worker infrastructure they can operate.
Verdict
Buildfarm provides remote execution and caching with flexible worker roles and storage choices. It requires a backplane and infrastructure setup, and its experimental FuseCAS option carries a reliability caveat.
The facts
Each one read from Buildfarm's own pages, with the date it was checked.
What it does
- Architecture
- Workers can perform execution and CAS shard roles, and either role can be disabled in configuration.checked 5 Oct 2026
- Build system compatibility
- The project says it is compatible with Bazel, Buck2, Pants, and other build systems that support the API.checked 5 Oct 2026
- Build systems
- The project says it is compatible with Bazel, buck2, Pants, and other build systems that use the Remote Execution API.checked 5 Oct 2026
- Caching and execution
- A Buildfarm cluster can provide Action Cache and Content Addressable Storage for remote caching, and workers can execute build actions remotely.checked 5 Oct 2026
- CAS features
- Documented features include configurable instances, progressive and flow controlled CAS reads and writes, pluggable external CAS endpoints, and RequestMetadata attribution.checked 5 Oct 2026
- CAS options
- Buildfarm documents in-memory storage, an external CAS proxy, an HTTP/1 proxy, and persistent worker disk storage as CAS implementations.checked 5 Oct 2026
- Deployment
- The project documents running Buildfarm server and worker processes, using containers for a minimal cluster, and installing an OCI bundled Helm chart.checked 5 Oct 2026
- Deployment scale
- The quick start says deployments can spread servers and workers across machines and describes use by hundreds or thousands of developers or CI processes.checked 5 Oct 2026
- Execution controls
- Execution policies can modify or control worker actions, including wrapper policies such as running actions through the Linux sandbox or as the nobody user.checked 5 Oct 2026
- Experimental limitation
- The worker documentation says FuseCAS is experimental and may not work reliably over long periods or under substantial load.checked 5 Oct 2026
- Feature support
- The project lists configurable instances, progressive and flow-controlled CAS reads and writes, pluggable external CAS endpoints, and RequestMetadata behavior attribution among its supported features.checked 5 Oct 2026
- License
- The project repository identifies its license as Apache-2.0.checked 5 Oct 2026
- Metrics
- The quick start documents a Prometheus metrics endpoint configurable for the server and worker.checked 5 Oct 2026
- Notable limitation
- The worker documentation says the Fuse execution filesystem is experimental and may be unreliable under substantial load.checked 5 Oct 2026
- Product
- Buildfarm is a software stack implementing the Remote Execution API for remote content storage, action-result caching, and asynchronous action execution.checked 5 Oct 2026
- Purpose
- Buildfarm implements the Remote Execution API for remote caching and execution.checked 5 Oct 2026
- Resource limits
- Workers can use Linux cgroups to limit execution resources, and the documentation says this feature requires OS-specific cgroups support available in Linux.checked 5 Oct 2026
- Sandboxing
- Configuration can require actions to use a sandbox, and supports settings for cgroups and an as-nobody wrapper.checked 5 Oct 2026
- Scale
- The quick start says deployments can spread services across machines and may serve hundreds or thousands of developers or CI processes.checked 5 Oct 2026
- Security
- The authentication guide describes configuring client/server authentication with self-signed TLS certificates.checked 5 Oct 2026
- Setup
- The quick start demonstrates running the service on Linux and provides a container-based startup option.checked 5 Oct 2026
- Storage options
- Buildfarm documents in-memory, external gRPC, HTTP/1 proxy, persistent worker disk, and sharded CAS implementations.checked 5 Oct 2026
Money
- Backplane dependency
- Buildfarm requires a backplane for information shared between cluster members, and its quick start uses Redis for that role.checked 5 Oct 2026
- Backplane requirement
- Buildfarm requires a backplane for information shared between cluster members, and the quick start uses Redis.checked 5 Oct 2026
