Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Release Notes

What changed in each self-hosted release, what breaks, and the lowest version you can upgrade from.

Your administration console checks this list for you — Instance → Updates compares the version you are running against the current release and tells you what is new. Checking is opt-in and never automatic unless you turn it on, because a self-hosted install should not reach the internet without being asked.

Downloads live in the self-hosted portal; sign in with the email on your subscription.

0.4.3

Fixes for three problems that made the app look broken to the people using it — and the first release since 0.4.1 to ship everything: containers, Helm chart and appliance. Docker and Kubernetes users upgrade from 0.4.1; appliance users upgrade from 0.4.2.

  • The app no longer gets stuck on "Loading…". Sessions expired after two minutes of inactivity, and nothing said so — the tab simply stopped responding until you reloaded it by hand. It hit sign-up, email verification and email-change confirmation hardest, because every one of those asks you to leave for your mailbox and come back. Sessions now last 30 minutes and, when one does expire, the page reloads itself instead of hanging.

  • A project URL typed without https:// no longer breaks every run. Entering www.example.com was accepted, and the AI agent explored the site quite happily — but each run then failed immediately with nothing on screen to explain why, because the address was rejected somewhere the result never reached you. Addresses are now completed when saved, existing projects are corrected automatically, and an address that genuinely cannot be used is refused with a message that names it.

  • A run that fails before any test starts now tells you why. Failures of that kind previously showed "no per-scenario results" and left the reason in a file you had to go and open.

  • Command line. testvibe run --wait no longer treats a still-queued run as a finished one and exits 1; the published package also reports its own version correctly.

The appliance also carries every 0.4.2 fix below, built by the corrected pipeline that release introduced — so its disks seal themselves per copy.

Upgrading the appliance: attach the new OS disk and keep your existing data disk. Your database, artifacts, install identity and license all live on disk 2. Do not discard it.

Upgrading everything else: Docker — pull the 0.4.3 tag and docker compose up -d. Kubernetes — helm upgrade to chart 0.4.3.

Schema migrations: this release applies V0268 on first start. It runs automatically and is one-way — take a database backup first, as you should for any upgrade. It also repairs any project address that was stored without https://.

0.4.2

An appliance-only release, and a security fix. There were no 0.4.2 containers or Helm chart.

Every copy of the 0.4.0 and 0.4.1 appliance images shipped with identical secrets — the same secret-protection key, database password, blob and runner keys, administrator password and install identity — because the release pipeline completed the disks' first boot while testing them, then published those same disks. Both images are withdrawn and are no longer downloadable. The boot test now runs on a throwaway overlay, and the build proves the published disks still seal themselves independently by booting them twice and requiring two different install identities.

  • The first-boot banner now appears on the hypervisor's own console. It carries the address to open and the only copy of the generated administrator password, and it was going to a serial port that Hyper-V Generation 2 machines do not have — so the appliance looked dead while it was serving normally. It also persists above the login prompt instead of scrolling past once.

  • Port 80 answers. It serves the application, redirects /admin to the administration console, and shows a self-refreshing page while the app is still starting. Previously all three ports refused connections for the first few minutes, which is indistinguishable from a broken image.

  • An interrupted first boot repairs itself. Secrets are written atomically, and the appliance no longer trusts a marker vouching for files it never finished writing.

  • Booting with only one of the two disks attached now boots, serves port 80 and says which disk is missing, instead of dropping to an emergency prompt with no login.

If you ran a 0.4.0 or 0.4.1 appliance: treat that install's generated credentials as compromised and rotate the administration console password after upgrading.

Schema migrations: none over 0.4.1.

0.4.1

An appliance fix. Replace the VHDX or OVA if you downloaded one before 6 August 2026.

The virtual appliance shipped with a network configuration that named one specific adapter — the one present on the machine that built it. On any other hypervisor the adapter is presented under a different name, nothing matched it, and the appliance booted with no IP address, no first-boot banner, and no way to sign in. It affected Hyper-V, VMware and VirtualBox alike; the symptom looked like a broken image rather than a configuration problem, because it was one.

The image now configures whatever adapter it is given. Our own build-time boot test was part of the failure — it booted the appliance on the same adapter it was built with, so it could never have caught this — and it now tests on a different one.

Docker and Kubernetes installs were never affected.

  • Helm charts refuse to over-scale. runner.replicaCount and browser.replicaCount above 1 now stop the install with an explanation. Run state lives in the process that took the job, and the app polls for it through a load-balanced Service, so a second replica did not share load — it lost runs. See Capacity and scaling.

  • Everything in 0.4.0 below is unchanged.

Upgrading the appliance: attach the new OS disk and keep your existing data disk. Your database, artifacts, install identity and license all live on disk 2. Do not discard it.

Schema migrations: this release applies V0266 and V0267 on first start. They run automatically and are one-way — take a database backup first, as you should for any upgrade.

0.4.0

The administration console. License, mail, single sign-on, AI provider and capacity are configured in a UI instead of by editing environment files, and settings take effect without a restart.

  • New administration console — a separate service on its own port (5120), with a guided setup checklist. It is deliberately not exposed by the Kubernetes chart's ingress: publishing an administrative console should be an explicit decision.

  • Mail through your own SMTP relay. Earlier self-hosted installs had no supported mail path at all, so invitations, verification and notifications could not send. Use port 587 (submission, STARTTLS) or 25; implicit-TLS 465 is not supported — every mainstream relay offers 587.

  • Single sign-on via OpenID Connect — Entra ID, Okta, Keycloak, Auth0, Ping — plus GitHub and Google, all configurable at run time. The SSO panel prints the exact redirect URI to register with your provider; a mismatch there is the most common reason a first sign-in fails.

  • Settings are stored in the instance database and read live. Environment variables still win, and the console marks those fields as locked so it is obvious why one cannot be edited.

  • License activation moved into the console — copy the install id, paste the license, no restart.

  • Kubernetes — a Helm chart, shipped in the bundle under kubernetes/ and published as an OCI artifact at oci://testvibe.azurecr.io/charts/testvibe.

  • Appliance — bootable VHDX (Hyper-V Generation 2) and OVA (VMware / VirtualBox) images that run the whole stack natively under systemd, with no Docker and no registry access. Two disks: the OS disk is replaced by an upgrade, the data disk keeps your database, artifacts, identity and license.

Required configuration

Both are set in .env (or your Helm values) before the first start, and the stack refuses to start without them rather than booting into a broken state.

  • TV_ADMIN_PASSWORD (or TV_ADMIN_PASSWORD_FILE) — without it the console refuses every sign-in. It fails closed by design, so a broken single sign-on can never lock you out of the console you would use to fix it.

  • TESTVIBE_SECRET_PROTECTION_KEY — required to store credentials in the console. Back it up. It is not a password you rotate; it is the only key to that data, and changing or losing it makes every stored secret permanently unreadable.

VirtualBox users: set firmware to EFI before the first boot. The appliance is UEFI/GPT. VMware and ESXi read that from the OVA automatically; VirtualBox does not, and stops at "No bootable medium found!". Fix it in Settings → System → Motherboard → Enable EFI, or with VBoxManage modifyvm "TestVibe-0.4.0" --firmware efi. The OVA's import wizard says so too.

Related Help

PreviousLicensingNextREST API

Last updated

Was this helpful?