This guide walks you through fully removing a Midaz deployment from Kubernetes. A standard helm uninstall removes the Helm-managed resources, but several persistent resources — PersistentVolumeClaims, Secrets, ConfigMaps, and the namespace itself — are intentionally left behind to prevent accidental data loss. This page covers how to clean them up completely when needed.
Uninstalling Midaz permanently deletes application data. Before proceeding, ensure you have backups of all databases and any data you need to retain. This operation is irreversible.
Run the following command to uninstall the Midaz Helm release:
helm uninstall midaz -n midaz
This removes all Kubernetes resources created by the Helm chart — Deployments, Services, Ingresses, ConfigMaps managed by Helm, ServiceAccounts, and RBAC resources. It does not remove PersistentVolumeClaims, Secrets created outside Helm, or the namespace.Verify that all Helm-managed pods have been removed:
PVCs hold your database volumes and are never removed by helm uninstall. List them first to confirm what exists:
kubectl get pvc -n midaz
Delete all PVCs in the namespace (this destroys all data stored in those volumes):
kubectl delete pvc --all -n midaz
Or delete specific PVCs by name:
kubectl delete pvc <pvc-name> -n midaz
Deleting PVCs permanently destroys the underlying volume data for PostgreSQL, MongoDB, and any other stateful dependency. Make sure database backups are in place before running this command.
Secrets created outside the Helm release lifecycle (e.g., kubectl create secret) are not removed by helm uninstall. List all secrets in the namespace and identify any that are no longer needed:
Once all resources inside the namespace have been removed, delete the namespace itself:
kubectl delete namespace midaz
Deleting the namespace will forcefully remove any remaining resources inside it. If a resource is stuck in Terminating state, you may need to remove its finalizers manually.
For staging, evaluation, or CI environments where a full teardown is safe, the following script automates the entire process:
Data loss is permanent. Run this only in environments where you have confirmed backups or where data loss is acceptable (staging, evaluation, CI). Do not run this in production without a full backup and team sign-off.