Security patches and reliability fixes for the Kubernetes 1.35 line, delivered automatically. Newer Kubernetes capabilities are waiting on the lines above when you're ready to move.
Security patches and reliability fixes for the Kubernetes 1.34 line, delivered automatically. Newer Kubernetes capabilities are waiting on the lines above when you're ready to move.
What’s a Cluster Stack?
A Cluster Stack pins everything your cluster runs to one tested release: the Kubernetes version, the node image,
and the in-cluster components like CNI and DNS. Syself builds and tests them together, so your team never has to check hundreds of moving parts by hand.
Each stack fits the provider, node role, and hardware it runs on. Syself also tests the
upgrade paths between Cluster Stack releases, so a cluster moves forward safely over time.
Tested Together
Syself tests the Kubernetes version, the node image, the in-cluster components, and every upgrade path together, then ships them as one release.
Applied Per Node
Each Cluster Stack fits the infrastructure it runs on. The provisioner installs only what a node needs for its role and its hardware, nothing more.
Continuously Maintained
Syself tracks versions, vulnerabilities, fixes, and upgrade paths. Releases on the same minor keep behavior stable; a new minor adds new Kubernetes features.
One release unit, three layers
A Cluster Stack defines every layer of your cluster in one release, from the node operating
system at the bottom to the networking that connects it.
Cluster Add-ons
Kubernetes Configuration
Node Image
The stack ships only the add-ons a cluster needs to run, like the Container Network Interface (CNI) and the Cloud Controller Manager (CCM). Syself pins each one to a tested version and installs it when the cluster comes up, so nothing runs that was not tested together.
The stack ships only the add-ons a cluster needs to run, like the Container Network Interface (CNI) and the Cloud Controller Manager (CCM). Syself pins each one to a tested version and installs it when the cluster comes up, so nothing runs that was not tested together.
Core components like etcd and the API server come with settings Syself has already tuned and locked for the hardware underneath. You inherit a control plane that stays stable and secure, with no flags to hand-edit on every node.
The node image carries the container runtime, the security hardening, and every system dependency a node needs. It cannot change after Syself builds it, so each node boots exactly what the rest of the stack was tested against.
The value of a tested ClusterStack
Every node in a stack version is built from pinned, traceable inputs, so Syself can verify,
support, secure, and upgrade clusters with confidence.
Same Stack, Same Behavior
Nodes on the same stack version boot the identical OS and container runtime. Nothing drifts from one machine to the next.
Safer Updates
Move to newer versions without tracking every component yourself. Syself keeps the stack tested and compatible, so updates are easier to trust.
Reproducible Node Images
Node images are built at release time and distributed with the Cluster Stack. During provisioning, nodes receive everything they need without installing packages on boot.
Fully Automated Tested Upgrade
Syself tests every Kubernetes version and component upgrade on real clusters before it ships. See how Upgrades on Syself works
Step-by-Step Execution with Validation
Updates run one controlled step at a time, and Syself checks the cluster stays healthy before it moves to the next.
End-to-End Compatibility
Core components stay stable and secure after an update, from etcd and the API server to kubelet, networking, and storage.
Syself Linux,Layer by Layer
An immutable node OS, built from source as sealed, read-only layers. The kernel checks the
base, the add-ons, and the per-node config against known hashes at boot, so a node cannot
drift from the image Syself tested.
Every server runs the same known build, and updates replace the image rather than modify it
in place. Writable runtime data stays separate from the verified system, while each image
ships tuned for its target hardware with everything the node needs already cached.
Base Image Size
< 250MB
dm-verity Sealed
ReadOnly
Packages installed
< 60
boot-time assembly
< 30s
A node has only what it can use
Hardware-Aware
Reproducible nodes
100%
Every release ships with SBOM, VEX
No Package Manager
How a Server Becomes a Syself Node
The provisioner turns bare hardware into a verified Kubernetes node in sealed phases. Each
phase finishes in full before the next starts, so a server is never reachable while it is
still unconfigured.
01 Server Created
Hetzner brings up a fresh machine, either a cloud server or a bare-metal server, and boots it into the rescue system. The same path works for every node, so control-plane, worker, and GPU servers all start the same way.
02 Rescue System
The machine first runs a small Linux in memory, with the disks attached but still empty. It cannot reach your cluster, so all setup happens in this throwaway environment, and nothing is left for the live node to configure itself.
03 Immutable OS Installed
The provisioner checks the disks, downloads the node image, and confirms it is correct before writing the read-only operating system. Only the parts a node needs are installed, nothing more.
04 Configuration Applied
It writes this machine's name, network settings, and the details it needs to join Kubernetes, then locks these files so they cannot be changed later. Every server ends up set up the same way, with no drift over time.
05 Server Starts
The machine reboots into the sealed system, and the kernel checks every block before it runs. Then syself-activate joins the node to your cluster, or starts a new one, and confirms it is healthy before handing it over.
06 Agent Watches the Node
From here on, syself-agent keeps the node connected to the control plane and runs health checks all the time. If a part fails, or a file is changed, it reports the problem so it can be fixed fast.
From Cluster Stack 1-34-v1, the update path
leads to 1-34-v10, and the upgrade
path continues to 1-36-v5.
Automated Updates and Upgrades
Every change to a cluster's Kubernetes version comes through a Cluster Stack release, never
a patch to a running node. An update keeps the cluster on the same Kubernetes minor version;
an upgrade moves it to a newer one. Both run a tested, automated path.
Updates carry maintenance work: security
patches, bug fixes, and component bumps that do not change how Kubernetes behaves.
Upgrades are where new Kubernetes behavior
lands, along with new Syself features, API changes, and the larger compatibility shifts between
minor versions.
Cloud servers are replaced, bare-metal ones are reprovisioned
Kubernetes, the components, and the node image move together
Every node runs a tested stack version
Autonomous Self-Healing Kubernetes Clusters
Node failures should not page your team. On every node, a health daemon (syself-agent) runs
inside the operating system and checks the kernel, kubelet, container runtime, and disk. It
reports what it finds as standard Kubernetes node conditions, so Kubernetes acts on each
node's real state instead of guessing from a missed heartbeat. On top of that, Syself's
management cluster watches every cluster from the outside and steps in when a node cannot
recover. Read more about Self Healing
At Cluster Level
From outside your cluster, Syself's continuously checks that every node is responsive. A
node that has crashed or lost its network cannot report on itself, so this outside view is
what catches it, including a whole cluster that has gone unreachable. The management
cluster is highly available, so the monitoring itself has no single point of failure.
Failure Detection
Inside your cluster, syself-agent runs on every node and discovers a problem the moment it
appears. At the same time, the control-plane nodes watch each worker's heartbeat on their
own. This detection lives inside your cluster, isolated and with no outside dependency, so
it keeps working even alone and stays very reliable.
How Syself Works Differently
Terraform or Ansible run once and then stop. Syself never stops talking to your infrastructure
provider's APIs. It provisions the cluster, reads its real state, and corrects any drift the
moment it appears, so the running cluster keeps matching what you asked for. You declare the
outcome, and the controllers do the rest.
Syself scans every Cluster Stack release for vulnerabilities and ships a full Software Bill of
Materials (SBOM) with it. You get cryptographically verifiable evidence of every component
your clusters run, not just a claim that they are safe.
