Upgrades

Pin the image tag

helm upgrade presponsieve oci://ghcr.io/m-a-m-a-ai/charts/presponsievelite \
  -n presponsieve -f my-values.yaml --set image.tag=<NEW_TAG>

--set image.tag=latest appears in the quickstart because it is convenient for a first install. It is wrong for anything you intend to keep: two upgrades a week apart would install different software with nothing to explain the difference.

Back up the database first

The migration Job runs alembic upgrade head as a pre-install and pre-upgrade hook. Migrations are forward-only and Helm does not roll them back.

gcloud sql backups create --instance presponsieve-pg
aws rds create-db-snapshot --db-instance-identifier presponsieve-pg \
  --db-snapshot-identifier presponsieve-pre-upgrade

Do this every time. It takes seconds.

Render first

helm template presponsieve oci://ghcr.io/m-a-m-a-ai/charts/presponsievelite \
  -f my-values.yaml --set image.tag=<NEW_TAG> | less

A renamed value is silently ignored rather than rejected, so a setting you rely on can quietly stop being configured. Rendering catches that before it reaches the cluster.

What happens

1. The migration Job runs. An unreachable database fails the install cleanly, before any pod starts against a schema that is not there.
2. App pods roll.

Rolling back

helm history presponsieve -n presponsieve
helm rollback presponsieve -n presponsieve

warning

A rollback reverts workloads, not the database schema. If the upgrade ran a migration, rolling the release back leaves old code against a newer schema.

When a migration has run and the application is misbehaving, restore the pre-upgrade backup rather than relying on helm rollback alone.

If you manage the release with Terraform, move the pinned version back there too. A helm rollback not reflected in Terraform is undone by the next terraform apply, usually at the worst possible moment.

Uninstalling

helm uninstall presponsieve -n presponsieve

Leaves the external database and bucket intact, along with the secret. Delete those separately if you want the data gone — and be sure you have APP_KEK somewhere before you delete the namespace.

Kubernetes upgrades

The chart supports 1.27 and later. The Cloud SQL Auth Proxy needs 1.29, because it runs as a native sidecar.

Move the cluster version separately from the application version. Two changes at once means two candidate causes when something breaks.