The object store on self-hosted

On the cloud, TestVibe uses Azure Blob. Self-hosted swaps that for a small first-party service — the blob server — that stores objects on a plain filesystem path. That swap is already wired for you: TV_STORAGE_PROVIDER=http is set by both shipped deployments and is not something you configure.

Objects are keyed accounts/{account}/projects/{project}/runs/{run}/…, so what belongs to which workspace and project is legible on disk — useful when you are sizing or auditing, and the reason per-run and per-project deletion can be exact.

Why there are two

A Playwright trace is downloaded by the user's browser, directly from the object store — not proxied through the application. So the store needs one address for machines inside the deployment and a different one for people outside it.

Set it correctly

1. Appliance: console → Addresses → Artifact URL. On first boot the appliance seeds it from the address DHCP handed out, and the field stays editable — which matters, because an appliance has no OS login and a moved lease would otherwise break every trace link permanently. If the address changed, fix it here.
2. Docker Compose: set TV_BLOBSERVER_PUBLIC_URL in .env. It defaults to http://localhost:8080, which works only for someone sitting at the host — change it as soon as anyone else uses the install.
   .envcopy

   TESTVIBE_PUBLIC_BASE_URL=https://testvibe.example.com
   TV_BLOBSERVER_PUBLIC_URL=https://artifacts.testvibe.example.com

   Pinned in the environment means the console shows both fields locked, which is correct for a config-as-code deployment.

3. Behind a reverse proxy: publish a route to the blob server and put that route here. If the app is on HTTPS, the artifact URL must be too — a browser on an HTTPS page will refuse to fetch a plain-HTTP trace.
4. Prove it. Run one test, open the run, and open its trace from a normal user's desktop. Nothing else in the product exercises this path, which is exactly why it goes unnoticed until someone needs a trace.

The appliance generates all three on first boot and stores them on the data disk. The Compose .env.example ships the two blob keys as placeholders you must replace before the first start; the protection key is commented out and should stay that way. On Kubernetes the two blob keys are chart secret values and secrets.protectionKey is deliberately left empty.

Where users see it

• Settings → Storage (workspace) — the total, a per-domain breakdown with a meter, a "By project" card, and the retention controls. This panel is overview and policy; it has no delete buttons.
• Settings → Project → Project Storage — where deletion actually happens, scoped to the current project, per domain. Chat and notes require typing the project name to confirm.
• The Dashboard carries the same usage summary.

Numbers are refreshed by an hourly reconcile, and immediately when the panel is opened or an asset is deleted. A figure that looks stale usually is — reopen the panel.

What is switched off on self-hosted

The enforcement gates all short-circuit. Nothing is refused because of a quota:

• New runs, generations and load tests are never blocked by storage.
• Visual-regression baselines and PDF-import screenshots are never refused.
• The "Storage full" prompt never appears on a dispatch.

Mitigations, best first

1. Raise the storage entitlement in the database. This is the direct fix and it is one additive statement. Back up first, and run it against the TestVibe database.
   psql — raise the entitlement to 500 GBcopy

   -- what each workspace currently resolves to
   SELECT account_id, name, plan_code FROM tv_account;
   
   -- raise the entitlement on the plan(s) actually in use
   UPDATE tv_plan
      SET storage_bytes_included = 536870912000
    WHERE plan_code IN (SELECT DISTINCT plan_code FROM tv_account);

   On Docker Compose: docker compose exec postgres psql -U tvadmin -d testvibe. On Kubernetes, exec into the database pod. On the appliance there is no OS login, so this route is not available to you — use the next two, and contact support.

2. Set retention deliberately, so you stay under whatever the ceiling is. Settings → Storage → per-domain retention. Runs have no default retention (they are kept until quota pressure — which is precisely what the eviction above is); telemetry defaults to 30 days. Setting an explicit runs retention of, say, 14 days turns an unpredictable eviction into a predictable policy.
3. Delete deliberately. Settings → Project → Project Storage, per domain. Deletes are never gated, by design — they are the recovery path.
4. Grow the disk. That solves running out of space; it does not stop the eviction above, which is measured against the entitlement and not against free space.

Two more behaviours that surprise people

• The meter and the percentage in Settings → Storage are cosmetic on self-hosted. They are drawn against the same 1 GiB entitlement, so a healthy install can legitimately read "12.4 GB of 1.0 GB · 100%". Nothing is being refused because of it — with the one exception below.
• Asset uploads are the exception, and they are refused. The asset-upload path checks the quota itself rather than going through the exempted gate, so on a self-hosted install over the entitlement, Settings → Assets will refuse to open the file picker and the server will refuse the whole batch with "only N of your 1.0 GB storage quota is free". Raising the entitlement as above is the fix; there is no setting for it.
• Dormant workspaces on the default entitlement have their telemetry purged after 30 days of inactivity. Runs, features and specs are not touched by that sweep — only telemetry.

1. Find out which project. Settings → Storage → the "By project" card. It is almost always one project with a nightly full suite.
2. Clear the biggest domain for that project. Settings → Project → Project Storage → the Runs & traces row. This removes the artifacts and the staged bundles; the run rows and their results stay, so history and trends survive.
3. Then set a retention policy so you do not do this again. Settings → Storage → the retention field on the same domain.
4. Check the free space actually moved.
   appliancecopy

   df -h /var/lib/testvibe /var/lib/postgresql
   du -sh /var/lib/testvibe/blob

   docker composecopy

   docker system df -v | grep testvibe_
   docker compose exec blobserver du -sh /data

Backups

• Appliance: the data disk is the backup unit. Snapshot or back up disk 2 and you have the database, every artifact, the secrets, the install ID and the licence. The OS disk holds nothing of yours.
• Compose / Kubernetes: back up the Postgres volume and the blob volume together. Restoring one without the other gives you runs whose traces 404, or orphaned files nothing references.
• Appliance only: keep a copy of TESTVIBE_SECRET_PROTECTION_KEY with the backup. On Compose and Kubernetes the key lives inside the database, so your database backup already has it.
• Backup and restore has the step-by-step procedure for each shape, including the restore ordering that avoids the mismatch above.

Where to go next

• The installation guide — backup and restore, and the full port map.
• Licensing · Sign-in · AI providers · Integrations · Capacity.
• support@testvibe.com — especially if you need long trace retention on an appliance.