Kubernetes works by declaration. You declare the state you want, and controllers build it and hold it there. You tell a Deployment how many replicas to keep, and if one dies Kubernetes starts another. You never run the steps yourself. Syself Autopilot extends that model to the whole cluster and the machines under it. You declare the cluster you want, and Syself builds it and keeps the running cluster matching what you declared.

Your cluster is one object#

Your whole cluster becomes one standard Kubernetes object. The object records only what you want: which cluster stack and version to run, the Kubernetes version, how many control-plane nodes, which worker pools, and the settings that control them, like region and machine types. It is stored on the management cluster , the Kubernetes cluster Syself runs to manage your workload clusters. The cluster stack it names decides which values it accepts.

Everything you do to the cluster is an edit to this one object. To upgrade, you change the Kubernetes version or the cluster stack version. To scale, you change a replica count. You can write, apply, and edit the object as a plain Kubernetes resource. A change only lasts if you make it here.

Syself writes the node config from your values#

You set a value on the object, and the cluster stack writes the real config files on the right machines. You never edit those files yourself. Turn on etcd encryption, and the cluster stack writes the provider config onto the control-plane nodes. Set the cluster network ranges, and they are written to the file the network layer reads. The full list of values you can set is in the cluster variables reference .

The object is an open standard#

Your cluster is described in an open, standard format that any Kubernetes tooling can read. It describes a whole cluster the same declarative way Kubernetes describes workloads. Syself adds its own cluster templates, node OS, provisioning pipeline, and healing controllers underneath, but what you touch stays a standard Kubernetes object. Your workloads run on standard upstream Kubernetes, so your manifests, Helm charts, and data move with you unchanged.

Syself fixes drift automatically#

Most infrastructure tools only act when you run them. Terraform runs once when you type apply, then stops watching. But things keep changing: a machine dies, a disk fills, someone edits a setting on a server. Now the running cluster and the file that describes it say two different things. That gap is called drift. With a run-once tool, the drift sits there until a person notices and runs the tool again. Syself Autopilot does not wait for a person; it fixes the gap itself.

If you have watched a Deployment keep its replicas alive, you already know this. A Cluster object that asks for a set of control-plane nodes of a chosen machine type in a chosen region works the same way. Syself's controllers keep watching what the cluster really looks like, compare it to what you asked for, fix any gap, and check again. The same loop handles scaling, upgrades, and a failed node.

A failed node is replaced with a fresh one from the same immutable image . The node's operating system cannot change after Syself builds it, so nothing on a running node drifts and there is nothing to patch.

Syself does not watch your Hetzner account. If you turn a server off in the Hetzner website, Syself does not see that you did it, only the result: the node stops working, so Syself replaces it. So always work in Kubernetes, in the Cluster object on the management cluster, never in the Hetzner website.

Hand edits inside the cluster are treated the same way. A setting you change over SSH on a node, or straight on a generated object under the Cluster, is drift. The next reconcile reverts it, or replaces the node under it. The reconcile makes the running cluster match the object again.

The controllers underneath#

You write one object. Underneath, Syself's controllers expand your declaration into the many objects a running cluster is really made of, each with its own controller, all on the management cluster. You almost never see them and do not need to: you work with the object at the top, and only look deeper when a cluster gets stuck during bring-up, where Syself's tooling points you at the stage that has not finished. Cluster API resources lists the objects your Cluster expands into.

Keeping the object in Git#

Treat the object like a workload: it is plain YAML, so keep it in Git next to your application manifests. Every cluster change becomes a pull request, the Git history is your change log, and the management cluster's audit log records every operation against the object, so you get change control and an audit trail from tools you already use. GitOps with Syself Autopilot covers setting this up with Argo CD or Flux.

The object points at a cluster stack , covered on the next page.