syself@demo:~$ kubectl apply -f cluster.yaml cluster.cluster.x-k8s.io/mycluster created
Instead of relying on static tools like Terraform or Ansible, Syself is built as a system that actively communicates with your infrastructure provider's APIs. It not only provisions Kubernetes clusters—but understands their real-time state, fixes issues instantly, and keeps everything aligned with your desired outcome. You define what you want, and the platform takes care of the rest.

From initial creation to upgrades and failure recovery, Syself continuously monitors and adjusts your clusters without manual intervention.
Manage multiple environments (like dev, stage, prod) with isolated definitions, version control, and repeatable infrastructure patterns.
Syself doesn’t stop at provisioning. It maintains operational state over time. If a node fails or something drifts, the platform reacts instantly to correct it.
Syself communicates directly with cloud provider APIs—no scripts or middlemen. This enables real-time provisioning, state checks, and automated problem resolution.

Define your cluster using manifests, just like you would a Pod or Deployment. Everything is a Kubernetes object—fully compatible with kubectl, GitOps, and CI/CD.
Syself supports dynamic node scaling natively. As workloads grow or shrink, the system adjusts capacity without human input.
At the heart of Syself is a simple idea: you shouldn’t have to write long scripts or manage low-level steps. Instead, define the cluster setup you want, and let Syself handle the rest.
This cluster definition becomes a Kubernetes-native object—just like your pods or deployments. And because Syself uses Kubernetes to manage Kubernetes, you can interact with your infrastructure using the same tools you already know: kubectl, GitOps, CI/CD pipelines, even the Kubernetes API itself.
yaml_files
apiVersion: cluster.x-k8s.io/v1beta2kind: Clustermetadata: name: cluster-stagespec: topology: classRef: name: hetzner-apalla-1-36-v1 version: v1.36.3 controlPlane: replicas: 3 workers: machineDeployments: - class: workeramd64hcloud replicas: 6 failureDomain: nbg1 variables: overrides: - name: workerMachineTypeHcloud value: cpx31 variables: - name: region value: nbg1 - name: controlPlaneMachineTypeHcloud value: cpx31
reconciliation loop
yaml_files
apiVersion: cluster.x-k8s.io/v1beta2kind: Clustermetadata: name: cluster-stagespec: topology: classRef: name: hetzner-apalla-1-36-v1 version: v1.36.3 controlPlane: replicas: 3 workers: machineDeployments: - class: workeramd64hcloud replicas: 6 failureDomain: nbg1 variables: overrides: - name: workerMachineTypeHcloud value: cpx31 variables: - name: region value: nbg1 - name: controlPlaneMachineTypeHcloud value: cpx31
reconciliation loop
Feature benefits
Syself integrates declarative principles deeply across the entire platform. Here’s how it works:
Keep your environments aligned. From dev to production, Syself enforces the same structure, reducing surprises and bugs.

Every cluster starts from a clear, versioned definition. You can recreate, duplicate, or scale environments with confidence.
Whether you manage one cluster or hundreds, Syself makes scaling effortless with built-in automation and environment awareness.

Declarative systems can automatically reconcile drift between the current and desired state. Learn more about how Self-healing works on Syself

Use the tools you already know—kubectl, GitOps, CI/CD pipelines—thanks to Syself’s Kubernetes-native design.
Scaling becomes a matter of changing a value, manage hundreds of clusters without misconfigurations. Changes propagate consistently and safely.

Syself replaces brittle scripts with intelligent software. It’s not just faster to act—it’s smarter. You get a system that continuously enforces your cluster definitions and keeps everything running as it should, even during failure scenarios.
This approach gives your teams more speed, more confidence, and fewer late-night alerts.
Syself Autopilot is a fully automated Kubernetes management platform that allows you to launch production-ready Kubernetes clusters in minutes.
Have a different question and can’t find the answer you’re looking for? Reach out to our support team and we’ll get back to you as soon as possible.
Your whole cluster is one standard Kubernetes object: the Cluster Stack and version to run, the Kubernetes version, the control-plane size, the worker pools, and settings like region and machine types. You create and edit that object through the Kubernetes API. Syself Autopilot’s controllers read it, provision the servers it describes, and keep the running cluster matching it.
Those tools act only when you run them. Terraform applies your plan once and stops watching, so a failed machine or a manual change stays in place until someone runs it again. Syself Autopilot reconciles continuously: it compares the running cluster with your Cluster object, fixes any gap, and checks again. The object itself is the source of truth, so there is no separate state file to keep in sync.
Any tool that talks to the Kubernetes API. Apply and edit the Cluster object with kubectl, keep it in Git and roll it out with Argo CD or Flux, or change it from your CI/CD pipeline. You use the same tooling for your clusters that you already use for your workloads.
Both count as drift, and Syself Autopilot corrects it. A failed node is replaced with a fresh one built from the same immutable node image. A setting changed over SSH, or directly on an object generated from your Cluster, is reverted on the next reconcile. Make every change in the Cluster object, not in your infrastructure provider’s console, so the change lasts.
Give each environment its own Cluster object, keep them in Git, and point them at the same Cluster Stack version. The same Cluster Stack version rebuilds the same cluster, so environments differ only in the values you set, such as node counts or machine types. Changes move between environments as pull requests, and the Git history records who changed what.
Yes. Syself Autopilot integrates with the Kubernetes Cluster Autoscaler for Cluster API, which runs inside your workload cluster. It adds nodes when pods are pending for lack of capacity and removes nodes that sit underused. You can also scale by hand: change the replica count of a worker pool in the Cluster object.
No. Your cluster is described in the open Cluster API format, and your workloads run on standard upstream Kubernetes, so your manifests, Helm charts, and data move with you unchanged. The Hetzner provider underneath, CAPH, is open source and maintained by Syself.