Your own hostname and HTTPS

Out of the box TestVibe answers on an IP address over plain HTTP. To reach it at a name like testvibe.example.com with a certificate, you put your own proxy in front and then tell TestVibe its new address. There are two addresses to set, not one — and the second is the one people forget.

Appliance maintenance. The appliance provides a restricted recovery menu, with no general-purpose operating-system login. Use your hypervisor for disk backups and resizing. Appliance shell commands below are reference for support-assisted maintenance; they cannot be entered in the recovery menu. Compose and Kubernetes commands run on a host you manage.

Why there are two addresses

TestVibe serves the app from one place and your test results — traces, screenshots, videos — from another.

The app is what you look at. The artifact store is where a finished run puts its trace and screenshots. When you open a run, the app hands your browser a link to the artifact store, and your browser fetches it directly. So your browser has to be able to reach both.

Address	What it is	Administration field
The app	The pages people sign in to and use.	Settings → Addresses → Application URL
The artifact store	Traces, screenshots and videos from finished runs.	Settings → Addresses → Artifact URL

The trap If you put the app on HTTPS and leave the artifact store on plain HTTP, runs will pass and results will look fine — and every trace and screenshot will fail to load. Browsers refuse to fetch a plain-HTTP file from an HTTPS page, and they do it quietly. It looks like a TestVibe bug. It is a missing second route.

What is listening, per shape

Point your proxy at these. Nothing here changes when you add a proxy — the original ports keep listening.

Shape	App	Artifact store	Settings → Administration
Appliance	`:80` (already proxied to the app), or `:8080` direct	`:8090`	Same application URL
Docker Compose	`:3000`	`:8080`	Same application URL
Kubernetes	the `web` Service	the `blobserver` Service	Same application URL

Appliance The appliance already runs a small nginx on :80 that forwards to the app. It does not forward the artifact store. That is why you have to publish a second route yourself.

Kubernetes The chart can do all of this for you — see section 05. You do not need a separate proxy unless you already have one.

nginx — appliance or Compose

One server block for the app, one for the artifact store. Replace the two host names and the upstream address with yours.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# 1) The app.
server {
    listen 443 ssl;
    http2  on;
    server_name testvibe.example.com;

    ssl_certificate     /etc/ssl/certs/testvibe.crt;
    ssl_certificate_key /etc/ssl/private/testvibe.key;

    # Uploads and imported files. Match the appliance's own limit.
    client_max_body_size 128m;

    location / {
        # Appliance: the box's own address on :80 (or :8080).
        # Compose:   http://127.0.0.1:3000
        proxy_pass http://10.0.0.50:80;

        proxy_set_header Host              $http_host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # LOAD-BEARING. The app holds a live connection open to push updates.
        # Without these three lines the app loads and then silently stops
        # updating, which looks like a slow or flaky install.
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # Traces stream for a while. Do not cut them off.
        proxy_read_timeout 300s;
    }
}

# 2) The artifact store. Same certificate, different name.
server {
    listen 443 ssl;
    http2  on;
    server_name artifacts.example.com;

    ssl_certificate     /etc/ssl/certs/testvibe.crt;
    ssl_certificate_key /etc/ssl/private/testvibe.key;

    client_max_body_size 512m;

    location / {
        # Appliance: :8090. Compose: the published blob-server port, :8080 by default.
        proxy_pass http://10.0.0.50:8090;
        proxy_set_header Host              $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

Prefer one host name? Serve the artifact store under a path instead — for example location /artifacts/ { proxy_pass http://10.0.0.50:8090/; } — and use https://testvibe.example.com/artifacts as the Artifact URL in step 04. Keep the trailing slashes exactly as shown, or the path is passed through twice.

Tell TestVibe its new address

The proxy alone is not enough. TestVibe builds sign-in redirects and artifact links from these two values, so until you change them it keeps handing out the old address.

Point DNS at your proxy. testvibe.example.com and artifacts.example.com should both resolve to it. You should see: the certificate loads in a browser, even if the page behind it errors.
Sign in to TestVibe with an instance administrator account.
Go to Settings → Administration → Addresses.
Set Application URL to https://testvibe.example.com — no trailing slash.
Set Artifact URL to https://artifacts.example.com (or your /artifacts path). You should see: both fields save and the page tells you a restart is needed.

Restart. These two only take effect on restart.

# Appliance: use the VM recovery menu to restart services.

# Docker Compose
docker compose restart web blobserver

# Kubernetes
kubectl -n testvibe rollout restart deploy/testvibe-web

On the appliance These fields start out holding the address the box picked up on its first boot. Editing them here is the supported way to change them — you do not need a login on the machine, and you should not edit testvibe.env by hand. Writing the value into that file locks the Administration field.

Kubernetes — let the chart do it

The chart ships an Ingress for both the app and the artifact store, so you usually do not need your own proxy at all.

ingress:
  enabled: true
  className: nginx
  host: testvibe.example.com
  tls:
    - secretName: testvibe-tls
      hosts: [testvibe.example.com]
  # The artifact store gets its own route under the same host.
  blobserver:
    enabled: true
    path: /artifacts

web:
  publicBaseUrl: https://testvibe.example.com
blobserver:
  publicUrl: https://testvibe.example.com/artifacts

Set web.publicBaseUrl and blobserver.publicUrl in the same change. They are the Helm equivalents of the two Administration fields in step 04, and the same rule applies: the Ingress alone does not tell TestVibe what its address is.

Ingress controller If yours is nginx, annotate it to allow the live connection the app keeps open and to accept large uploads: nginx.ingress.kubernetes.io/proxy-read-timeout: "300" and nginx.ingress.kubernetes.io/proxy-body-size: 128m.

Administration uses the normal application Ingress and requires an instance-administrator account. The chart does not create a separate admin Service or Ingress. If the application is unavailable, use the host recovery executable described in the troubleshooting guide.

Check it worked

Four checks. The third is the one that catches the mistake this page exists to prevent.

Sign in at your new address. You should see: the sign-in page over HTTPS, and a successful sign-in.
Leave a page open for a minute. You should see: it stays live. If counters and lists freeze, your proxy is not passing the connection upgrade — go back to the three load-bearing lines in section 03.
Open a finished run and click through to its trace. You should see: the trace viewer open with screenshots. If the page is blank or the links are dead, open your browser's developer console: a Mixed Content or connection error there means the Artifact URL is wrong or that route is not published.
Sign out and back in with your identity provider, if you use one. You should see: a normal round trip. If it fails, the redirect URI registered with your provider still names the old address — see The redirect URI.

Things that catch people out

Symptom	Cause
The app loads, then stops updating. Nothing errors.	The proxy is not forwarding the connection upgrade. Add the `proxy_http_version`, `Upgrade` and `Connection` lines.
Runs pass, but traces and screenshots are broken links.	The Artifact URL still points at the old address, or the artifact store has no route through the proxy.
Sign-in with GitHub, Google or OIDC fails after the move.	The redirect URI at your provider is built from Application URL. Re-register it with the new address.
An old `/admin` link opens the normal application.	Expected in 0.4.14 and later. Sign in and open Settings → Administration.
Large uploads or imports fail at the proxy.	`client_max_body_size` is smaller than the 128 MB the app itself accepts.
It worked, then broke after a reboot.	The address was written into a file instead of Administration, or DHCP moved the machine. Give the machine a fixed address or a reservation.

Where to go next Identity & sign-in for redirect URIs, and Storage & artifacts for what the artifact store holds and how long it keeps it.

Why there are two addresses​

What is listening, per shape​

nginx — appliance or Compose​

Tell TestVibe its new address​

Kubernetes — let the chart do it​

Check it worked​

Things that catch people out​