Install

Prerequisites, the quick-start flow, and how upgrades and data persistence work for a self-hosted TestVibe.

TestVibe self-hosted ships in three shapes. They run the same application and the same version — pick by what you already operate:

Shape	What you get	Choose it when
Docker Compose	A docker-compose stack plus an .env template.	One host, fastest to evaluate.
Kubernetes	A Helm chart, in the same bundle and as an OCI artifact.	You already run a cluster.
Appliance (VHDX / OVA)	A bootable two-disk VM running the stack natively under systemd.	Hyper-V, VMware or VirtualBox — or an air-gapped site, since it pulls nothing at run time.

The Compose flow is below; the chart's own values.yaml and the appliance's first-boot banner carry their specifics.

Prerequisites

Requirement	Detail
Docker	Docker Engine with Compose v2.
Image access	The container images are private. You authenticate to the registry with a token TestVibe provides before pulling.
An AI provider	Test generation needs either a hosted AI key or a local model. The rest of the app runs without one. See AI models.
A license	Enforcement is on. You can boot first and activate during the grace window — see Licensing.
Network reach	The stack must be able to reach the site under test from inside your network.

Quick Start

1. Sign in to the registry. The images are private, so this is not optional — without it the next steps stop on denied or manifest unknown, neither of which says "you are not signed in".

   docker login testvibe.azurecr.io -u <token-name>

   Paste the registry token TestVibe issued you as the password. It is pull-only, scoped to the images your subscription covers, and revocable on its own — it is yours, not a shared credential. Once per host.

   On Kubernetes the equivalent is a pull secret:

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

   …then --set global.imagePullSecrets[0].name=testvibe-registry. The appliance needs neither — it carries its software inside the image and reaches no registry at all, which is what makes it the option for an air-gapped site.

2. Copy the template to .env and fill in the required values (see Configuration).

3. Start the stack:

   docker compose up -d

   The order is enforced automatically: database → schema job → object storage → app.

4. Check it came up:

   docker compose ps

   The app and object storage should report healthy, and the schema job should show Exited (0).

5. Open the app at the public URL you configured (the default is http://localhost:3000).

Generate strong, unique secrets for every key value (a database password and a few signing keys). Treat them like production credentials — don't reuse the template defaults.

First Sign-In And Licensing

On first boot the instance generates its own install id and starts a grace window.

Open the administration console on port 5120 and sign in with TV_ADMIN_PASSWORD. Its License panel shows the install id with a copy button; paste that into the self-hosted portal and paste the license you get back into the same panel. No restart — the app re-checks within about twenty seconds. The console's setup checklist covers the rest: mail, single sign-on, AI provider and capacity.

(The install id is also printed to the web container's logs, and on the appliance to the console banner at the end of first boot, along with the generated console password.)

Until a license is installed the app is fully usable; after the grace window lapses without one it stops starting new runs, generations and load tests — existing data stays readable. Full flow in Licensing.

If you didn't configure GitHub or Google sign-in, the app falls back to local email/password accounts.

Upgrades

To move to a new release:

1. Pull the new bundle and updated image tags.

2. Run docker compose up -d again.

The schema job re-runs and applies only the new changes (it's idempotent), then the app restarts on the new version. Your data in the named volumes is untouched.

Data, Backup, And Teardown

• Persistence — the database and object storage live in named Docker volumes that survive restarts and upgrades.

• Backup — back up those volumes (and your .env) on your normal schedule. They hold everything: data and the instance's license/grace state.

• Teardown — docker compose down stops the stack but keeps the volumes. Removing the volumes deletes all data — do it deliberately.

Related Help

• How it works

• Configuration

• Capacity and runners

• Licensing

• Release notes

• Troubleshoot execution