Skip to main content

TestVibe 0.4.20

All release notes · Self-hosted upgrade guide

2026-10-26. Self-hosted packages are version-pinned to 0.4.20 from application and appliance tooling source d41d03073018fe2aa337ddf335f4d756899aa65a, tagged v0.4.20.

Static IPv4 on native appliances​

See appliance IP address configuration for the operator guide, including accepted values, confirmation, rollback and console recovery.

Installation administrators can choose DHCP (automatic) or Static IPv4 at Settings → Administration → Network & DNS → IP address configuration. This release supports the native appliance's single Ethernet adapter. Initial setup still uses DHCP; configure static addressing after signing in.

  1. Keep the VM's physical console available and reserve an unused address with your network administrator.
  2. Select Static IPv4, enter the IPv4 address and prefix length (1–30), and optionally enter a default gateway in the same subnet.
  3. Review the DNS servers below the address controls. Review application and artifact URLs under Addresses, certificates and identity-provider callback URLs separately; changing the IP does not rewrite them.
  4. Choose Apply network change. The connection may be interrupted.
  5. Reconnect at the new address, sign in, open Network & DNS and choose Confirm connection and keep settings within the displayed two-minute confirmation window.

If the change is not confirmed, the previous addressing is restored. Cancelling, an apply failure, an interrupted apply or a reboot before confirmation also restores the previous configuration. Restoration takes additional time after the watchdog detects the timeout. A successful apply must be durably recorded before confirmation is offered.

To return to automatic addressing, select DHCP (automatic) and follow the same apply/confirm process. If you cannot reach the application, wait for rollback or use Restore DHCP networking on the VM console. Existing DNS overrides are retained by console DHCP recovery.

Confirmed configuration is stored on the DATA disk and restored during boot. Retain that disk during an OS-disk upgrade. If the saved adapter is unavailable, the appliance falls back to DHCP and asks for a configuration review.

Hosted TestVibe does not expose a host-network configuration API. Docker, Kubernetes, multiple-adapter, IPv6 and custom-netplan networking remains managed through the infrastructure administrator. Workspace ownership alone does not grant installation-administrator access.

Packages and checksums​

Use the authenticated customer portal and verify that the selected deployment format offers 0.4.20.

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

Verify downloaded files against the matching SHA256SUMS catalog.

Upgrade while preserving DATA​

Allow active work to finish, back up the database, artifacts, configuration and original protection keys, and retain the old disks for recovery.

For Hyper-V, shut down the VM, extract the tar archive and decompress testvibe-0.4.20-os.vhdx.zst to .vhdx. Replace only the OS disk and keep the existing DATA disk attached once as the second disk. Do not replace it with the blank DATA disk supplied for new installations.

Boot, allow migration/startup to complete, check the installed version and open an existing run and artifact. Compose and Kubernetes operators should use the version-pinned bundle or chart and preserve their configuration, secrets and persistent volumes. Follow the upgrade guide and backup guide. Switching an old OS onto a migrated database is not a complete rollback.

Validation scope​

Automated .NET, PostgreSQL, React and appliance checks cover authorization, strict address validation, stale/repeated requests, cancellation, errors, confirmation, interrupted apply, timeout, reboot and retained-DATA restoration logic. Address transitions and recovery were exercised with isolated fixtures; real netplan generation and systemd syntax were also checked without applying host network settings.

The standard publishers verify package/source identity, credential exclusion, image/chart publication, native basic boot and unsealed installation identity, archive structure/decompression, checksums and download-store object names. Publication completes only after these checks and artifact verification.

Live DHCP/static transitions, customer hypervisor import, legacy upgrade/restore and independent Compose/Kubernetes acceptance were not run. Existing disabled acceptance harnesses remain disabled. No customer or host network settings were changed during development.