Self-Hosting

Run the entire TestVibe product on your own infrastructure — inside your firewall, off the public cloud — with Docker.

Self-hosting runs the whole TestVibe application on infrastructure you control: the app, its database, object storage, and the test/generation engines all live inside your network. Nothing about your projects, tests, or results leaves your environment.

It ships in three shapes, all running the same application at the same version: a Docker Compose bundle (a docker-compose stack and an .env template, so a single docker compose up brings up a complete private TestVibe), a Helm chart for Kubernetes, and a bootable appliance (VHDX for Hyper-V, OVA for VMware and VirtualBox) that runs the stack natively under systemd and pulls nothing at run time — which is what makes it the option for an air-gapped site.

Cloud, Private Runner, or Self-Hosted?

These three are easy to confuse. They sit on a spectrum of how much you host:

	What you host	Where your data lives	Use it when
Cloud (SaaS)	Nothing	TestVibe's cloud	The default. Your site is reachable from the internet and you don't need to host anything.
Private runner	Just the runner image	TestVibe's cloud (the app), your network (the test execution)	You use the hosted app but the app under test must never leave your network.
Self-hosted (this section)	The entire stack	Entirely your infrastructure	The whole product must run on-prem — air-gapped, data-residency, or compliance requirements.

A private runner is a feature of the cloud SaaS — you still sign in to TestVibe's hosted app. Self-hosting is the opposite: you run the app itself. If you only need test execution to stay inside your network, a private runner or a tunnel is far less to operate.

The Stack At A Glance

The bundle runs a handful of containers that together make a complete TestVibe:

Service	Role
web	The TestVibe app (Wisej/.NET) — what users open in the browser.
postgres	The application database.
migrate	A one-shot job that applies the database schema, then exits. See How It Works.
blobserver	Object storage for artifacts and run bundles (the on-prem replacement for cloud blob storage).
runner	Executes your Playwright test runs.
browser	A browser host the app drives for AI feature generation and the assistant.

Data persists in named volumes, so it survives restarts and upgrades. The full picture is in How It Works.

What You Can Do

Understand the stack

See the containers, how they fit together, and the startup order.

Install TestVibe

Prerequisites, quick start, data persistence, and upgrades.

Configure the instance

The environment-only config model, required values, and optional integrations.

Set up AI

Use hosted Claude/OpenAI keys or bring your own local model.

Activate a license

The offline license model, the grace window, and how to activate.

Related Help

• Private runners — host only the runner, keep the cloud app

• Where runs execute

• REST API