Syself Autopilot is fully managed Kubernetes on your own Hetzner servers. You declare a cluster as one Kubernetes object and apply it to the Kubernetes API. Syself builds the cluster, keeps it healthy, and upgrades it. Your applications run in standard upstream Kubernetes, on machines rented in an account you own.

The usual managed Kubernetes works the other way around. You rent a control plane that runs inside the provider's cloud, on their servers and their account. Running the node operating system, patching it, and scheduling upgrades stay your problem, and the longer you stay, the more the provider's private APIs and add-ons lock you in. Syself Autopilot divides the work the other way: Syself runs operations, and you keep ownership.

Two clusters: management and workload#

A Cluster object is a declarative Kubernetes custom resource where you describe the cluster you want. You apply this object to a management cluster Syself runs. The management cluster never runs your applications. Your applications run in separate workload clusters that keep serving even when the management cluster is unreachable. Management and workload clusters covers the split.

One tested stack#

Everything below your workloads comes as one cluster stack: the node operating system, the cluster topology, and the in-cluster components. The whole stack shares one version number. Syself tests it as a unit before any node boots, so the versions of the OS, the topology, and the components you run have already been checked to work together. Architecture shows how the pieces fit; Cluster stacks describes what is in the versioned bundle.

What is yours, what is Syself's#

The servers, the Hetzner account, and the data on the cluster are yours. Everything below your workloads is Syself's to build and run: the node OS, the gateway in front of every API server, and the controllers that provision, heal, and upgrade. Your workload layer stays portable. Manifests, Helm charts, the Kubernetes API, and data are standard upstream Kubernetes, so they move to any conformant cluster unchanged. What you own, what Syself manages, and compliance goes through the split item by item.

How to read these pages#

Start with the foundations: the two clusters, the versioned stack, and the one object you declare. Every other page builds on them. The operations pages show how the platform keeps clusters running and up to date without patching. The platform-internals pages go deep on the node OS, the network, and storage. Read the ownership pages last, because the case for cost, security, and sovereignty makes more sense once you know what the platform actually runs: the node OS, the controllers, and the network.

Foundations

• Architecture : how the pieces fit at a high level, and where to read each part in full.
• Management and workload clusters : the two-cluster model, and why workload clusters keep serving when the management cluster is unreachable.
• Inside a workload cluster : what runs on a control-plane node, what runs on a worker, and how the parts connect.
• Cluster stacks : the node OS, topology, and in-cluster components as one versioned bundle, and how you control which release a cluster follows.
• Declarative cluster management : your whole cluster as one Kubernetes object that ordinary tooling reconciles and keeps free of drift.

Operations

• The node lifecycle : a node is built before its first boot and runs an immutable operating system, so there is nothing to patch on a running node and nothing drifts. When a node must change, Syself replaces it.
• Fast, reliable provisioning : a bare Hetzner server becomes a Ready node with no package downloads and no config scripts at boot.
• Self-healing and node replacement : an on-node agent fixes what it can in place, and nodes that cannot recover are replaced automatically.
• Updates and upgrades : moving a cluster to a new tested stack version while the control plane stays available and pools roll one node at a time.
• Backup and disaster recovery : what survives a node replacement, what Syself backs up, and what stays your job.
• The observability model : what every cluster ships, and what you bring, so no vendor holds your telemetry.

Platform internals

• Syself Linux : the node OS is minimal and immutable, so nothing drifts and you can check that a node runs exactly what Syself shipped.
• KubeGate, the node agent, and the tunnel : the proprietary pieces Syself runs on top of Kubernetes, and what each one does.
• Networking and Cilium : one network layer for pod networking, load balancing, policy, and the default-deny host firewall.
• The storage model : where data lives and how it behaves through a node replacement.
• Bare metal, cloud, and accelerators : both become the same immutable node; what differs is how a machine is obtained and when each fits.
• Minimal provider dependency : the small set of Hetzner features the platform actually needs.

Ownership

• Run your own services : Kubernetes-first, not a catalog of managed services you rent.
• Run it yourself, or with help : from fully self-run to fully managed, and you can change your mind per service.
• The economics of owning vs renting : the cost numbers behind the model.
• What you own, what Syself manages, and compliance : the shared-responsibility line, item by item, and how it maps onto compliance frameworks.
• The security model : why nodes run safely on the public internet with no private network to set up.
• Sovereignty and data residency : your own account, your keys, and the region you pick.
• The Kubernetes layer for Sovereign Cloud Stack : where Syself Autopilot fits the European sovereignty effort.

Where to go next#

If you are evaluating, start with the pages below: what you would be running, how the economics compare, and how it is secured.

• Architecture
• Owning vs renting
• The security model