Architecture

Syself builds your whole Kubernetes cluster as one unit. The node operating system, the cluster topology, and every in-cluster component are pinned to exact versions and tested together under one version number.

You describe the cluster you want as one Kubernetes object. Syself provisions the Hetzner servers, writes an immutable operating system to them, and keeps what runs matched to what you asked for.

This page explains why Syself builds every layer, how one Cluster object becomes running nodes, and where the line falls between what Syself operates and what you own.

Building a cluster from separate parts#

You can assemble a cluster from separate parts. The work is keeping that exact combination running through every upgrade.

The parts are a general-purpose Linux, a CNI for pod networking, a CSI driver for storage, a control plane, and a stack of cluster components for DNS, metrics, and cloud integration. The CNI is the plugin that gives pods their network. The CSI driver connects storage to pods. Each part works on its own.

The trouble starts when you upgrade. Upgrades break where the parts meet: a version of the CNI that no longer matches the kernel, a CSI driver that expects a newer control plane. When a break like that happens, it is rarely clear whose job the fix is.

Most systems make it worse by building a node on first boot. They install packages, run cloud-init, and apply scripts while the machine comes up. Building a node this way causes problems:

• Build two machines with the same steps and they still drift apart the moment a package or download changes.
• A machine that sets itself up at boot has a window where someone can tamper with it, and no clean proof of what it ended up running.
• The scripts run once. After that, nothing pulls the machine back to a known state when it drifts.

Syself removes that step. Like a phone that installs one complete firmware image the vendor already tested, Syself builds and tests the whole cluster before any node boots.

The cluster stack: one versioned unit#

That complete image is the cluster stack: the whole pinned unit, given a name and released together as one version.

Cluster stacks explains what each layer holds and how a release gets its version number.

From a Cluster object to running nodes#

Syself pins and tests each release before you ever use it, and locks it to one hash-pinned version with no latest tag that changes under you (the cluster stacks page has the test and versioning detail). The rest of this section is what happens once you apply a Cluster object against that release.

You describe the cluster once, as data: how many control-plane nodes, which worker pools, which machine types, the region, and the stack version. The Cluster object lives on the management cluster, a Kubernetes cluster Syself runs for you. It is a plain Kubernetes resource, so your usual tools work on it: manage it with kubectl and your GitOps pipeline. There is nothing Syself-specific to learn, and Syself recommends keeping it in Git.

Syself's controllers build the running cluster to match. They provision the Hetzner servers and write an immutable operating system to each one. The operating system cannot change once it is built, so there is nothing to patch on a running node and nothing drifts. Syself verifies each image against a known hash before boot, so a corrupted image fails the check and never joins the cluster. The control-plane container images ship inside the node image, so a booting node pulls no images and downloads no packages.

Scaling and upgrades use the same reconcile loop: raise a replica count or point the cluster at a newer stack version, and the controllers close the gap. An upgrade brings in fresh nodes built from the next release; nothing is patched in place. Declarative cluster management covers how the reconcile loop works.

See Management and workload clusters for the two-cluster model.

Why Syself builds every layer#

When something below your workloads breaks, one team owns the fix, including breaks that show up where two layers meet. With separate vendors, an OS vendor, a Kubernetes distribution, and a set of glue scripts, no one clearly owns a problem between two of them.

The core pieces are Syself's own. Syself Linux is the node operating system, and Syself's provisioning writes it to each server. KubeGate sits in front of the Kubernetes API server and controls access to it, and the syself-agent watches node health. Platform components covers both.

Healing and upgrades run on open-source controllers. Syself operates them and adds its own node-repair logic.

Networking has many moving parts that must agree. Syself tests them together, so a node that reaches Ready has networking, storage, and cloud integration that already work. See Networking for how the pieces fit.

Shared responsibility: what Syself operates, what you own#

The servers and the Hetzner account are yours. So is the workload layer: your manifests, Helm charts, kubectl workflows, and data are standard upstream Kubernetes. The platform layer underneath is Syself's to run. What you own, what Syself manages, and compliance maps this line onto compliance frameworks, and Minimal provider dependency covers how far the workload layer carries to another cluster.

Provider support#

Today Syself Autopilot runs on Hetzner, and the Hetzner integration is complete. The design is provider-independent: the pieces that talk to the provider are isolated from the rest, so more providers can be added, and more are planned. This goes back to where Syself started, in the German government funded Sovereign Cloud Stack project. Minimal provider dependency covers what Syself takes from the provider and how the isolation works.

Next, read cluster stacks to see inside the versioned unit itself.