Skip to content

sourcebot-dev/sourcebot-helm-chart

Repository files navigation

Sourcebot Helm Chart

Artifact Hub

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/

Introduction

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.

Installation

  1. 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"
            ]
        }
    }
}
  1. Create a values.yaml file 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: password
      adminPasswordKey: postgres-password

redis:
  auth:
    existingSecret: sourcebot-secrets
    existingSecretPasswordKey: redis-password
  1. 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)"

Upgrading

helm repo update
helm upgrade sourcebot sourcebot/sourcebot \
  -f values.yaml \
  --set-json "sourcebot.config=$(cat config.json)"

Sizing

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"

App configuration

Sourcebot is configured via a JSON config file as well as environment variables.

config.json

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/sourcebot

Environment variables

Environment 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-key

For 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-secrets

License Key

To 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-key

Deployment Strategy

By 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: 1

On 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/hostname

Alternatively, 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: Recreate

Persistence

Each component has its own persistent volume for storing data across pod restarts.

Sourcebot

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:
      - ReadWriteOnce

To use an existing persistent volume claim (PVC):

sourcebot:
  persistence:
    existingClaim: my-existing-pvc

PostgreSQL

Managed by the Bitnami PostgreSQL subchart. Enabled by default with an 8Gi volume.

postgresql:
  primary:
    persistence:
      enabled: true
      size: 8Gi
      storageClass: ""

Redis

Managed by the Bitnami Valkey subchart. Enabled by default with an 8Gi volume.

redis:
  primary:
    persistence:
      enabled: true
      size: 8Gi
      storageClass: ""

Examples

Using an external Postgres server

postgresql:
  deploy: false
  host: your-postgres-host.example.com
  port: 5432
  auth:
    username: sourcebot
    database: sourcebot
    existingSecret: sourcebot
    secretKeys:
      userPasswordKey: password

Using an external Redis server

redis:
  deploy: false
  host: your-redis-host.example.com
  port: 6379
  auth:
    username: default
    existingSecret: sourcebot
    existingSecretPasswordKey: redis-password

Configuring an ingress

Enable 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-tls

Zero-downtime upgrades on multi-node clusters

Use 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 class

Alternatively, 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/hostname

Using an existing PVC

sourcebot:
  persistence:
    existingClaim: my-existing-pvc

Uninstalling

To uninstall/delete the sourcebot deployment:

helm uninstall sourcebot

This removes all Kubernetes components associated with the chart but preserves PersistentVolumeClaims (PVCs) by default. This includes:

  • sourcebot-data - Sourcebot repository data and search indexes
  • data-sourcebot-postgresql-0 - PostgreSQL data (if deployed)
  • valkey-data-sourcebot-redis-* - Redis data (if deployed)

To also remove all PVCs (⚠️ this will delete all your data):

kubectl delete pvc -l app.kubernetes.io/instance=sourcebot

About

Kubernetes config and Helm chart for Sourcebot

Resources

License

Contributing

Stars

Watchers

Forks

Packages

 
 
 

Contributors