BuildBuddy is designed to be easy to run on-premise for those use cases where data absolutely must not leave a company's servers. It can be run your own servers, or in your own cloud environment. It supports major cloud providers like GCP, AWS, and Azure.
The software itself is open-source and easy to audit.
For companies, we offer an Enterprise version of BuildBuddy that contains advanced features like OIDC Auth, API access, and more.
There are four ways to run BuildBuddy on-prem:
- Bazel Run: get the source and run a simple
- Docker Image: pre-built Docker images running the latest version of BuildBuddy.
- Kubernetes: deploy BuildBuddy to your Kubernetes cluster with a one-line deploy script.
- Helm: deploy BuildBuddy to your Kubernetes cluster with the official BuildBuddy helm charts.
The simplest method of running BuildBuddy on your own computer is to download and run it with "bazel run". Doing that is simple:
- Get the source
- Navigate into the BuildBuddy directory
- Build and run using bazel
We publish a Docker image with every release that contains a pre-configured BuildBuddy.
To run it, use the following command:
Note: If you're using BuildBuddy's Docker image locally and a third party gRPC cache, you'll likely need to add the
--network=host flag to your
docker run command in order for BuildBuddy to be able to pull test logs and timing information from the external cache.
If you run or have access to a Kubernetes cluster, and you have the "kubectl" command configured, we provide a shell script that will deploy BuildBuddy to your cluster, namespaced under the "buildbuddy" namespace.
This script uses this deployment file, if you want to see the details of what is being configured.
To kick of the Kubernetes deploy, use the following command:
k8s_on_prem.sh script requires kubectl version 1.15 or higher to be installed.
To pass in a custom config file, you can use the
By default the
k8s_on_prem.sh script will use
kubectl apply to deploy BuildBuddy to your current Kubernetes cluster. If you'd like to output the Kubernetes deployment to a yaml file instead that can be checked in, you can use the
By default the
k8s_on_prem.sh script will deploy a single replica of BuildBuddy. If you've configured a MySQL database, storage, and other options necessary to support multiple replicas, you can increase the number of BuildBuddy replicas to deploy with the
By default the
k8s_on_prem.sh will restart your BuildBuddy deployment to pick up any changes in your configuration file. This can lead to brief downtime if only one replica is deployed. You can disable this behavior with the
If you've obtained a BuildBuddy enterprise license, you deploy enterprise BuildBuddy by specifying the
If you run or have access to a Kubernetes cluster and are comfortable with Helm, we maintain official BuildBuddy Helm charts that are easy to configure and deploy.
They have options to deploy everything necessary to use all of BuildBuddy's bells and whistles - including MySQL, nginx, and more.
The official BuildBuddy charts live in our buildbuddy-helm repo and can be added to helm with the following command:
You can the deploy BuildBuddy Open Source with the following command:
For more information on configuring your BuildBuddy Helm deploy, check out the charts themselves:
For documentation on all BuildBuddy configuration options, check out our configuration documentation.