Berserk Docs

Dependencies

External dependencies and deployment configurations for Berserk (and managing secrets)

Berserk requires PostgreSQL (v18+) for metadata storage and S3-compatible object storage for segment data. You also need a GitHub PAT to pull container images and optionally an ingest token to authenticate ingest requests.

For each dependency below, choose whether the Helm chart manages the Kubernetes secret (managed: true) or you provide it externally (managed: false, the default).

GitHub Container Registry (GHCR)

A GitHub Personal Access Token (PAT) is required to pull Berserk container images from GHCR.

values.yaml
global:
  imageCredentials:
    managed: true
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml \
  --set global.imageCredentials.password="<github-pat>"

Create the secret before installing:

kubectl create namespace bzrk

kubectl create secret docker-registry ghcr-credentials \
  --namespace bzrk \
  --docker-server=ghcr.io \
  --docker-username=jakobgt \
  --docker-password=<github-pat>
values.yaml
global:
  imageCredentials:
    managed: false # default
    secretName: "ghcr-credentials"
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml

PostgreSQL Credentials

The meta service needs a PostgreSQL (v18+) connection string.

values.yaml
global:
  postgresCredentials:
    managed: true
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml \
  --set global.postgresCredentials.databaseUrl="postgres://<user>:<password>@host:5432/berserk"

Create the secret before installing:

kubectl create namespace bzrk

kubectl create secret generic postgres-credentials \
  --namespace bzrk \
  --from-literal=database_url="postgres://<user>:<password>@host:5432/berserk"
values.yaml
global:
  postgresCredentials:
    managed: false # default
    secretName: "postgres-credentials"
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml

S3 Object Store

Query, ingest, janitor, and nursery services all need access to an S3-compatible object store (AWS S3, MinIO, R2, etc.).

All approaches require the storage location in your values file:

values.yaml
global:
  storage:
    endpoint: "https://s3.eu-central-1.amazonaws.com"
    bucket: "your-berserk-bucket"
    region: "eu-central-1"
values.yaml
global:
  s3Credentials:
    managed: true
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml \
  --set global.s3Credentials.accessKeyId="AKIA..." \
  --set global.s3Credentials.secretAccessKey="secret..."

Create the secret before installing:

kubectl create namespace bzrk

kubectl create secret generic s3-credentials \
  --namespace bzrk \
  --from-literal=AWS_ACCESS_KEY_ID=<key> \
  --from-literal=AWS_SECRET_ACCESS_KEY=<secret>
values.yaml
global:
  s3Credentials:
    managed: false # default
    secretName: "s3-credentials"
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml

On EKS, S3 credentials are handled automatically through IAM Roles for Service Accounts (IRSA). No S3 secret is needed — Berserk picks up access from the pod's IAM role.

IAM Role Setup — create an IAM role with S3 permissions and associate it with a Kubernetes service account. If you use Terraform:

module "irsa" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
  role_name = "berserk-s3-access"

  oidc_providers = {
    main = {
      provider_arn = module.eks.oidc_provider_arn
      namespace_service_accounts = ["bzrk:berserk"]
    }
  }
}

The IAM policy needs at minimum s3:GetObject, s3:PutObject, s3:ListBucket, and s3:DeleteObject on your data bucket.

values.yaml
global:
  s3Credentials:
    managed: false
  serviceAccountName: "berserk"

The serviceAccountName is applied to all Berserk pod specs, which lets the AWS SDK resolve credentials from the IRSA-annotated service account automatically.

helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml

Default Ingest Token

An ingest token authenticates data sent to the ingest service. By default, all requests into the ingest service are authenticated via the ingest token. If you want to allow unauthenticated requests to the ingest service, then set up a default ingest token as follows.

values.yaml
global:
  ingestToken:
    managed: true
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml

An init container on the ingest service waits for Meta to be ready, creates the token via Meta's API, and stores it in a K8s secret. On subsequent deployments the init container is skipped if the secret already exists.

Create the secret before installing:

kubectl create namespace bzrk

kubectl create secret generic ingest-token \
  --namespace bzrk \
  --from-literal=default_ingest_token="<token>"
values.yaml
global:
  ingestToken:
    managed: false # default
    secretName: "ingest-token"
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml

With this you can manage the ingest token secret directly.

Full Install Example

When letting Helm manage all secrets, a single install command covers everything:

values.yaml
global:
  storage:
    endpoint: "https://s3.eu-central-1.amazonaws.com"
    bucket: "your-berserk-bucket"
    region: "eu-central-1"
  s3Credentials:
    managed: true
  postgresCredentials:
    managed: true
  imageCredentials:
    managed: true
  ingestToken:
    managed: true
helm repo add berserk https://berserkdb.github.io/helm-charts
helm install berserk berserk/berserk \
  --namespace bzrk \
  -f values.yaml \
  --set global.s3Credentials.accessKeyId="AKIA..." \
  --set global.s3Credentials.secretAccessKey="secret..." \
  --set global.postgresCredentials.databaseUrl="postgres://user:password@host:5432/berserk" \
  --set global.imageCredentials.password="<github-pat>" \

On subsequent helm upgrade calls, you do not need to pass the credential --set flags again — the secrets already exist in the cluster and the chart will not overwrite them.

See example values for minimal, Helm-managed, and EKS configurations.

On this page