Omni: The Bare-Metal Control Plane That Makes Hardware Feel Like an API
A deep dive into how Sidero Labs combines Talos, signed gRPC, and outbound tunnels to manage Kubernetes clusters on machines you cannot directly reach.
- Omni's real innovation is not cluster management, but making hostile network reachability irrelevant to day-2 operations.
- The platform treats physical machines as queryable resources, so hardware state becomes something you can watch, sign, and reconcile.
- SideroLink turns outbound connectivity into the control path, which is what makes bare metal feel cloud-like without turning it into a cloud.
- Omni is opinionated by design: Talos, schematics, and signed APIs form one operating model instead of a pile of separate tools.
Bare metal gets romanticized until the first time you have to manage a machine you cannot SSH into. Retail sites, lab racks, colo cages, and edge boxes all break the same assumption: the network is friendly. Omni is built around that failure. It starts from the uncomfortable truth that inbound access is often impossible.
That changes the whole product. Instead of asking operators to punch holes, wire VPNs, or build bootstrap rituals around PXE and shell scripts, Omni treats the machine as something that should call home, present state, and accept desired configuration through a controlled channel. The result is a control plane that behaves more like a cloud service than a traditional bare-metal tool.
The problem Omni actually solves
The hard part of bare metal is not installing an OS. It is keeping the machine reachable, knowable, and recoverable after the install is over. Once hardware lives behind NAT, firewalls, or local-only networks, the classic toolkit starts to fray. SSH becomes brittle. IPMI is narrow. Ad hoc scripts turn into folklore.
Omni's answer is to stop treating reachability as a prerequisite. Machines boot Talos, establish an outbound connection, and then become manageable through Omni's API surface. That flips the operational model from "find the box and log in" to "observe state and reconcile desired state."
Omni started with the exact opposite idea. Instead of automatic provisioning, the model was bring your Talos. A user can put a Talos image anywhere, even on an obscure cloud, and it will connect to Omni, and now you can manage it.
Omni's trick is an outbound control plane
The key mechanism is SideroLink, an outbound tunnel that lets a node behind a firewall establish a secure session back to Omni. That sounds like a networking detail. It is actually the product. Once the tunnel exists, Omni can watch, list, update, and coordinate the machine without assuming any inbound route exists.
This is why Omni feels different from a generic cluster manager. The product is not just orchestrating Kubernetes objects. It is orchestrating the machine lifecycle around a connectivity assumption that usually kills bare-metal automation before it starts.
Hardware is not a blob here
Omni models machines as structured resources, not as opaque hosts. The platform tracks hardware and status in enough detail to make the object useful before Kubernetes even exists. Disk serials, CPU frequency, network links, security posture, and system state all matter because they shape what can safely happen next.
That resource-first model is closer to Kubernetes than to traditional provisioning tools. Instead of one-shot installation logic, Omni keeps a live view of machine state and reconciles against it. The important shift is philosophical: hardware is no longer a bootstrap chore. It is a first-class object with lifecycle, status, and drift.
Schematic is image-as-code for machines
Omni's provisioning model goes beyond "pick an ISO." The idea of a schematic is that the image itself is assembled from declared inputs: extensions, kernel arguments, and tunnel-aware boot settings. In practice, that means you can shape the machine before it ever joins the cluster.
message CreateSchematicRequest {
repeated string extensions = 1;
repeated string kernel_args = 2;
bool use_grpc_tunnel = 3;
string machine_type = 4;
}
message MachineStatusSpec {
string system_disk = 1;
repeated string block_device_serials = 2;
repeated string network_links = 3;
uint32 cpu_frequency_mhz = 4;
} The detail matters because it collapses two separate jobs into one surface. You are not just provisioning an operating system. You are declaring how the machine should exist, how it should connect, and how it should be managed after the first boot.
The client SDK turns Omni into an automation surface
Omni is not only a UI. The Go client shows that the product is designed to be driven as an API platform. It opens a gRPC connection, then exposes sub-clients for Omni resources, management actions, and Talos-specific operations. That pattern makes automation feel native instead of bolted on.
The authentication layer is part of the story too. Calls are signed, service accounts can use cryptographic credentials, and the client abstracts the ceremony away from the caller. The result is a management plane that expects machine-to-machine traffic, not just human clicks.
Why Omni is different from CAPI, Rancher, and MaaS
| Tool / Approach | How it reaches the machine | What it manages | Day-2 operations | Edge / NAT friendliness | Opinionated OS integration |
|---|---|---|---|---|---|
| Omni | Outbound SideroLink tunnel | OS, machine state, and Kubernetes lifecycle | Strong. Upgrades, config, break-glass, and reconciliation are core | High | Tight with Talos |
| Cluster API | Usually through controllers and provider-specific infrastructure access | Kubernetes clusters | Strong for declarative cluster lifecycle, weaker for machine reachability problems | Medium | Depends on provider |
| Rancher / RKE2 | Often assumes reachable nodes and conventional networking | Cluster deployment and fleet management | Strong UI and ecosystem, but more general-purpose | Medium | Loose |
| MaaS | PXE, BMC, provisioning networks | Bare-metal provisioning | Good for install and commissioning, less opinionated above the OS layer | Low to medium | Low |
| Terraform plus Ansible plus VPN | Whatever you wire together | Whatever you script | As strong as your playbooks | Variable | None |
This is not a verdict that the other tools are bad. It is a statement about center of gravity. CAPI is about declarative cluster management. MaaS is about provisioning. Rancher is broad and enterprise-friendly. Omni is optimized for a narrower, harder problem: make bare metal behave like a managed cloud surface even when the network is hostile.
The security model is part of the product
Omni does not treat identity as an afterthought. Signed API calls, service account credentials, and OIDC are part of the control surface. That matters because the whole system is built around remote trust. If the machine can reach out, the control plane has to know exactly who is speaking and what they are allowed to do.
That security posture fits the rest of the design. If hardware is a live resource and the tunnel is the control path, then authentication cannot be a sidecar concern. It is the thing that keeps the whole model from becoming a very elaborate remote shell.
The BUSL license means you can run Omni for non-production workloads which includes testing, proof of concept, and home labs.
Why this matters beyond Talos users
Omni is bigger than one OS, even if Talos is its sharpest expression. The deeper idea is that infrastructure should be declarative all the way down to the machine boundary, and that remote trust should be built into the control plane instead of layered on top of it.
That is why the product reads less like a provisioning tool and more like an operating model. It says the hard part of bare metal is not installation. It is operating machines that live in places you do not control, on networks you do not trust, with state that changes under pressure. Omni is designed for that reality.