Undeploy a Design

Remove the resources a design describes from your clusters, and understand exactly what is and is not deleted.

Categories:

Designer

Undeploying deletes the Kubernetes objects that each component in a design describes, from every cluster in the environments you select. It does not touch the design itself. The design record, its versions, and its Operator view are unchanged.

Before you start 🔗

The prerequisites match Deploy a Design: a Meshery you run with a connected cluster, a non-empty design, and the Undeploy Design permission. The hosted kanvas.new site does not run undeploy. See Permissions by Role.

The undeploy flow 🔗

Choose Undeploy from the design’s Actions menu. The Undeploy design "<name>" stepper has the same five steps and gates as the deploy stepper:

Validate Design. Runs validation inline.
Identify Environments. Selects the environments, and so the clusters, to remove from.
Dry Run. An undeploy-type dry run that deletes by name with server-side dry run. Because an absent object returns NotFound, a design that was never deployed, or is already removed, shows an error for every component here and needs the bypass checkbox to continue.
Finalize. Confirms the environments and component count. The button reads Undeploy.
Finish. Runs the removal and shows the results.

What gets deleted 🔗

Behavior	Detail
What is removed	One delete for each non-annotation component’s object, in its namespace, on every selected cluster.
How it is matched	By kind and name from the design, not by label. An object with the same kind and name that was created some other way is deleted too.
Order	Reverse dependency order. A component whose dependent failed to delete is withheld: `Withheld <component>: <dependent> did not undeploy successfully`.
Objects already gone	Ignored.
Namespaces, custom resource definitions, volume claims, Secrets	Deleted only when the design has a component for them.
Dependency charts	For components of non-Kubernetes models, Meshery uninstalls the model’s Helm chart: `Undeployed dependent helm chart for <component>`. This can remove custom resource definitions and operators that other designs on the cluster use.
Missing namespace	Created before the delete is attempted.

Meshery always processes dependency charts on undeploy. The Include Dependencies checkbox in the dry-run step does not change this. Before you undeploy a design that uses custom resource models, check what else on the cluster depends on its definitions.

Read the results 🔗

Success raises the event undeployed design '<name>'. at success severity. Failure raises Failed to undeploy design '<name>'. at error severity, with an error card. The error codes match those in Deploy a Design. The deployment count of the design is not decremented.

In Operator mode, the resources leave the live view once MeshSync reports their deletion.

Limits 🔗

There is no undeploy-type dry run outside the stepper.
Deleting a design does not undeploy it. Undeploy first if you want the resources gone. See Delete a Design.
As with deploy, the Finish step waits for a server event. If the request fails before the server raises one, the step keeps spinning with no error. See Deploy a Design.