Bazel Buildfarm Remote Cache and Execution Farm

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Bazel Buildfarm - Remote Build Cache and Remote Execution

Bazel Buildfarm is an open source remote build cache and remote execution service that implements Bazel's Remote Execution API. Point your Bazel builds at it and actions are cached and executed on the farm instead of on every developer laptop and CI runner, so a shared cache and offloaded compilation make builds dramatically faster and CI cheaper. This image delivers a complete single-node farm, fully installed and hardened, so a working Remote Execution endpoint is running within minutes of launch with no manual setup.

## What Is Included

• Three managed services on one node: a Redis SHARD backplane bound to the loopback interface, a Buildfarm server exposing the Remote Execution API on gRPC port 8980 (the endpoint your clients dial), and a Buildfarm worker that executes actions.
• Sharded architecture ready out of the box: the Redis backplane is included and configured for you.
• Dedicated EBS data volume: the content-addressable cache store lives on an independently resizable volume kept off the OS disk.
• Immediate offload: point Bazel at the farm with --remote_executor and --remote_cache and your builds offload immediately.

## Secure by Default

Unlike a bare deployment, this image is secure by default. A unique Redis backplane secret is generated on each instance's first boot and written to a root-only file, and a fail-secure bootstrap gate ensures the server and worker cannot start until that per-instance secret exists, so the farm never comes up with a build-time or default secret.

The Remote Execution endpoint runs build actions your clients submit, so it is a privileged compute plane. The image ships with only SSH open in its security group; you scope an inbound rule for the Remote Execution port to your own build fleet, keeping the endpoint private to the clients that should reach it. The internal worker port and the Redis backplane are additionally kept off the public network by a firewall guard.

## Use Cases

• Shared cache for engineering teams (10-50+ developers): give a team working on a large C++ or Java monorepo a shared remote build cache so no one recompiles what a colleague already built, alongside CI systems such as GitHub Actions or Jenkins.
• CI acceleration: offload CI compilation onto the farm to cut CI wall-clock time and runner cost, reducing redundant compilation across parallel jobs.
• Self-hosted Remote Execution on your own infrastructure: run a Remote Execution endpoint inside your own VPC, keeping source code and build artifacts within your network boundary - suitable for teams with data residency or compliance requirements.

## Getting Started

1. Launch the AMI on your chosen EC2 instance type.

2. Verify the three services (Redis, Buildfarm server, Buildfarm worker) are running.

3. Add a security group inbound rule for TCP port 8980 scoped to your build fleet CIDR.

4. Configure your Bazel clients with --remote_executor=grpc://INSTANCE_IP:8980 and --remote_cache=grpc://INSTANCE_IP:8980.

5. Run a build - actions execute remotely on the worker and results are cached for subsequent runs.

Every build is verified end to end: a real Bazel build is executed remotely on the worker and re-served from cache on a second run, so you get a farm that genuinely executes and caches actions.

## 24/7 cloudimg Support

Technical support by email and live chat covers deployment, endpoint sizing, network scoping of the Remote Execution port, connecting your Bazel clients, cache and worker administration, and performance tuning.

Bazel and Bazel Buildfarm are trademarks of their respective owners. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.