Skip to main content

Install on Kubernetes

The official Helm chart installs the web app with integrated administration, PostgreSQL database, artifact server, runner, browser host, and migration job. It is available at oci://testvibe.azurecr.io/charts/testvibe and in the release bundle under kubernetes/testvibe/.

Use a Helm 3 client with OCI support, a cluster you can administer, and storage that can provision the chart's persistent volumes. Runner and browser pods must reach the application under test. A model provider is needed for generation; an instance license is required after the grace period.

Registry access and namespace​

Helm's chart login and Kubernetes' image pull secret are separate. Both use the registry credentials issued to you.

helm registry login testvibe.azurecr.io
kubectl create namespace testvibe
kubectl -n testvibe create secret docker-registry testvibe-registry \
  --docker-server=testvibe.azurecr.io \
  --docker-username=<token-name> --docker-password=<token-password>

If the namespace already exists, reuse it. Keep credentials out of shared shell history and scripts. A release and its pull secret must be in the same namespace; use -n testvibe on install and upgrade.

Values and installation​

Create a private values.yaml with strong, unique values. The placeholders below must be replaced.

global:
  imagePullSecrets:
    - name: testvibe-registry
secrets:
  pgPassword: "<database-password>"
  blobSigningKey: "<artifact-signing-key>"
  blobAdminKey: "<artifact-admin-key>"
  runnerKey: "<runner-key>"

All four secrets are required. Administration uses your normal application account; no separate admin password or bootstrap token is needed.

Alternatively, set secrets.existingSecret to a Secret you manage and populate the exact keys documented in the chart. This bypasses values validation; it does not make the underlying credentials optional.

helm install testvibe oci://testvibe.azurecr.io/charts/testvibe \
  --version <version> -n testvibe -f values.yaml

A new installation should leave secrets.protectionKey unset: the app creates its encryption key in PostgreSQL. If an existing installation has an explicit protection key, preserve it exactly in every upgrade. Chart 0.4.6 incorrectly required this value; that chart defect was fixed in 0.4.7.

Verify and create the first user​

kubectl -n testvibe get pods
kubectl -n testvibe get jobs
kubectl -n testvibe rollout status deploy/testvibe-web

The migration job applies PostgreSQL scripts; the app waits for the current schema before serving. Investigate failed jobs or ImagePullBackOff before continuing.

For local access, forward the web service:

kubectl -n testvibe port-forward svc/testvibe-web 3000:80

Open http://localhost:3000 and choose Create an account. The first account becomes the instance administrator without email delivery. Continue in Settings → Administration. Existing installations use host recovery to appoint an administrator; workspace owners are not promoted automatically.

Public URLs and storage​

Enable ingress.enabled and set ingress.host for browser access. Configure TLS for your environment. The chart can route artifacts under /artifacts or a separate artifact host. Both the application URL and artifact URL must be reachable by users' browsers; an internal Kubernetes service name is not sufficient. Without this ingress, set web.publicBaseUrl and blobserver.publicUrl to your reachable addresses.

Administration uses the same application ingress and requires instance-administrator access.

Bundled PostgreSQL uses one replica and a persistent volume. Arrange backups and recovery; the chart does not supply failover or point-in-time recovery. To use an operator-managed database, set postgresql.enabled=false and configure postgresql.external.*.

Keep runner.replicaCount and browser.replicaCount at 1. Their job state is attached to the process that accepted it. Increase resources instead of putting interchangeable replicas behind the service. See Capacity.

Upgrades​

Back up PostgreSQL, artifact storage, and your secret configuration. Keep a private values file and pass it explicitly:

helm upgrade testvibe oci://testvibe.azurecr.io/charts/testvibe \
  --version <new-version> -n testvibe -f values.yaml

To recover values from an existing release before editing them:

helm get values testvibe -n testvibe -o yaml > values.yaml

That file may contain secrets; protect it. Preserve existing database and encryption keys. Review release notes and check the migration job and rollout after the upgrade.

A restricted-network installation can use the bundled chart and mirrored images through global.imageRegistry. Preload every image and model dependency and validate licensing and integration requirements for that environment; having the chart locally alone does not establish offline readiness.