With Syself Autopilot you manage your clusters through the **management cluster**: Syself's control surface, and the one piece Syself runs and hosts for you. It exposes a Kubernetes API, so you declare the cluster you want the same way you declare any Kubernetes object, using the `kubectl` and GitOps you already know.

The **workload cluster** is what Syself builds from that declaration: a complete Kubernetes cluster on your own Hetzner servers, with its own control plane and its own worker nodes. Your applications run here, and your `kubectl` talks straight to it, like any Kubernetes cluster you have used before. ([Inside a workload cluster](/docs/hetzner/apalla/concepts/foundations/inside-a-workload-cluster) shows what runs in one.)

## You declare, Syself builds

The object defines the cluster you want: its Kubernetes version, how many nodes, which machine types, and which region. Syself's controllers read it and build a matching workload cluster on your Hetzner servers, then keep it that way: when a machine fails they replace it, and when you change the object they roll out the change. How that reconciling works is [declarative cluster management](/docs/hetzner/apalla/concepts/foundations/declarative-cluster-management).

So you work in two places, depending on what you want to change:

- To change the **shape** of the cluster, its version, node counts, machine types, or region, you edit the object on the management cluster.
- To change **what runs inside** the cluster, your applications, you use the workload cluster's own API, exactly like any Kubernetes cluster.

```mermaid
flowchart LR
  YOU(["You"]):::you
  subgraph MC["Management cluster: Syself runs this"]
    D["The object:<br/>your cluster's shape"]:::platform
    C["Syself's controllers:<br/>build, heal, upgrade"]:::platform
    D --> C
  end
  subgraph WC["Workload cluster: yours, on your servers"]
    CP["Control plane"]:::platform
    W["Worker nodes: your apps"]:::platform
  end
  YOU -->|"edit the object"| D
  YOU -->|"deploy apps"| WC
  C -->|"builds and keeps it running"| WC
```

## Your workload cluster stands on its own

Your workload cluster runs its own control plane, etcd, networking, and storage on your own Hetzner servers. It does not depend on the management cluster to keep running.

It serves traffic, schedules pods, and answers your `kubectl` whether or not the management cluster is reachable. If the management cluster goes down for maintenance or loses its network, your applications keep serving. What pauses is the automation: building or scaling nodes, upgrades, and automatically replacing a failed machine. All of that resumes once the management cluster is back.

| Keeps working on its own                 | Waits for the management cluster         |
| ---------------------------------------- | ---------------------------------------- |
| Serving traffic and scheduling your pods | Creating or scaling nodes                |
| Your control plane, `kubectl`, and Helm  | Upgrades and version rollouts            |
| Your ingress, networking, and storage    | Automatically replacing a failed machine |

So a problem in Syself's operations layer never takes your applications down; at most, it delays a change until the layer is back.