Skip to main content
To deploy BuildBuddy Remote Build Execution on-prem, we recommend using the BuildBuddy Enterprise Helm charts.

​
Installing the chart

First add the BuildBuddy Helm repository: 
helm repo add buildbuddy https://helm.buildbuddy.io
Then you’ll need to make sure kubectl is configured with access to your Kubernetes cluster. Here are instructions for major cloud providers:

Google Cloud

GKE cluster access setup

AWS

EKS cluster access setup

Azure

AKS cluster access setup
Finally install BuildBuddy enterprise to your Kubernetes cluster: 
helm install buildbuddy buildbuddy/buildbuddy-enterprise
This will deploy a minimal BuildBuddy enterprise install to your Kubernetes cluster. You can verify your install by waiting a minute or two for your deployment to complete, then running: 
echo `kubectl get --namespace default service buildbuddy-enterprise -o jsonpath='{.status.loadBalancer.ingress[0].*}'`
This will return an IP address that you can visit in a browser and verify that you install was successful. The basic deployment doesn’t configure RBE, so you’ll only see options for BES and Cache endpoints.

​
Configuring your install

Now that you have a basic BuildBuddy Enterprise install deployed. Let’s configure it to enable Remote Build Execution. You can do so this by passing a values.yaml file to Helm that enables RBE. Here’s a simple values.yaml file with RBE enabled. This will deploy RBE with 3 executors and Redis enabled:
values.yaml
executor:
  enabled: true
  replicas: 3
redis:
  enabled: true
config:
  remote_execution:
    enable_remote_exec: true
This configuration with 1 app instance, 3 executors, and a Redis instance will fit on a machine/cluster with at least 5 vCPUs and 24 GB of RAM.
GCP’s n2-standard-8 machines or similar are a good place to start. For information on scaling up and down your deployments, see the Configuring resource section.
You can now upgrade your install with the following command: 
helm upgrade buildbuddy buildbuddy/buildbuddy-enterprise --values values.yaml
Once your upgrade has completed (and the rollout has finished), you can reload the IP address you obtained from the kubectl command above. 
echo `kubectl get --namespace default service buildbuddy-enterprise -o jsonpath='{.status.loadBalancer.ingress[0].*}'`
You should now see a remote build execution checkbox and can try your first remote build execution. Make sure your RBE toolchains and platforms are correctly configured.

​
Configuring resources

Now that you’ve got a working RBE deployment, you can configure resources requested by BuildBuddy app instances and executors to scale up and down your cluster.
By default BuildBuddy app instances request 1 CPU and 4 GB of RAM, executors request 1 CPU and 5 GB of RAM per instance, and Redis requests 1 CPU and 5GB of RAM.
Here’s a values.yaml file that specifies the replica and resource settings you can use to scale your cluster up and down:
values.yaml
replicas: 1
resources:
  limits:
    cpu: "2"
    memory: "8Gi"
  requests:
    cpu: "1"
    memory: "4Gi"
executor:
  enabled: true
  replicas: 3
  resources:
    limits:
      cpu: "2"
      memory: "10Gi"
    requests:
      cpu: "1"
      memory: "5Gi"
redis:
  enabled: true
  resources:
    limits:
      cpu: "1"
      memory: "6Gi"
    requests:
      cpu: "1"
      memory: "5Gi"
config:
  remote_execution:
    enable_remote_exec: true
If you scale beyond one app replica, make sure you’re using MySQL instead of SQLite, and GCS/S3 instead of disk storage. For information on how to configure these, see the enterprise configuration guide. Scaling the number of executor replicas does not have these requirements.
The default values support both memory hungry Java tests and CPU-intensive Tensorflow builds. Fine tuning these parameters for peak performance depends a lot on your workload, and we’re happy to help.
For a full overview of what can be configured via our enterprise Helm charts, see:
Values for the executor deployment are nested in the executor: block of the buildbuddy-enterprise yaml file.

​
More configuration

For more configuration options beyond RBE, like authentication and storage options, see our:

​
Writing deployment to a file

If you don’t want to use Helm, you can write your Kubernetes deployment configuration to a file: 
helm template buildbuddy buildbuddy/buildbuddy-enterprise > buildbuddy-deploy.yaml
You can then check this configuration in to your source repository, or manually apply it to your cluster with: 
kubectl apply -f buildbuddy-deploy.yaml

Build docs developers (and LLMs) love

Get started for freeTalk to us