Skip to content

Upgrade

For an operator running the Helm chart: at the end, Agent Kourier runs a newer build with its sessions, outbox and audit log intact, and you know how to roll back.

There is no tagged release yet. Once there is, each release publishes a signed multi-arch image and a chart whose default image is that image by digest.

Upgrade the chart

helm upgrade agent-kourier oci://<registry>/<repo>/charts/agent-kourier --version <new version> \
  -n agent-kourier -f my-values.yaml
  • SQLite (the default). The Deployment's strategy is Recreate: the old pod stops and releases the volume before the new one starts, so Agent Kourier is down for its start-up. Its volume carries the sessions, the outbox and the reply queue across, and recovery continues each conversation where it stopped.
  • Postgres with a standby. The strategy is a rolling update. The leader hands the lease over when it stops, so the other replica takes over within a retry period.
  • Agent Kourier applies its own database migrations at start.

Deploy by digest. A released chart pins its image by digest, so --set image.tag=... alone changes nothing: set image.digest, or image.digest="" together with the tag.

Roll back

Install the previous chart version, whose default image is that release's digest, or set image.digest back to the previous release's digest. A bad release is not deleted or retagged: a new tag carries the fix.

Verify a release before you deploy it

Deploy only digests that cosign verify accepts: an unsigned digest is not a release. The repository's RELEASING.md has the commands for the image's signature, SBOM and provenance, and for the chart.

Upgrade across the rename

The chart was called courier before the project became Agent Kourier. A release installed under that name (helm install courier ...) gets the fullname courier-agent-kourier from the renamed chart, so an upgrade makes a new Deployment and, with SQLite, a new and empty <fullname>-data claim beside the old one.

The old claim survives, because persistence.retainOnUninstall defaults to true, and the database file in it keeps its old name (the default persistence.dbFile), so there is nothing to convert. To carry the data over, upgrade with persistence.existingClaim: <old release>-data, or keep the old names with fullnameOverride: <old release>.

With Postgres nothing is stored in the chart's volume: a migration adds the renamed purge functions beside the old ones, and a replica from before the rename keeps working until the rollout finishes.