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.
global:
imageCredentials:
managed: truehelm 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>global:
imageCredentials:
managed: false # default
secretName: "ghcr-credentials"helm install berserk berserk/berserk \
--namespace bzrk \
-f values.yamlPostgreSQL Credentials
The meta service needs a PostgreSQL (v18+) connection string.
global:
postgresCredentials:
managed: truehelm 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"global:
postgresCredentials:
managed: false # default
secretName: "postgres-credentials"helm install berserk berserk/berserk \
--namespace bzrk \
-f values.yamlS3 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:
global:
storage:
endpoint: "https://s3.eu-central-1.amazonaws.com"
bucket: "your-berserk-bucket"
region: "eu-central-1"global:
s3Credentials:
managed: truehelm 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>global:
s3Credentials:
managed: false # default
secretName: "s3-credentials"helm install berserk berserk/berserk \
--namespace bzrk \
-f values.yamlOn 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.
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.yamlDefault 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.
global:
ingestToken:
managed: truehelm install berserk berserk/berserk \
--namespace bzrk \
-f values.yamlAn 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>"global:
ingestToken:
managed: false # default
secretName: "ingest-token"helm install berserk berserk/berserk \
--namespace bzrk \
-f values.yamlWith this you can manage the ingest token secret directly.
Full Install Example
When letting Helm manage all secrets, a single install command covers everything:
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: truehelm 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.