TestVibe 0.4.7
All release notes · Self-hosted upgrade guide
Archived release. Superseded by 0.4.9. Downloads are no longer offered; these notes remain available for upgrade planning.
A fresh Kubernetes install follows the documentation again, and the administration console stops telling an operator an install is ready when it cannot generate a single test. This is a release that shipped containers, the Helm chart, VHDX, and OVA. Docker and Kubernetes users upgraded from 0.4.5; appliance users from 0.4.3. Version 0.4.6 was tagged but not published; its changes below shipped in 0.4.7.
helm installno longer needssecrets.protectionKey. The 0.4.6 chart refused to render without a value its ownvalues.yamldocumented as "leave this empty" — the defect called out in the 0.4.6 notes below. The check is gone, so the documented minimum installs. Supplying your own Secret withsecrets.existingSecretnow works too: both key references are marked optional, where before an operator who followed that advice and omitted the key put every pod intoCreateContainerConfigError. An install that already passes an explicit key keeps working unchanged — and must keep passing it, using the same protected values file on each upgrade.- Connecting a named AI provider in the console never worked. Anthropic, OpenAI, OpenCode and OpenRouter are offered as one-click connections that deliberately send no base URL — and the save path demanded one before it looked at the kind, so it discarded the API key you had just typed. It works now. If you tried to connect a provider by name on 0.4.5 or 0.4.6 and it appeared to do nothing, this was why.
- The setup checklist stops calling an install complete when it cannot generate anything. "Get started" printed an N-of-M count that never included AI models, so a box with no provider connected read as fully set up and then failed at the first generation. AI models is now a row and counts — and "configured" means a provider is enabled with at least one model ticked, not merely that a provider row exists, since a connected provider starts switched off. A database that cannot answer reports Not checked rather than being asserted as undone.
- Creating an environment is a guided seven-step flow — database, licence, addresses, mail,
sign-in, AI providers, first user — instead of a modal that asked for a connection string and
wished you luck. A console with no database wired lands on it directly. Mail also gained
TESTVIBE_MANDRILL_API_KEY, which the app has always read and no console ever offered, and Send test now refuses on a Mandrill install and says why rather than reporting a green result for a path the app would not take. - The console stopped presenting unknowns as facts. An unprovisioned deployment renders "— not provisioned" instead of a confident "Workspaces 0 · Running now 0" that reads as healthy and idle. Runs, load tests, generations and the impersonation log load a capped page, so a filter that missed on page one used to answer "no runs match" — a wrong answer indistinguishable from a right one; each list now carries its real total, the chip reads "300 of 4,812", and the empty state names the window it searched. Audit-log and credit-ledger timestamps render UTC to the minute, so two support sessions on one day can finally be ordered.
- One name per thing. The instance rail had two items both labelled Users opening unrelated screens. Creating the first account is now First user; the sign-up setting is Who may sign up; Deployments is Health; Sessions is Activity; the setup page is Get started; and installations are environments everywhere, including the switcher. Display strings only — no setting, variable or API name changed.
- Who may sign up is a real control.
TV_SIGNUP_MODEwas declared a choice with no renderer, so it was a free-text box you had to typeinvite,openorclosedinto exactly. It is now a radio group that shows all three options and what each one does.
Security fixes in the administration console. The sign-in throttle bucketed on a
caller-supplied X-Forwarded-For header, and the bundle publishes this console straight onto a host
port with no proxy in front of it — so varying the header minted a fresh bucket per attempt and
walked past the only brute-force control on TV_ADMIN_PASSWORD. It now meters on the socket peer
unless that peer is listed in the new TV_ADMIN_TRUSTED_PROXIES (comma-separated; * trusts any
peer). Leave it unset unless an ingress genuinely fronts this console and the container port
is not reachable around it. Separately, the console's installations file is now created empty with
its permissions already applied, so a connection string is never briefly world-readable.
The backup playbook told you to restore a key your install does not have. It instructed
operators to keep "the original protection key" from their .env — but Compose comments that
variable out, the Helm chart leaves it empty by design, and since 0.4.6 the app generates the key
into its own database. The playbook now branches on where the key actually lives for your
deployment. The appliance still sets the variable, so that advice stays.
Nothing about your AI configuration changes. No migration runs, no provider row is created or altered, and no model's ticked state moves. An install that upgrades and configures nothing keeps its existing providers, keys, models and generation engine exactly as they were.
Upgrading: Docker — pull the 0.4.7 tag and docker compose up -d. Kubernetes — helm upgrade
to chart 0.4.7. If your install passes secrets.protectionKey today, keep passing it — this
release makes the value optional for new installs, not removable from existing ones, and Helm
still does not remember it between upgrades. Nothing is required of your .env.
Appliances: 0.4.7 included VHDX and OVA images. These artifacts are now archived. For an upgrade, replace the OS disk and keep the existing data disk.
Schema migrations: from 0.4.5, this release applies V0273–V0276, carried forward from the unpublished 0.4.6 version. An appliance upgrading from 0.4.3 also applies V0269–V0272. Back up before upgrading.