Skip to main content
Resources

Verifiable, Immutable OS for Kubernetes Nodes: Syself Linux

Verifiable, Immutable OS for Kubernetes Nodes: Syself Linux
Note

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.

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

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. 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 nodeSyself Linux node
SizeSeveral gigabytesAbout 350 MB
How a change arrivesPatched in place, then rebootedA fresh, tested image replaces the node
State after a yearIts own patch and edit historyIdentical to the image it booted
IntegrityYou trust the patching went wellThe kernel verifies each block against a sealed hash as it's read
Fixing a broken nodeLog in and repair by handReprovision from the image

How small, and why that matters 

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.

Can you prove what a node runs? 

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.

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.

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.

Talos and Syself Linux, side by side 

Both are a small, locked-down node you replace instead of patch. The main difference is who runs it.

TalosSyself Linux
Who operates the nodeYou, through its APISyself, as a managed service
How an update happensThe node updates itself in placeThe node is replaced with a fresh one
Getting into a nodeAPI only, no shellSSH into a locked-down node when you need it
Hardware fitRuns across many providersTuned 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.

The platform stands behind each node 

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.

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

Ready to Build? Start Your Free Trial

Start with a 14-day free trial, and our step-by-step guides will walk you through your first cluster deployment in minutes.

Tags

Product UpdatesKubernetesInfrastructure