Skip to main content

TestVibe 0.4.19

All release notes · Self-hosted upgrade guide

2026-10-23. Self-hosted packages published from application source 24b1c087752d4a0d9a33b71f5905f64c466924c9, tagged v0.4.19.

Target HTTPS CA roots​

Installation administrators can configure public company root CA certificates at Settings → Administration → Network & DNS → Target HTTPS CA roots (PEM) on self-hosted installations. This is a paste field, not a file-upload dialog.

  • Paste public PEM root-certificate blocks supplied by your IT team. Never paste a private key or a target site's server/leaf certificate.
  • The bundle is limited to 16 roots and 64 KiB. Roots must be currently valid, self-signed certificate authorities with valid supported signatures. RSA roots require at least 2048 bits; supported ECDSA curves are P-256, P-384 and P-521. Supported signature hashes are SHA-256, SHA-384 and SHA-512.
  • Save the section, then start a fresh run or generation. Close existing browser sessions after saving, rotating or removing roots: new sessions capture the saved policy.
  • Saving an empty field disables additional roots, including deployment defaults. Reset to deployment default restores the deployment policy instead.

Normal hostname, certificate validity and chain checks remain enabled. This setting does not change the host operating system's trust store or install trust on customer-owned remote browsers. Installation-wide DNS configuration is separate from CA trust; the target hostname must still resolve correctly.

The field's shipped help text still describes its earlier Chrome/Chromium scope. Do not interpret this release as verified acceptance of every browser, load-test or customer-owned runtime; the qualification limits below apply.

On TestVibe Cloud, a separate hosted-only update shows Network & DNS to installation administrators as empty, disabled controls with Available on self-hosted installations. Hosted installation values are not exposed, and writes remain unavailable. Workspace ownership alone does not grant installation administrator access. This hosted UI update is separate from the versioned self-hosted packages.

Published packages​

Compose bundles, the Kubernetes chart, Hyper-V/VHDX and OVA packages are published. Use the authenticated customer portal and verify the version offered for your deployment format.

  • testvibe-selfhosted-v0.4.19.zip and .tar.gz: Compose and bundled Helm chart.
  • oci://testvibe.azurecr.io/charts/testvibe, chart version 0.4.19.
  • testvibe-0.4.19.vhdx.tar: Hyper-V OS and new-install DATA disks, compressed with Zstandard inside the tar archive.
  • testvibe-0.4.19.ova: VMware / VirtualBox appliance.

Verify downloaded files against the matching SHA256SUMS catalog. Its SHA-256 is b5b5777442e974e9973b834de972590cd84b3b067cda375cf137691bc4cb2fce.

Hyper-V upgrade​

Allow active work to finish and back up the database, artifacts, configuration and original protection keys. Shut the VM down gracefully and retain a copy of the existing DATA disk and old OS disk.

Extract the tar archive and decompress testvibe-0.4.19-os.vhdx.zst to .vhdx with a Zstandard-capable archiver. With the VM off, replace only the OS disk with the decompressed new OS disk. Keep the existing DATA disk attached once, as the second disk. Do not replace it with the empty DATA disk included for new installations.

Boot, allow migration/startup to finish, confirm the installed version and open an existing run and artifact. If the new version has started, rollback requires the matching DATA backup as well as the old OS disk; do not place an old OS over a changed database. Follow the upgrade guide.

Validation scope​

The ordinary publishers completed build/package and credential checks, appliance basic boot and unsealed-installation checks, archive structure/decompression and checksum checks, download-store object checks, and exact source/version/tag checks. The final small checksum manifest was independently downloaded and its digest verified. Full appliance payloads were not independently downloaded again through an authenticated customer session; publication is not proof of customer access.

At the user's direction, custom blocking release-qualification harnesses were disabled with their source and prior results preserved. Native instrumented .NET coverage, restart/paired restore, historical upgrade/restore and independent Compose/Kubernetes acceptance remain unverified, not passed. Customer Hyper-V, VMware and VirtualBox imports and customer network environments are not claimed validated by this release.

These limitations do not authorize ignoring TLS errors, changing customer trust stores, or modifying customer network settings.