Verifiable, Immutable OS for Kubernetes Nodes: Syself Linux

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.

It's the foundation the rest of the platform rests on. Nodes here are disposable: never patched, always replaced. That only works because the thing being replaced is identical, tested, and provable every time.

What makes it immutable?

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 goes on checking each add-on pack and the per-node config the same way, block by block as they're read, not just once at startup.

So 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.

Why an immutable OS at all?

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. Patch a fleet for a year and no two servers are quite the same anymore. Each one carries its own history, and the next failure hides in the difference.

A Syself Linux node can't drift, because it never changes at all. An update is a fresh image, never a change applied in place.

How small, and why that matters

At roughly 350 MB, there isn't much surface to attack: no package manager, no general-purpose userland, none of the software a normal distribution drags along. 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. So a node boots even when it's air-gapped, pulling nothing from the network.

Can you prove what a node runs?

Yes, and without trusting us. 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; C means the kernel caught corruption. And you can browse every component on a node, its version, and a downloadable SBOM in the Version Hub. The full walkthrough is in Verify node integrity.

Why didn't we build on Talos?

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.

That "replace it, don't nurse it" idea isn't ours. 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 it, and Talos, designed to be tended node by node, pulls the other way.

There's a deeper reason too. 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 gets you a good node; it doesn't get you that system. And because we build the OS, we can stand behind every node: what's on it, the security issues that affect it, and an SLA to back it, rather than wrapping an image someone else ships.

Talos and Syself Linux, side by side

Both are a small, locked-down node you replace instead of patch. Where they part ways is who runs it.

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 choice isn't Syself Linux against Talos — it's Syself Autopilot against running Talos yourself. It comes down to whether you want to operate the nodes yourself or hand that off to a managed service.

The platform stands behind each node

You do not have to trust a node on faith, and it does not have to prove itself on its own. The provisioner writes the sealed image to each server, confirms the node booted exactly that image, and keeps watching it while it runs, so the system that builds and runs a node stands behind it. Even the few writable parts a node needs, its logs, certificates, and kubelet state, cannot change without leaving a trace the platform turns into an alert.

FAQ

Do I ever patch a Syself Linux node?

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.

Can I SSH into a 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 door there, enterprises especially. What you can't do is change the node through it: 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 control that door. 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 where the immutable, replace-never-patch model starts. The next step is how that image becomes a running node.