Skip to content
Edit page
Copy page

Verify & Upgrade

This page covers the checks and cautions that apply on every platform, after you install the portal. For the install, verification, and upgrade commands on each platform, see Deploy on VMs, Deploy on Kubernetes, and Deploy on OpenShift.

Verify

Confirm every instance is serving, not just that the deploy command succeeded. The deployment guides show the per-instance checks on each platform.

Then verify the two things a single-instance smoke test cannot catch, on any platform:

Sessions are shared. Log in through the load balancer or ingress, then stop the instance that served the login. The next request should land on another instance with the session intact. If you are logged out instead, the instances are not reading the same session table — check that every instance points at the same external database and resolves the same encryption key and session secret.

Only one instance dispatches each event. Trigger a credential change and confirm the registered subscriber receives exactly one delivery, not one per instance. See Control Plane Connection.

Upgrade

Upgrade one instance at a time so the others keep serving: a rolling update on Kubernetes and OpenShift, and one VM at a time, drained from the load balancer, on VMs. The deployment guides show the commands and rollback for each platform.

Two things hold on every platform:

  • Old and new instances overlap during a rolling upgrade, so peak database connections briefly exceed instances × max_open_conns. Leave headroom for it.
  • A rollback reverts configuration, not database schema changes. Check the release notes before upgrading across a version that migrates the schema.