Skip to main content

Install

TestVibe self-hosted is delivered as a versioned release bundle: a docker-compose stack plus an .env template. Bringing it up is a short, repeatable flow.

Prerequisites​

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

Quick Start​

  1. Get the bundle and authenticate to the image registry with the token TestVibe gave you.
  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).
warning

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 prints an install id to the web container's logs and starts a grace window. Send that id and your organisation name to TestVibe to receive a license, then install it. Until then the app is fully usable; after the grace window lapses without a license it goes read-only. 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.