Sourcebot is a self-hosted tool that helps you understand your codebase. This repository contains the official helm chart for deploying Sourcebot onto a Kubernetes cluster.
Homepage: https://sourcebot.dev/
This chart bootstraps a Sourcebot deployment on a Kubernetes cluster using the Helm package manager.
By default, this chart deploys:
- Sourcebot application
- PostgreSQL database (via Bitnami subchart)
- Redis/Valkey cache (via Bitnami subchart)
See the minimal installation example for an example deployment.
- Create a config.json to configure repositories, language models, SSO identity providers, etc.
{
"$schema": "https://raw.githubusercontent.com/sourcebot-dev/sourcebot/main/schemas/v3/index.json",
"connections": {
"github-repos": {
"type": "github",
"repos": [
"sourcebot-dev/sourcebot"
]
}
}
}- Create a
values.yamlfile to configure the required configuration options:
sourcebot:
authSecret:
value: "CHANGEME" # generate via: openssl rand -base64 33
encryptionKey:
value: "CHANGEME" # generate via: openssl rand -base64 24
postgresql:
auth:
password: "CHANGEME"
redis:
auth:
password: "CHANGEME"They can alternatively be set via secrets (the secrets must exist):
sourcebot:
authSecret:
existingSecret: sourcebot-secrets
existingSecretKey: authSecret
encryptionKey:
existingSecret: sourcebot-secrets
existingSecretKey: encryptionKey
postgresql:
auth:
existingSecret: sourcebot-secrets
secretKeys:
userPasswordKey: postgresql-password
adminPasswordKey: postgresql-password
redis:
auth:
existingSecret: sourcebot-secrets
existingSecretPasswordKey: redis-password- Install & deploy the chart:
helm repo add sourcebot https://sourcebot-dev.github.io/sourcebot-helm-chart
helm repo update
helm install sourcebot sourcebot/sourcebot \
-f values.yaml \
--set-json "sourcebot.config=$(cat config.json)"helm repo update
helm upgrade sourcebot sourcebot/sourcebot \
-f values.yaml \
--set-json "sourcebot.config=$(cat config.json)"By default, the chart will run with the minimum resources to provide a stable experience. For production environments, we recommend to adjust the following parameters in the values.yaml.
sourcebot:
resources:
requests:
cpu: "2"
memory: 4Gi
limits:
cpu: "2"
memory: 4Gi
postgresql:
primary:
resources:
requests:
cpu: "2"
memory: 4Gi
limits:
cpu: "2"
memory: 4Gi
redis:
primary:
resources:
requests:
cpu: "1"
memory: "1.5Gi"
limits:
cpu: "1"
memory: "1.5Gi"Sourcebot is configured via a JSON config file as well as environment variables.
For the config file, it is recommended to create a separate config.json and use --set-json on the helm install command:
{
"$schema": "https://raw.githubusercontent.com/sourcebot-dev/sourcebot/main/schemas/v3/index.json",
"connections": {
"github-repos": {
"type": "github",
"repos": [
"sourcebot-dev/sourcebot"
]
}
}
}helm install sourcebot sourcebot/sourcebot \
-f values.yaml \
--set-json "sourcebot.config=$(cat config.json)"Alternatively, you can define the config directly in a values.yaml file:
sourcebot:
config:
$schema: https://raw.githubusercontent.com/sourcebot-dev/sourcebot/main/schemas/v3/index.json
connections:
github-repos:
type: github
repos:
- sourcebot-dev/sourcebotEnvironment variables are used to pass secrets to the config.json as well as to configure other options. See the environment variables docs for a full list of supported variables.
For sensitive values, use additionalEnvSecrets to reference keys in an existing Kubernetes Secret:
sourcebot:
additionalEnvSecrets:
- envName: GITHUB_TOKEN
secretName: sourcebot-secrets
secretKey: github-token
- envName: ANTHROPIC_API_KEY
secretName: sourcebot-secrets
secretKey: anthropic-api-keyFor non-sensitive values, use additionalEnv:
sourcebot:
additionalEnv:
- name: SOURCEBOT_LOG_LEVEL
value: "debug"You can also mount entire Secrets or ConfigMaps using envFrom:
sourcebot:
envFrom:
- secretRef:
name: my-env-secretsTo enable Enterprise Edition features, set your license key directly:
sourcebot:
license:
value: "your-license-key"Or via an existing secret:
sourcebot:
license:
existingSecret: sourcebot-secrets
existingSecretKey: license-keyBy default, the chart uses a RollingUpdate strategy, which creates the new pod before terminating the old one during upgrades. You can customize the rolling update behavior:
sourcebot:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1On multi-node clusters with ReadWriteOnce persistent volumes, the new pod may fail to start if it gets scheduled on a different node than the old pod. To avoid this, you can pin pods to the same node using pod affinity:
sourcebot:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/name: sourcebot
topologyKey: kubernetes.io/hostnameAlternatively, you can use the Recreate strategy, which terminates the old pod before creating the new one. This avoids PVC conflicts but causes brief downtime during upgrades:
sourcebot:
strategy:
type: RecreateEach component has its own persistent volume for storing data across pod restarts.
Stores cloned repositories and search indexes. Enabled by default with a 10Gi volume.
sourcebot:
persistence:
enabled: true # Default
size: 10Gi # Increase for large or many repositories
storageClass: "" # Uses cluster default
accessModes:
- ReadWriteOnceTo use an existing persistent volume claim (PVC):
sourcebot:
persistence:
existingClaim: my-existing-pvcManaged by the Bitnami PostgreSQL subchart. Enabled by default with an 8Gi volume.
postgresql:
primary:
persistence:
enabled: true
size: 8Gi
storageClass: ""Managed by the Bitnami Valkey subchart. Enabled by default with an 8Gi volume.
redis:
primary:
persistence:
enabled: true
size: 8Gi
storageClass: ""postgresql:
deploy: false
host: your-postgres-host.example.com
port: 5432
auth:
username: sourcebot
database: sourcebot
existingSecret: sourcebot
secretKeys:
userPasswordKey: passwordredis:
deploy: false
host: your-redis-host.example.com
port: 6379
auth:
username: default
existingSecret: sourcebot
existingSecretPasswordKey: redis-passwordEnable ingress to expose Sourcebot:
sourcebot:
ingress:
enabled: true
className: nginx
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
hosts:
- host: sourcebot.example.com
paths:
- path: /
pathType: Prefix
tls:
- hosts:
- sourcebot.example.com
secretName: sourcebot-tlsUse a ReadWriteMany access mode so the old and new pods can mount the PVC simultaneously during rolling updates. This requires a storage class that supports ReadWriteMany (e.g., EFS on AWS, Filestore on GCP, Azure Files):
sourcebot:
persistence:
accessModes:
- ReadWriteMany
storageClass: "efs-sc" # example: AWS EFS storage classAlternatively, you can keep ReadWriteOnce and use pod affinity to pin pods to the same node:
sourcebot:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/name: sourcebot
topologyKey: kubernetes.io/hostnamesourcebot:
persistence:
existingClaim: my-existing-pvcTo uninstall/delete the sourcebot deployment:
helm uninstall sourcebotThis removes all Kubernetes components associated with the chart but preserves PersistentVolumeClaims (PVCs) by default. This includes:
sourcebot-data- Sourcebot repository data and search indexesdata-sourcebot-postgresql-0- PostgreSQL data (if deployed)valkey-data-sourcebot-redis-*- Redis data (if deployed)
To also remove all PVCs (
kubectl delete pvc -l app.kubernetes.io/instance=sourcebot