The lifecycle of a cluster covers keeping it healthy, updating and upgrading it, backing it up, and replacing nodes that fail. This page lists what you do at each stage and links to the guide for each step.

## Keep the cluster healthy

Check regularly that every node is `Ready`, especially the control plane nodes, and that no certificate requests are stuck. See [Maintain a cluster](/docs/hetzner/apalla/clusters/upgrades/maintain-a-cluster).

## Update and upgrade on your schedule

An update moves your cluster to a newer Cluster Stack release on the same Kubernetes minor. An upgrade moves it to the next minor. Both replace your nodes one at a time.

Syself Autopilot has no maintenance window scheduler, and nothing updates or upgrades a cluster on its own. A rollout starts when you apply the change, so pick a time when your team can watch it. Take each release as it ships, so every step stays small.

- [Update within a version](/docs/hetzner/apalla/clusters/upgrades/update-within-a-version)
- [Upgrade to a new Kubernetes version](/docs/hetzner/apalla/clusters/upgrades/upgrade-to-a-new-kubernetes-version)
- [Migrate a manifest to v1beta2](/docs/hetzner/apalla/clusters/upgrades/migrate-a-manifest-to-v1beta2), if your `Cluster` manifests still use `v1beta1`
- [Cluster upgrades](/docs/hetzner/apalla/concepts/operations/cluster-upgrades), for background on how a rollout replaces your nodes

## Back up your cluster

Syself Autopilot heals your infrastructure, but it does not back up your data. Keep your manifests in Git and back up your data. See [Back up your cluster regularly](/docs/hetzner/apalla/clusters/upgrades/maintain-a-cluster#back-up-your-cluster-regularly) and [Backup and disaster recovery](/docs/hetzner/apalla/concepts/operations/backup-and-disaster-recovery).

## When a node fails

When a node fails a health check, Syself Autopilot first attempts to recover it by rebooting. If the node is still unhealthy after the reboot, it replaces the node. It does not handle every failure, for example broken hardware, so alert on the [node conditions](/docs/hetzner/apalla/servers-and-nodes/access/node-problem-detection-and-conditions) to catch the rest. See [Self-healing and node replacement](/docs/hetzner/apalla/concepts/operations/self-healing-and-node-replacement) and [Machine health checks and remediation](/docs/hetzner/apalla/servers-and-nodes/maintenance/machine-health-checks-and-remediation).

## Keep your workloads available

When a node is replaced, its pods are rescheduled onto other nodes. Configure your workloads to remain available during this process and avoid delaying the node drain. A PodDisruptionBudget can hold a drain only up to the drain timeout. After that the drain proceeds and the pods go with the node. See [Survive node drains](/docs/hetzner/apalla/workloads/production/survive-node-drains) for the settings that keep a workload serving through a drain, and the [Production readiness checklist](/docs/hetzner/apalla/workloads/production/production-readiness-checklist) for the rest.