Self-Hosting

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 is delivered as a Docker bundle — a versioned release containing a docker-compose stack and an .env template — so a single docker compose up brings up a complete, private TestVibe.

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.

info

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.