Kubernetes (Helm)

Install Busabase Premium with Helm — what the chart does, the two values that break attachments and sign-in when they are wrong, and when to bring your own Postgres and S3.

The chart lives in the public busabase/busabase-premium repo, under helm/. It is the Compose deployment expressed in Kubernetes objects, so everything in Production with Compose still applies.

Install

git clone https://github.com/busabase/busabase-premium.git
helm install busabase ./busabase-premium/helm \
  --namespace busabase --create-namespace \
  --set image.tag=0.10.0 \
  --set appUrl=https://busabase.company.internal

Both values are required, and the chart refuses to render without them rather than installing something that half-works:

image.tag — pinned deliberately. A chart that tracks a moving tag upgrades the instance whenever a pod restarts, which is not a property you want on a server holding your data.
appUrl — the address users type. Sign-in cookies are issued against it, so a mismatch produces a sign-in that appears to succeed and then bounces straight back to the login page, with nothing in the logs.

What it creates

Object	Purpose
`Deployment`	The app
`Job` (Helm hook)	Migrations, run once per release before the app rolls
`StatefulSet` ×2	Bundled Postgres and object storage (omitted in external mode)
`Service` ×3	App, Postgres, storage
`Secret`	Generated credentials, preserved across upgrades

Migrations run as a hook, not an init container

The Job is a pre-install,pre-upgrade hook, which matters for two reasons:

It runs once per release, not once per replica. An init container would have every replica race to migrate the same database; the loser fails in a way that reads as a corrupt schema rather than a lock conflict.
A failed migration fails the release. helm upgrade stops, and the existing pods keep serving the old code against the old schema — instead of new pods coming up against a half-migrated one.

The failed Job is kept so you can read its logs. The error names the failing SQL statement but not the file it came from; grep the migrations directory for that statement to find it.

Object storage has to be reachable by the browser

Uploads are presigned PUTs and downloads are redirects, so the browser fetches object storage directly — exactly as it does against S3 on Busabase Cloud. The address must resolve for the browser. A cluster-internal Service name does not, and the symptom is specific and misleading: the app works, sign-in works, and every attachment upload fails.

By default the chart derives the storage host from appUrl, which is usually right. Set storage.publicHost when storage answers on a different hostname, and expose both hosts through your Ingress.

Bring your own Postgres and S3

The bundled ones exist so helm install produces something that works. Neither is a production answer: the bundled Postgres is a single pod with no failover, no point-in-time recovery, and backups that are yours to arrange.

helm install busabase ./busabase-premium/helm \
  --set image.tag=0.10.0 \
  --set appUrl=https://busabase.company.internal \
  --set postgres.mode=external \
  --set postgres.external.host=pg.company.internal \
  --set storage.mode=external \
  --set storage.publicHost=s3.company.internal

In external mode the chart creates neither StatefulSet.

Secrets

The Postgres password, object-storage key and session signing key are generated on first install and preserved on upgrade — the chart reads back the existing Secret rather than minting new ones. That is not a detail: a new session key signs every user out, and a new Postgres password locks the app out of its own database.

Set secrets.existingSecret to manage them yourself; the chart then creates none.

Activating

Identical to every other deployment shape: System Admin → Licence, paste, save. Verification is local and needs no network. See Licensing.