{#if release === stack.latest}

<VersionScopeNotice guide="update">

You are seeing the documentation for Kubernetes <code>1.36</code>, Cluster Stack release <code>hetzner-apalla-1-36-v6</code> — the newest release Syself Autopilot offers right now.

If your cluster is already on this release, there's nothing to do.

Not on this release? Documentation is tailored to each Cluster Stack release. Pick your cluster's actual version to jump straight to the guide that applies to it:

</VersionScopeNotice>

## Not sure which Cluster Stack release your cluster is on?

If you are unsure which Cluster Stack release your cluster is currently running, do the following:

<Steps>

<Step>Check in your cluster</Step>

Run these commands against the Syself Autopilot management cluster, not the workload cluster.

To check one cluster:

```console
$ kubectl get cluster <cluster-name> -n <namespace> \
  -o jsonpath='{.spec.topology.classRef.name}{"\n"}'
```

The command returns the Cluster Stack release name:

```console vars
hetzner-apalla-1-36-v3
```

The name includes the provider, stack, Kubernetes minor version, and Cluster Stack release. The final `vN` segment identifies the Cluster Stack release.

To check every cluster:

```console
$ kubectl get clusters -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,CLUSTER:.metadata.name,CLUSTERSTACK:.spec.topology.classRef.name,KUBERNETES:.spec.topology.version'
```

**If the management cluster serves `cluster.x-k8s.io/v1beta1`**:

If the Syself Autopilot management cluster serves `cluster.x-k8s.io/v1beta1` instead of `v1beta2`, use `spec.topology.class` instead of `spec.topology.classRef.name`.

To check one cluster with `cluster.x-k8s.io/v1beta1`:

```console
$ kubectl get cluster <cluster-name> -n <namespace> \
  -o jsonpath='{.spec.topology.class}{"\n"}'
```

To check every cluster with `cluster.x-k8s.io/v1beta1`:

```console
$ kubectl get clusters -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,CLUSTER:.metadata.name,CLUSTERSTACK:.spec.topology.class,KUBERNETES:.spec.topology.version'
```

<Step>Match the docs to your version</Step>

If either one doesn't match <code>hetzner-apalla-1-36-v6</code> / <code>1.36</code>, switch the docs to your cluster's actual version using the picker below:

<VersionDropdown size="lg" class="max-w-fit mt-4" />

An update guide scoped to that version will show you the real update steps.

</Steps>

## Explore further

<Card title="Inspect this release" href="/versions/{stack.latest.minor.version.replace('.', '-')}/v6#stack-contents-heading">

Exactly which components and versions <code>hetzner-apalla-1-36-v6</code> ships.

</Card>

<PlanYourUpgrades compact />

{:else if release === minor.latest}

Right now you are on the latest ClusterStackRelease available for Kubernetes <code>1.36</code>.

## Ready to move to a newer Kubernetes version?

To move from Kubernetes <code>1.36</code> toward Kubernetes <code>1.36</code>, follow [Upgrading the cluster to a new Kubernetes version](/docs/hetzner/apalla/clusters/upgrades/upgrade-to-a-new-kubernetes-version).

## Your other options

- **Update an older ClusterStackRelease**: If your cluster uses an older release, select its actual version in the picker at the top of this page. The version-specific guide will show the relevant update steps.

- **Check your cluster's version**: If you are not sure which Kubernetes version and Cluster Stack your cluster uses, [check the Kubernetes version and Cluster Stack](/docs/hetzner/apalla/clusters/configure/how-to-check-the-kubernetes-version-and-stack).

{:else}

A Cluster Stack release bundles the Kubernetes patch version, the in-cluster components, and the node image under one version number, tested together before any node boots. Updating within a Kubernetes minor moves your cluster from one release to the next on that same minor, here from <code>hetzner-apalla-1-36-v3</code> to <code>hetzner-apalla-1-36-v6</code>. The Kubernetes minor itself does not change.

## Before you update

- See what your current release ships and where it stands on security. The <Button class="p-0 m-0 text-base" variant="link" href="/versions/{minor.version.replace('.', '-')}/v3">Cluster Stack Release</Button> for <code>hetzner-apalla-1-36-v3</code> lists every component in it, with its CVEs and how each one is assessed, so you can tell what the newer release changes before you move.
- Run the [pre-flight checks](/docs/hetzner/apalla/clusters/upgrades/plan-maintenance-and-prechecks).

{#if release.hasArmImages}

## Check for ARM-based nodes

If your cluster isn't running ARM-based nodes, skip this step.
ARM-based (CAX) nodes are temporarily not supported. If your cluster has any, the update will fail unless you migrate them to x86 nodes first — see [Migrate ARM servers to x86 in your cluster](/docs/hetzner/apalla/servers-and-nodes/provision/migrate-arm-to-x86) for instructions.

{/if}

## Editing the cluster object

{#if upgrade.toMinorLatest[0]?.kubernetes === minor.latest.kubernetes}

In this case, you only need to update one version. Change your cluster's <code>spec.topology.classRef.name</code> to <code>hetzner-apalla-1-36-v6</code> and <code>spec.topology.version</code> to <code>v1.36.4</code>, as shown below. Both belong to the same release — set them together and you're done.

> [!NOTE]
> The manifest below uses `cluster.x-k8s.io/v1beta2`, the current API version for cluster manifests. `v1beta1` keeps working for now, but Syself recommends migrating: see [Migrate a manifest to v1beta2](/docs/hetzner/apalla/clusters/upgrades/migrate-a-manifest-to-v1beta2).

```yaml vars persistBlur title="cluster.yaml"
apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  topology:
    classRef:
      name: hetzner-apalla-1-36-v6
    version: v1.36.4
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: workeramd64hcloud
          name: md-0
          replicas: 1
          failureDomain: nbg1
          variables:
            overrides:
              - name: workerMachineTypeHcloud
                value: cpx42
    variables:
      - name: region
        value: nbg1
      - name: controlPlaneMachineTypeHcloud
        value: cpx42
```

{:else}

This update spans several releases. Change your cluster's `spec.topology.classRef.name` and `spec.topology.version` one release at a time, following the steps below.

<Timeline />

{/if}

This can be achieved either by editing the resource inside the management cluster, or by updating it in your GitOps repository.

Once you apply it, the cluster rolls to the ClusterStack release you specified: new nodes come up and the old ones are removed, one at a time. This is the same node replacement that happens during routine self-healing, so a workload set up to tolerate it — replicas spread across nodes with a `PodDisruptionBudget` — rides through the roll without downtime. If your workloads are not set up that way yet, see [Prepare workloads for upgrades](/docs/hetzner/apalla/clusters/availability/prepare-workloads-for-upgrades); it applies to any node replacement, not just updates.

If you need to update to another version, wait for the current update to finish. You can check if it's done by checking the nodes in your cluster:

```console
$ kubectl get nodes
```

If you still have old nodes, this means the update is in progress. In this case, wait until the output shows only new nodes.

## Moving to a new Kubernetes minor instead of a new release on your current one?

See [Upgrading the cluster to a new Kubernetes version](/docs/hetzner/apalla/clusters/upgrades/upgrade-to-a-new-kubernetes-version).

## Not sure which release your cluster is on?

[Check the Kubernetes version and Cluster Stack](/docs/hetzner/apalla/clusters/configure/how-to-check-the-kubernetes-version-and-stack) for your cluster.

{/if}