You trigger a Kubernetes upgrade, and one by one every worker is drained and replaced under your running workloads. No page, no outage, if you built for it. That roll, plus the self-healing that swaps out any node that goes unhealthy on its own, is the single fact that should decide how you build.

You run standard Kubernetes workloads on Syself Autopilot, with one rule shaping all of it: a pod is never guaranteed to stay on the node it started on. A minor-version upgrade you start rolls every node in turn, and self-healing replaces any node that fails, so node replacement is routine here, not an incident. That does not make your application fragile. It makes one set of settings non-optional for anything serving real traffic: more than one replica, health probes, a PodDisruptionBudget, and a spread rule. Get that baseline right and the churn is invisible to your users.

Everything else on this tab assumes you have that in place. So start there.

## Start with the production baseline

Whatever you plan to run, begin at [Run a production-ready workload](/docs/hetzner/apalla/workloads/production/run-a-production-ready-workload). It wires every drain-survival setting into a single working example, so you can see how the pieces fit before you split them apart.

The rest of that sub-topic then takes each setting on its own, one page at a time: [health probes](/docs/hetzner/apalla/workloads/production/health-probes) so the platform knows when a pod is really ready, [resource requests and limits](/docs/hetzner/apalla/workloads/production/resource-requests-and-limits) so the scheduler can place it and the kubelet can protect it, [PodDisruptionBudgets](/docs/hetzner/apalla/workloads/production/pod-disruption-budgets) so a drain can never take down more replicas than you allow, and [graceful shutdown](/docs/hetzner/apalla/workloads/production/graceful-shutdown) so a pod finishes its in-flight work before it goes. Read the example first; use the individual pages when you want the reasoning.

## What you inherit for free

Part of the safety net is already strung for you. You get these without writing a line of configuration:

- **A best-effort spread of your pods across nodes and cloud zones**, applied even to pods that carry no spread rule of their own. It never blocks scheduling, so it costs you no capacity, but it is deliberately loose, and a workload that must survive a single node loss still needs a tighter rule you set yourself.
- **Namespace guardrails that take effect the instant you set them**, because LimitRanger and ResourceQuota admission are already wired in. Define a quota and it is enforced on the next pod, with nothing to install.
- **NUMA-aligned placement on bare-metal nodes** for pods that qualify, so memory-bound and latency-sensitive workloads sit close to the CPUs serving them, when the topology fits.
- **A GPU stack that ships with the hardware.** On supported cards the driver, CDI, and device plugin arrive with the node. You schedule against the GPU, not against a driver install.

## Where to go next

- [Placement and scheduling](/docs/hetzner/apalla/workloads/placement/steer-workload-placement)
- [Scaling](/docs/hetzner/apalla/workloads/scaling/horizontal-pod-autoscaler)
- [Stateful workloads](/docs/hetzner/apalla/workloads/stateful/run-a-statefulset-with-storage)
- [Batch and jobs](/docs/hetzner/apalla/workloads/batch/run-jobs)
- [Specialized workloads](/docs/hetzner/apalla/workloads/specialized/run-gpu-workloads)
- [Secure workloads](/docs/hetzner/apalla/workloads/secure/set-security-contexts)
- [Configuration and delivery](/docs/hetzner/apalla/workloads/delivery/deploy-apps-from-git-argo-cd)

One boundary worth drawing before you start. This tab is about running the workload and isolating it at the workload level: security contexts, user namespaces, and secure runtimes all live here, under [Secure workloads](/docs/hetzner/apalla/workloads/secure/set-security-contexts). The cluster's wider posture lives in the [Security](/docs/hetzner/apalla/security/security-architecture) tab: network policy, Pod Security enforcement, admission control, and the zero-trust model. This tab hardens the pod; that tab locks down the network around it.