This resource is part of the Syself Autopilot 1.36 release. For the whole picture, see what's new in 1.36.
Every node in a Syself Autopilot cluster now runs Syself Linux: an immutable operating system we build from source and then seal, so the kernel can check each block against that seal as it reads it from disk. It's about 350 MB, has no package manager, and holds nothing a Kubernetes node doesn't need. Because it's sealed, you can recompute that seal yourself and confirm a node is running exactly what we shipped.
The rest of the platform is built on it. Nodes here are never patched, only replaced, and that only works if every replacement is identical, tested, and provable.
The base image and every layer on top of it ship as sealed, read-only images guarded by dm-verity, the Linux feature that stores a hash for every block of a disk and fails any read whose block doesn't match. From the moment a node boots, the kernel verifies the base against a published root hash, and it keeps checking each add-on pack and the per-node config the same way. Every block is checked each time it's read, for as long as the node runs.
A modified base doesn't start, and tampering on a running node is caught: depending on what changed, the node either replaces itself or raises an alert you can act on. There's no package manager to patch and no way to edit a layer and keep it trusted.
Before, our nodes ran a general-purpose Linux we set up with scripts. It worked, but it was big, it drifted, and it was hard to prove what was really on a machine. After a year of patching, no two servers in a fleet are quite the same. Each one carries its own history, and those differences make failures hard to trace.
A Syself Linux node can't drift, because it never changes. An update arrives as a fresh image instead of a change applied in place.
| General-purpose Linux node | Syself Linux node | |
|---|---|---|
| Size | Several gigabytes | About 350 MB |
| How a change arrives | Patched in place, then rebooted | A fresh, tested image replaces the node |
| State after a year | Its own patch and edit history | Identical to the image it booted |
| Integrity | You trust the patching went well | The kernel verifies each block against a sealed hash as it's read |
| Fixing a broken node | Log in and repair by hand | Reprovision from the image |
At roughly 350 MB, there isn't much surface to attack: no package manager, no general-purpose userland, and none of the extra software a normal distribution includes. We build the image for the hardware it runs on, from cloud servers to the bare-metal machines Hetzner offers, and everything a node needs is baked in, container images included. A node can boot even when it's air-gapped, because it pulls nothing from the network.
Yes, and you don't have to trust us to do it. A node's root hash is recomputable from the published image, so anyone can confirm a node booted exactly what Syself shipped. Even a node's own settings are verifiable: its hostname, keys, and network config are sealed as another layer and checked on every read like everything else.
You can also just ask the kernel on the node:
$ dmsetup status root
The status ends in a single letter. V means every block is being verified and none has failed, and C means the kernel caught corruption. You can also browse every component on a node, its version, and a downloadable SBOM in the Version Hub. The full walkthrough is in Verify node integrity.
Talos is the closest thing out there to Syself Linux, so people ask this a lot. The difference comes down to who runs the node. Talos is built to manage itself: you drive each node through its own interface, and it updates itself in place. Our platform works the other way. It builds, runs, and replaces the node for you, swapping in a fresh one whenever anything needs to change.
Replacing nodes instead of repairing them isn't our idea. It's the "cattle, not pets" principle behind Cluster API, the Kubernetes project for managing clusters and the machines under them. Our whole platform is built on that principle, while Talos is designed to be managed node by node.
There's a second reason. The OS is only about a tenth of what we ship. The rest is the system that tests every build, tracks the CVEs in it, provisions it, heals it, and upgrades it on a proven path. Running Talos yourself gives you a good node, but you'd still have to build that system around it. Because we build the OS ourselves, we can stand behind every node: what's on it, the security issues that affect it, and an SLA to back it. We couldn't do that by wrapping an image someone else ships.
Both are a small, locked-down node you replace instead of patch. The main difference is who runs it.
| Talos | Syself Linux | |
|---|---|---|
| Who operates the node | You, through its API | Syself, as a managed service |
| How an update happens | The node updates itself in place | The node is replaced with a fresh one |
| Getting into a node | API only, no shell | SSH into a locked-down node when you need it |
| Hardware fit | Runs across many providers | Tuned to the hardware it runs on: cloud and bare-metal servers alike |
Syself Linux isn't a product you run on its own. It ships as one piece of Syself Autopilot, the managed platform that builds, runs, and replaces your nodes for you. So the real comparison is between Syself Autopilot and running Talos yourself. It comes down to whether you want to operate the nodes yourself or hand that off to a managed service.
A node doesn't have to vouch for itself. The provisioner writes the sealed image to each server, confirms the node booted exactly that image, and keeps watching it while it runs. Even the few writable parts a node needs (its logs, certificates, and kubelet state) can't change without leaving a trace that the platform turns into an alert.
No. Fixes and CVE updates arrive as a new image, and the node is replaced by the same loop that heals and upgrades. There's nothing to patch on a running node.
Yes. SSH is on by default and key-only, kept as an out-of-band way in for support and debugging. Many teams want that access available, especially enterprises. You can't change the node through it, though: the system is read-only, so an edit either won't stick or gets flagged, and it's gone when the node is replaced anyway. Permanent changes belong in your config, where every node picks them up.
You decide who can use it. You can restrict SSH to a bastion host or turn it off entirely with a Cilium deny policy (see Restrict SSH access).
Syself Linux is the starting point for the immutable model, where nodes are replaced instead of patched. Next, see how that image becomes a running node.
Start with a 14-day free trial, and our step-by-step guides will walk you through your first cluster deployment in minutes.
Tags
Syself Autopilot 1.36 ships its own reverse tunnel so kubectl logs, exec, and pod metrics work. Each node dials out, so the control plane never has to dial in.
KubeGate is the single entry point to the Kubernetes API server in Syself Autopilot 1.36. It controls who reaches the control plane and preserves the real client IP.
Syself Autopilot 1.36 produces four Kubernetes audit signals on every node, including the real client IP in the API server audit log, ready to ship to a SIEM.