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.** A PV with `persistentVolumeReclaimPolicy: Retain` (and the Hetzner Cloud volume behind it) survives the cluster on purpose. Decide whether you want that data. If you do, record the volume IDs now; if you do not, delete the PVCs first so the volumes are removed with them.
- **`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 `Retain`-policy PV whose data you want to keep, record the Hetzner volume ID first. For data you do not need, delete the PVCs so the volumes are cleaned up.

<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.