Uninstall & recovery¶

Before you uninstall: keep your configuration¶

Uninstalling with the data volume removed, or reinstalling into a new cluster, starts KubeManta empty. To avoid re-entering every setting, export your configuration first from Admin → System → Configuration backup:

Choose a password of at least 12 characters; the file is encrypted with it (AES-256-GCM, scrypt-derived key). KubeManta never stores the password.
The file carries every admin setting — alert integrations and their credentials, alert rules, AI provider and guardrails, AI Context documents, SSO settings and group-to-role mappings, access-control lists, branding, applications, scanner and observability configuration, runbooks and scanner risk exclusions.
It does not carry history (audit trail, alerts, scans, incidents), local user accounts, two-factor secrets, API keys or the licence key.

On the new install, import it from the same card: Check file shows what would change before anything does; Import and restart applies it, and KubeManta restarts itself to load the new settings. A wrong password or a damaged file changes nothing.

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` Secret	Inter-pod credential, regenerated only if absent.
`<release>-terminal` Secret	Only on installs that ran 1.3.1 or earlier. Nothing reads it any more; delete it.
`<release>-trivy-cache` PVC	The vulnerability-database cache, created by KubeManta at the first built-in scan, not by Helm. Safe to delete; the next scan downloads the database again.

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 scanner's database cache (created by KubeManta, not Helm)
kubectl delete pvc -n <namespace> \
  -l app.kubernetes.io/managed-by=kubemanta,app.kubernetes.io/component=scanner

# the namespace itself
kubectl delete namespace <namespace>

Then confirm nothing cluster-scoped survives:

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

That should print nothing. If it does, delete them by name — a preflight ClusterRole or binding, or the <release>-terminal-guard and <release>-agent-secret-guard admission policies (present with rbac.allowWrites=true), left behind by an interrupted uninstall is safe to remove once the release itself is gone.

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.