Deleting a cluster is deleting one `Cluster` object, and Syself Autopilot removes the servers it created. The care is in the order and in the things that outlive the cluster: retained volumes and load balancers keep billing, and data on a retained volume is gone if you delete the wrong thing. Do it in the safe order.

## Before you delete

Three things need attention first, because deleting the `Cluster` does not clean them up the way you might expect:

- **Retained PersistentVolumes.** Every StorageClass on Syself Autopilot uses `reclaimPolicy: Retain`, so the Hetzner Cloud volume behind each PV stays after the cluster is deleted, even if you delete the PVC. The PVCs and PVs themselves are deleted with the cluster. If you want to use the data again in a new cluster, note the volume IDs first. To remove a volume, set its PV's reclaim policy to `Delete` before you delete the PVC, or delete the volume in the Hetzner Console after the teardown.
- **`LoadBalancer` Services.** Each one created a Hetzner load balancer that bills separately and is not always torn down cleanly when the cluster goes. Delete these Services first.
- **In-flight work.** A teardown does not drain nodes gracefully, so anything mid-write can be cut off. Stop or finish important work before you start.

## The safe order

<Steps>
<Step>Remove DNS and LoadBalancer Services</Step>

Delete every `type: LoadBalancer` Service so its Hetzner load balancer is released, and remove the DNS records that point at the cluster, so nothing keeps resolving to soon-dead addresses.

```console
$ kubectl delete svc --all-namespaces --field-selector spec.type=LoadBalancer
```

<Step>Handle retained volumes</Step>

For any PV whose data you want to keep, record the Hetzner volume ID first. For data you do not need, set the PV's reclaim policy to `Delete`, stop the workload that uses the PVC, then delete the PVC, so the volume is removed with it:

```console
$ kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
$ kubectl delete pvc <pvc-name> -n <namespace>
```

<Step>Delete the Cluster object by name</Step>

Delete the specific `Cluster`, by name, in the management cluster. Do not `kubectl delete -f cluster.yaml` if that file holds other objects, and never delete by a broad selector that could match another cluster.

```console
$ kubectl delete cluster mycluster -n my-organization
```

<Step>Watch the teardown</Step>

```console
$ kubectl get machines -n my-organization -w
```

The Machines move to `Deleting` and disappear as their servers are removed. Remember there is no graceful drain on teardown; the nodes go.

</Steps>

## What is cleaned up, and what is not

Deleting the `Cluster` removes the control-plane and worker Machines and the servers behind them, the control-plane load balancer, and the cluster's own infrastructure objects. It does **not** remove: `Retain`-policy PVs and their Hetzner volumes, load balancers from `LoadBalancer` Services you did not delete first, or anything you created directly in your Hetzner account outside the platform. Check the Hetzner console after a teardown to confirm no volumes or load balancers are left billing.

## A stalled delete

If Machines sit in `Deleting` and do not clear, a finalizer is usually waiting on something, a volume still attached, a load balancer the platform cannot remove, or a Hetzner API error. Read the events on the stuck `Machine` and `Cluster` objects (`kubectl describe`) for what the finalizer is waiting on, clear that dependency, and the delete proceeds. If it stays stuck with no clear cause, get support rather than force-removing finalizers, which can orphan billing resources.

## Related

- [Throwaway clusters](/docs/hetzner/apalla/clusters/workflows/throwaway-clusters): spin up and tear down short-lived clusters cleanly.