EQTY LabDocs

Upgrade

Customer upgrade process for the Guardian Platform.

View as Markdown

Plan Guardian Platform upgrades as customer operations. Review the release manifest, release notes, known issues, and rollback plan before changing a running environment.

Before Upgrade

  1. Confirm the target release supports the customer Kubernetes version and architecture.
  2. Back up PostgreSQL, OpenBao storage if Auth Service signs with OpenBao, object storage, chart values, and platform secrets according to customer policy. A 1.3 upgrade can’t be rolled back without this backup; see Rolling Back from 1.3 to 1.2.x.
  3. Review migration notes and behavior changes.
  4. Confirm identity provider, storage, key-management, and registry access are healthy.
  5. Pause non-essential bulk workflows if the customer rollout plan requires it.

Upgrade Flow

Upgrade the Guardian Platform chart to the version recorded in the release manifest, using reviewed customer values and secrets. Use the same chart source and values files as the install, and set --version to the target release:

bash
helm upgrade guardian-platform \
  oci://ghcr.io/eqtylab/charts/guardian-platform \
  --version <target-chart-version> \
  --namespace guardian \
  --values values.yaml \
  --values secrets.yaml

For a Cloudsmith delivery, upgrade from cloudsmith-prod/guardian-platform with values-cloudsmith.yaml last, as in Connected Install.

A release installed before 1.3 is named governance-platform, in the governance namespace, and needs values changes before its first 1.3 upgrade. Follow “Upgrading from 1.2.x” in the Guardian Platform v1.3.0 release notes instead of the command above.

With global.secrets.create: true, keep the database password in secrets.yaml unchanged. The bundled PostgreSQL keeps the password it was initialized with, so a new value locks the services out of the database.

Auth Service, Governance Service, Integrity Service, and the LLM Gateway apply their database migrations when their new pods start. A failed migration shows in that service’s pod logs. With the gateway stack enabled, upgrade in two steps so the gateway’s migrations finish before the Control Plane rolls out; see LLM Gateway Operations. To turn on agent certification, upgrade with it off, then follow Agent Certification.

After the upgrade, verify service readiness, sign-in, project access, attachments, reports, indicators, lineage, and certificate workflows.

After Upgrade

Record the upgraded chart version, values revision, release manifest, validation evidence, and any customer-visible issues. Keep rollback artifacts available until the customer accepts the upgrade.