Roll back
Read the boundary section first. It decides whether a rollback is safe or whether you need a restore.
The boundary, stated plainly
helm rollback reverts manifests. It does not revert your database.
That single sentence is the whole risk. Helm restores the previous Deployments, images and configuration. Any schema change the upgrade's migration hook applied is still applied. If the old application cannot read the new schema, rolling back the manifests gives you old code against a new database.
| Situation | Rollback is |
|---|---|
| Patch upgrade within a train, no migration ran | Safe. Just do it |
| Minor upgrade whose migrations only added things | Safe. Old code ignores what it does not know |
| Minor upgrade whose migrations removed or renamed something the old code reads | Not safe. Restore from backup instead |
| You are not sure which | Check the release notes. If they do not say, ask us before rolling back |
Migrations that add in one train and remove in a later one mean a one-release rollback never needs a schema change. That is the design intent, and it is what makes most rollbacks safe. It is not a guarantee for every release, which is why this page exists rather than a one-line reassurance.
Before you start
- You know which revision you are going back to
- You have read the release notes for the version you are leaving
- The previous release's images are still in your registry
Offline bundle method: mirroring is additive, so the old tags are still there unless you deleted them. Do not prune your registry between an upgrade and the point at which you are confident.
1. Find the revision
helm history g0s -n gen0sec
The output is similar to this:
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Sep 1 10:14:02 2026 superseded gen0sec-platform-0.1.0 0.1.0 Install complete
2 Mon Sep 1 15:41:18 2026 deployed gen0sec-platform-0.2.0 0.2.0 Upgrade complete
2. Roll back the platform
Start here. In most cases this is the only step you need, because the application is what broke.
helm rollback g0s 1 -n gen0sec
kubectl -n gen0sec wait --for=condition=Ready pod --all --timeout=10m
$KIT/scripts/verify-deployment.sh
If the smoke test passes, stop. Do not roll back infra or data unless they are the problem.
3. Roll back the schema, only if you must
Needed when the upgrade applied a change the old code cannot work with. Check the release notes first.
kubectl -n gen0sec run db-migrate-down --rm -it --restart=Never \
--image=$REGISTRY/gen0sec/db-migrate:<previous-version> \
--env DATABASE_URL="$OWNER_DSN" -- down
$OWNER_DSN is the superuser connection string from the gen0sec-db-migrate secret. See
Secrets.
Reversing a migration that dropped a column recreates the column, not its contents. If the upgrade removed data, only a restore brings it back. See Back up and restore.
4. Roll back infra and data, only if they are the problem
Same order as the upgrade, in reverse: platform, then data, then infra.
helm rollback g0s-data 1 -n gen0sec-system
helm rollback g0s-infra 1 -n gen0sec-system
Helm never manages CRDs after the first install, in either direction. A rolled-back operator runs against the newer CRD schema. That works when the change was additive, which is the usual case, and it is another reason to roll back the platform alone where possible.
When a restore is the right answer instead
Rollback is for "the new version misbehaves". Restore is for "the data is wrong".
| You want to | Use |
|---|---|
| Undo a bad release | Rollback |
| Undo a destructive migration | Restore |
| Recover from data corruption | Restore |
| Return to a point in time | Restore |
If it fails
| Symptom | Cause |
|---|---|
ImagePullBackOff after rollback | The previous version's images were pruned from your registry |
| Old pods start, then error on database queries | Schema mismatch. Go to step 3, or restore |
helm rollback reports no such revision | helm history was truncated. helm get manifest g0s --revision N to confirm what exists |