Configure Environments and App Repository
Two settings panels define what a project tests and where its code lives: Settings → Environments for the test site URLs, and Settings → App Repository for the optional source code connection.
Environments
A project can have multiple test site URLs — for example staging, QA, and preview — with one marked as the default. Runs, recordings, and automations pick which site URL to use; the default is used when nothing else is chosen.
| Good choice | Why |
|---|---|
| Shared staging URL | Stable and reachable by cloud test sessions. |
| QA environment URL | Usually safe for repeat test data and automation. |
| Public preview URL | Useful for short-lived validation. |
The cloud test session must be able to reach the URL. For private, VPN-only, or internal sites, connect a tunnel device — the URL stays unchanged and nothing inbound is opened. See Tunnel devices.
Avoid localhost — a cloud session cannot reach your machine without a tunnel device running on it.
Environment Availability
Wherever you pick an environment — the run composer, the Load Configure form, the Generate and Record dialogs, and Settings → Environments — each entry shows a live availability chip so you can see whether the cloud can reach that site before you start:
| Chip | Meaning |
|---|---|
| Available | The cloud can reach this site directly. |
| Via tunnel · device | Reachable through the named tunnel device inside your network. |
| Tunnel offline · device | The site needs its tunnel device, but that device is offline right now. |
| Needs a tunnel | A private, VPN-only, or localhost site with no tunnel configured. |
For a tunnel-backed environment the chip names its device and opens a per-device dropdown listing each device's online state, when it was last seen, whether it's scoped to this site's URL, and which one this project would actually use, plus a Manage tunnels link. On Settings → Environments a quiet re-check button next to the list refreshes the current state on demand.
The chips are informational only — they never block a row, so you can pick an offline-tunnel environment intending to bring the tunnel up first. Dispatch still enforces reachability: if you start a run, generation, or load test against a site the cloud can't reach, TestVibe prompts you before spending credits with Connect a tunnel or proceed anyway. See Tunnel devices.
App Repository
Settings → App Repository holds the project's optional, read-only source code connection (GitHub, GitLab, or Azure DevOps):
| Field | What it does |
|---|---|
| Source repository | The assistant reads the application code for context; read-only. |
Two-way mirroring of your generated test files to a Git repository — features, specs, and Playwright configs, edits flowing both ways — is a separate panel, Settings → Test Files Sync.
Both are optional — project content always lives in TestVibe's cloud.
After Saving Settings
Run a small test to confirm the session opens the right site URL and results stream back into the app. If a private site cannot be reached, check the tunnel device first.