## Introduction

Syself Autopilot builds on top of [Cluster API (CAPI)](https://cluster-api.sigs.k8s.io/), allowing you to manage Kubernetes clusters declaratively, with a clear separation between control and compute.

With Syself Autopilot, instead of interacting directly with infrastructure components, users manage Kubernetes clusters through a dedicated management cluster that orchestrates the lifecycle of workload clusters running on their Hetzner infrastructure.

This architecture separates cluster management operations from the Kubernetes clusters that run production workloads.

In this documentation, we also refer to the management cluster as the "Autopilot" or "Syself Autopilot" cluster.

## What is the management cluster?

The management cluster is the central control plane used by Syself Autopilot to provision, upgrade, scale and watch Kubernetes clusters.

It's where the platform components live. It includes the Cluster API Provider Hetzner, the Cluster Stack Operator, and many other components that are responsible for managing the lifecycle of workload clusters.

You never have to worry about running or updating this management cluster — it’s fully managed by us. It acts as the interface between you and your infrastructure. It is responsible for:

- Provisioning infrastructure
- Creating Kubernetes nodes
- Performing cluster upgrades
- Replacing unhealthy machines
- Managing cluster lifecycle operations

Users do not deploy workloads into the management cluster. Instead, it acts as the orchestration layer responsible for maintaining the desired state of workload clusters.

## What are workload clusters?

Workload clusters are the Kubernetes clusters where your applications, services, and workloads actually run.

Each workload cluster is provisioned on your Hetzner infrastructure and contains its own:

- Kubernetes API server
- Control plane nodes
- Worker nodes
- Networking components
- Storage integrations

Because workload clusters are isolated from the management cluster, cluster operations can be performed independently without affecting other environments or clusters.

This separation also improves operational resilience. Issues affecting a workload cluster do not impact the management cluster or other workload clusters managed by Syself Autopilot.

## Why separate management and workload clusters?

Separating management and workload clusters is a core design principle of Cluster API and Syself Autopilot.

This architecture provides several operational advantages.

### Declarative cluster lifecycle management

Clusters are managed using Kubernetes resources and reconciliation loops instead of imperative infrastructure tooling.

This enables repeatable and automated operations for:

- Cluster creation
- Kubernetes upgrades
- Scaling
- Node replacement
- Self-healing

### Improved operational resilience

Because the management cluster is isolated from production workloads, infrastructure automation remains available even if a workload cluster experiences failures or instability.

### Multi-cluster management

A single management cluster can orchestrate multiple workload clusters across different environments, regions, or teams.

This makes it easier to standardize Kubernetes operations at scale.

### Infrastructure abstraction

Users interact with Kubernetes-native resources instead of directly managing infrastructure provisioning details.

This simplifies cluster operations while still allowing workload clusters to run on dedicated Hetzner infrastructure.

## What this means in practice

When using Syself Autopilot, most cluster operations are performed declaratively through Kubernetes resources.

For example, users can:

- Create new Kubernetes clusters
- Upgrade Kubernetes versions
- Scale node pools
- Configure infrastructure settings

without manually provisioning or replacing servers themselves.

Syself Autopilot continuously reconciles the desired cluster state and automates the underlying infrastructure operations.