Uninstall & recovery¶

Removing KubeManta¶

helm uninstall <release> -n <namespace> --wait

That removes the Deployments, Services, RBAC and config. It deliberately does not remove everything, and the difference matters.

What is kept on purpose¶

Kept	Why
`<release>-enc` Secret	The at-rest encryption key. Deleting it makes the database permanently undecryptable — every stored credential, cloud key and saved bundle becomes unreadable. It is annotated `helm.sh/resource-policy: keep` so an upgrade cannot destroy it.
`<release>-data` PVC	Your audit log, terminal command history, saved bundles, runbooks and settings.
`<release>-admin` Secret	The seeded administrator password.
`<release>-expert-exec`, `<release>-terminal` Secrets	Inter-pod credentials, regenerated only if absent.

This is why a reinstall into the same namespace keeps your history and your password: the state was never deleted.

The retained PVC holds your audit trail

It contains the record of who did what in your cluster, including terminal command history. If you are removing KubeManta for compliance reasons, or handing the cluster to someone else, delete it explicitly — it will not go away on its own.

Removing everything¶

helm uninstall <release> -n <namespace> --wait

# the deliberately-retained state
kubectl delete pvc,secret -n <namespace> \
  -l app.kubernetes.io/instance=<release>

# the namespace itself
kubectl delete namespace <namespace>

Then confirm nothing cluster-scoped survives:

kubectl get clusterrole,clusterrolebinding -o name | grep <release>

That should print nothing. If it does not, you are on a chart older than 2026-07-30, where the preflight hook resources were never cleaned up on uninstall — delete them by name.

Recovering a stuck release¶

If an install or upgrade is interrupted — a dropped terminal, a cancelled CI job, a timeout — Helm leaves the release locked and every retry fails:

Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

Nothing self-heals this. Check what state it is in:

helm list -A --all | grep <release>

Status	Recovery
`pending-install` (never succeeded)	`helm uninstall <release> -n <namespace>` then install again. Your PVC and Secrets are retained, so nothing is lost.
`pending-upgrade` / `pending-rollback`	`helm rollback <release> <last-good-revision> -n <namespace> --wait`. Find the revision with `helm history <release> -n <namespace>`.
`failed`	Usually safe to `helm upgrade` again. A `failed` release often means the timeout expired while the rollout was still progressing — check `kubectl get pods` first, because the deploy may in fact have succeeded.

A timeout is not always a failure

--wait --timeout gives up after a fixed period, but Kubernetes carries on. On a multi-node cluster pulling fresh image layers, a rollout can finish minutes after Helm has already reported failure. Always check the pods before assuming the deploy did not work.