Why I Run Talos Linux on My Homelab

When I first set up my homelab Kubernetes cluster, I ran Ubuntu Server. It worked, but it bothered me. I had a full Linux distribution running just to host Kubernetes: hundreds of packages I'd never use, an SSH server I had to secure, and configuration that could drift over time. Then I found Talos Linux.

What Is Talos Linux?

Talos Linux is a minimal, immutable operating system designed exclusively to run Kubernetes. There's no SSH. No shell. No package manager. No way to log into the machine at all. Everything is managed through a gRPC API using the talosctl command-line tool.

The first time you hear this, it sounds insane. No SSH? How do you debug anything? But after running it for months, I can't imagine going back.

Why Immutable Matters

An immutable OS means the root filesystem is read-only. You can't install packages, modify system files, or make changes that persist outside of the API. This gives you:

• No configuration drift: the machine is always in the state defined by its machine config
• No unauthorized changes: there's no shell to run commands in
• Reproducible builds: reinstalling produces identical results
• Smaller attack surface: no SSH daemon, no unnecessary services, no package manager to exploit

The Machine Config

Everything about a Talos node is defined in a single YAML machine configuration: networking, disk partitions, Kubernetes settings, kernel parameters, system extensions. You apply it with talosctl apply-config and the node converges to that state.

This is infrastructure as code at the OS level. The machine config is the source of truth, and you can version it in Git alongside your Kubernetes manifests.

Day-to-Day Operations

Common tasks work through talosctl:

# Check node health
talosctl health

# View system logs (replaces journalctl)
talosctl logs kubelet

# View running processes (replaces ps/top)
talosctl processes

# Get kernel messages (replaces dmesg)
talosctl dmesg

# Apply updated configuration
talosctl apply-config --file controlplane.yaml

It takes a day to adjust to the mental model, then it feels natural. You stop thinking about the OS and focus entirely on Kubernetes.

Upgrades

OS upgrades are atomic. You point talosctl upgrade at a new Talos image and it reboots into it. If something goes wrong, it rolls back. No apt upgrade anxiety, no broken dependencies, no partial upgrade states.

Kubernetes version upgrades are equally clean: talosctl upgrade-k8s handles the control plane and kubelet versions.

Extensions

Since you can't install packages, Talos uses system extensions: minimal containers that run at the OS level. I use the iscsi-tools extension for Longhorn storage. Extensions are baked into the Talos image at build time using the Image Factory.

The Tradeoffs

It's not perfect:

• Debugging is different: no shell means no quick curl or tcpdump from the host. You debug from within pods or use talosctl commands.
• Learning curve: if you're used to SSHing into machines, the API-only model takes adjustment.
• Limited ecosystem: some tools assume they can run on the host. Anything that needs host-level access needs to be rethought.

For a Kubernetes-focused homelab, these tradeoffs are worth it. The security posture alone justifies the switch.

Who Should Use It

If you run Kubernetes and want to treat your nodes as cattle instead of pets, Talos is the answer. It's especially good for homelabs where you might rebuild from scratch periodically: the entire OS state is defined in one config file, and recovery is just talosctl apply-config on fresh hardware.

I went from "I have a Linux server that also runs Kubernetes" to "I have a Kubernetes appliance." That's exactly what I wanted.