Upgrading

Upgrading ISE is a Helm upgrade. Schema migrations run automatically, exactly once, before any new application pod starts.

Back up first

Always back up before upgrading, and back up two things:

1. The PostgreSQL database — all of ISE’s state.
2. The credential key-encryption key. Integration credentials are stored encrypted under this key. A database restored without it contains credentials nobody can decrypt — the estate survives, every connection does not.

Treat the pair as one artefact. A backup of either alone is not a backup.

Upgrade

helm upgrade ise ./helm -n ise -f values-production.yaml --set image.tag=main-20260731-1430

Pin the exact image tag. Tags are immutable and formatted <branch>-yyyymmdd-hhmm; latest is never published and never referenced, precisely so that “what is running?” and “roll back to what?” always have exact answers.

What happens, in order:

1. The migration Job runs as a pre-upgrade hook. Migration files are append-only, so the history is trustworthy and a given migration applies exactly once per release.
2. If migrations fail, the Helm upgrade fails before any new pod rolls out — the running version stays up. The hook Job’s logs are the first place to look during release triage; make them part of your routine.
3. Only after migrations succeed do the new API, worker, Beat, and frontend pods roll.

Because application containers never run migrations at startup, replicas can’t race each other and a crash-looping pod can’t re-run a migration.

Rolling back

helm rollback ise -n ise

Rollback returns you to a previous release with its exact, still-existing image — byte-for-byte, not an approximation.

One caveat that matters: helm rollback does not un-migrate the database. Schema changes are forward-only, so a rollback is safe when the previous application version tolerates the newer schema (the usual case for additive migrations) and risky when it does not. If a release contains a destructive or incompatible migration, your recovery path is the database backup, not helm rollback — which is the other reason step one is not optional.

Housekeeping

Helm hook-managed resources are not removed by helm uninstall; deleting the namespace is the complete cleanup. The image registry also accumulates immutable tags over time and eventually wants a retention policy.

Next steps

• Installation — the values and secrets referenced above.
• Audit trail — where credential handling and the key-encryption key are covered in more depth.