Applying modern DevOps and Platform Engineering practices to a homelab with Talos Linux and Omni

Two years ago, Grzegorz Rożniecki, Senior Engineering Manager at Akamai, found himself staring at the CNCF landscape wondering how something as straightforward as running Kubernetes could become so impossibly complex. What started as a home lab project turned into a lesson about architecture, abstractions, and why the best platforms are the ones that get out of your way.

The complexity trap

The journey started when Akamai acquired Linode, and Rożniecki’s team began building platforms on top of it. He decided that, if he was going to build production infrastructure, he wanted to understand it from the ground up.

So he set up a home lab.

He started with Proxmox, K3s, and TrueNAS for storage, then added Kairos for immutability, Terraform for one-click deployments, Kubeadm, Ansible for configuration management, and Kubespray to tie it together.

Which indeed was a lot to manage. Each tool was reasonable on its own, but together, they created a tangled mess.

The deeper problem isn't the tools themselves but rather cognitive load: the hidden tax of modern architecture. Every additional layer meant another thing to understand, maintain, and troubleshoot. The actual constraint was time, and all of it was going to infrastructure instead of to what he actually wanted to learn. Or as one of our SREs said, trying to manage a fleet this way is “basically rocket science.”

Finding Talos

Talos Linux emerged as a way out of that complexity. It is the simple, minimalist Kubernetes OS with no SSH, shell, or user management, and fewer than 50 binaries. Plus, it’s API-first.

Though it initially seemed strange, it was clear that there was value in having an OS that was API-first. By eliminating the shell, Talos Linux eliminates an entire class of vulnerabilities and configuration drift. By being immutable, it eliminates another. (It’s true. We have the data.)

DevOps and the cognitive load problem

There's a broader context that goes beyond the home lab. The DevOps movement, coined in 2009, was fundamentally about tearing down the wall between development and operations, making it possible for developers to move faster without being blocked by organizational silos. But it created a new problem: if dev and ops are one team, that team now has to understand everything.

The answer isn't for everyone to know everything. The answer is platform engineering and building the abstractions that let each team focus on what they're actually good at.

Team Topologies describes this through four team types:

• Stream-aligned teams doing product work
• Enabling teams helping others onboard
• Subsystem teams owning specialized domains
• Platform teams providing everything as a service

The platform team's job is to make the underlying complexity invisible to everyone else, and in this case, Talos fits this model cleanly. Whether running on bare metal or virtual machines, it is able to provide a consistent, API-driven foundation that platform teams can build on without exposing that complexity to developers. The hardware layer simply stops mattering.

Where Omni comes in

Talos solved the OS problem. But as the home lab grew, with increasingly more machines, clusters, and experiments, a new problem emerged: how do you manage a fleet of Talos nodes across multiple clusters without losing track of what's where?

That's what led to Omni. Where Talos is the abstraction over the OS, Omni is the abstraction over the fleet. It can act as the control plane for the control planes–the single place with centralized authentication, observability, and cluster management regardless of where the nodes actually live.

The pattern maps directly back to the platform engineering principle: find the right abstraction, hide the complexity beneath it, and give teams a clean interface to work with.

As Rożniecki said, “Great architectures have one thing in common: they're simple.”