Upgrade

A Helm upgrade. Migrations are compiled into the binary and applied on first connection, so there is no separate step to forget.

Upgrading

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep --wait

Pin the version if your change process needs it:

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep --version 1.1.0 --wait

What happens to the database

Each migration is recorded when it runs, so it runs exactly once no matter how many replicas start at the same time. Findings, decisions, exceptions and evidence survive the upgrade; nothing is rebuilt from scratch.

What happens to admission during the rollout

With the default two replicas, one keeps answering while the other is replaced. With failurePolicy: Ignore a moment with no replica means unreviewed rather than blocked; with Fail it means deployments wait. That is the same trade described in Admission, and an upgrade is exactly when it becomes visible.

Verifying what you are about to run

Every release is signed. Check it before you upgrade:

cosign verify ghcr.io/attestkeep/attestkeep-k8s:1.1.0 \
  --certificate-identity-regexp '^https://github.com/attestkeep/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

A product that checks your signatures should be checkable the same way. The chart is signed too, and the release page carries the digest for each artefact.

Rolling back

helm rollback attestkeep --namespace attestkeep