Upgrading

helm upgrade edisyl \
  oci://944311261080.dkr.ecr.us-east-1.amazonaws.com/edisyl-charts/edisyl-helm \
  --version <new-chart-version> \
  -n edisyl \
  -f edisyl.values.yaml \
  --timeout 20m

Pin --version, pass -f, and keep the long timeout, exactly as on installing.

--wait and --atomic behave differently here than on a first install. The migration runs as a pre-upgrade hook, so it completes before the deployments are updated — there is no ordering deadlock to avoid. --atomic is still worth avoiding: a rollback reverts the manifests while leaving the migrated database as it is, which is the mismatch described below.

Before you upgrade

Read the changelog for what changed in the platform between your current release and the target.

Update your image tags to match the chart version. Chart version and image tags move together; the image matrix publishes the tag set for each release, with a values block ready to copy. A new chart with old images is not a combination we test.

Take a database backup. Upgrades run migrations, and migrations are not reversible by re-installing the older chart.

What happens

The migration hook runs to completion first, then the deployments roll. Expect a short window where old pods are still serving against an already-migrated database, so keep migrations backward-compatible with the release you are leaving — or accept a brief outage.

Rolling back

helm rollback edisyl <revision> -n edisyl

This reverts manifests. It does not revert migrations. If the release you are leaving applied a schema change, the older application code may not run against the migrated database. Treat rollback as a way to recover from a bad configuration, not from a bad migration — for that, restore your backup.

Rollback does not delete an existing database cluster that both revisions declare. It is helm uninstall that destroys it — see Installing.

Keeping generated secrets stable

If you let the chart generate secrets, they are generated once and reused by looking up the existing Secret in the cluster. A plain helm upgrade against a live cluster preserves them.

Rendering without cluster access does not. Under Argo CD, or anywhere the manifests are produced by helm template, the lookup returns empty and every generated value is regenerated — including ENCRYPTION_KEY, which orphans data encrypted under the previous one. Supply those values explicitly instead; see Configuration.