Oxide details three Kubernetes paths, with native storage still unfinished

Why it matters

Kubernetes is testing Oxide's central thesis: owning the full rack lets it fix customer problems across APIs, networking, storage and the hypervisor, while making Oxide responsible for every missing capability.

Oxide, the on-prem cloud hardware builder founded by Steve Tuck and Bryan Cantrill, on Thursday detailed how customer requests pushed it from having no supported Kubernetes integrations in late 2024 to maintaining three provisioning paths and a shared runtime controller.

The August 13th technical account also gives an unusually direct inventory of the work that remains. Oxide still lacks a native load-balancing service, and a native Kubernetes storage driver is blocked by the Cloud Computer's inability to attach or detach disks while an instance is running.

Those constraints make the Kubernetes effort a test of the founders' original bet. Tuck and Cantrill built Oxide around the idea that on-premises infrastructure should arrive as an integrated cloud computer, with hardware, storage, networking and control software designed together. Kubernetes is forcing that integrated stack to meet the same infrastructure contracts that developers expect from public cloud providers.

Matthew Sanabria, who joined Oxide as its first Solutions Software Engineer, has been carrying that work across the boundary between customers and the product. His first assignment started with a customer-submitted pull request and an internal roadmap, RFD 493. It eventually produced integrations for Rancher, Sidero Labs' Omni and Kubernetes Cluster API, plus a cloud controller manager shared across those provisioning systems.

Customer code became the roadmap

The first integration came from outside Oxide. A customer had submitted a Rancher node driver pull request that translated Rancher provisioning operations into Oxide API calls. Sanabria tested the implementation, merged it, added CI/CD and documentation, and published the initial release.

Sanabria says that customer was already running the driver in production. Oxide has not published the customer's identity, cluster size or workload profile, so the production claim remains a vendor account rather than an independently measured deployment. The contribution still gave Oxide a concrete starting point: software written around an actual operator's workflow instead of a speculative integration plan.

That pattern continued with Sidero Labs' Omni integration. Customers wanted to provision Talos Linux machines on Oxide and register them with Omni. Oxide began work on September 24th, 2025, giving Sanabria's group seven weeks before an Oxide and Sidero event on November 12th.

The deadline exposed a low-level compatibility bug. Oxide presents cloud-init user data using a FAT12 filesystem, while Talos initially looked for an ISO 9660 superblock and stopped probing after that attempt failed. Talos therefore could not read the configuration required to join Omni.

The temporary fix captured the practical nature of the project: pad the user-data file with comments until it became large enough to use ISO 9660. Sidero worked on the underlying correction, while Oxide used the workaround to keep the integration moving for the November demonstration.

Oxide later released Cluster API Provider Oxide, or CAPOx, after customer demand and the size of the Solutions Software Engineering group caught up with the engineering cost. CAPOx lets operators use Kubernetes custom resources to create, scale, upgrade and delete clusters on an Oxide rack. It supplies a Kubernetes-native path that does not require Rancher or Omni as the management layer.

The three integrations serve different operator preferences. Rancher fits existing Rancher environments. Omni combines Talos Linux with Sidero's lifecycle tooling. CAPOx lets operators manage cluster infrastructure through the upstream Cluster API model. Oxide's current Kubernetes documentation recommends Rancher or Omni as its most complete managed provisioning options, while CAPOx gives the engineering group another end-to-end system to test against its own infrastructure.

Kubernetes exposed the platform gaps

Provisioning virtual machines solves only the first part of running Kubernetes. Once a cluster is active, Kubernetes needs a reliable view of the infrastructure underneath it. Oxide built an open-source cloud controller manager to reconcile Kubernetes Node objects with Oxide instances and report details such as addresses, instance identifiers and machine state.

The controller also handles Kubernetes services of type LoadBalancer, even though Oxide has not shipped a native load-balancing service. Oxide uses floating IP addresses as an interim mechanism. The controller attaches a floating IP to an eligible Kubernetes node, then relies on the cluster's service dataplane to route traffic to the target pods.

That approach supports a familiar Kubernetes API while exposing an imperfect implementation underneath it. Users see both the externally reachable floating IP and the node's internal address in Kubernetes output. According to Oxide's cloud controller manager documentation, the service controller allocates and attaches the floating IP to the first node ordered by name. The controller currently supports externalTrafficPolicy: Cluster, which permits that node to forward traffic to endpoints elsewhere in the cluster.

Storage presents the harder constraint. Kubernetes expects a Container Storage Interface driver to create and attach a volume after a pod has been scheduled. Oxide currently requires an instance to stop before a disk can be attached or detached. Stopping a Kubernetes worker for one volume operation would interrupt its other workloads and could trigger further scheduling and storage changes.

A native Oxide CSI plugin therefore depends on disk hot-plug support across the hypervisor, control plane and API. Kubernetes has converted a missing integration into a platform requirement that reaches through the full hardware-software stack.

The founders' integration bet gets tested in production

Oxide's approach gives Tuck and Cantrill control over the layers needed to solve these problems. It also makes Oxide responsible when a standard cloud workflow reaches a capability the rack cannot yet provide. The Kubernetes work has already generated projects in networking, storage, image building and infrastructure reconciliation, rather than remaining a thin compatibility package around an API.

That responsibility is expensive. Oxide raised a $200M Series C on February 5th, 2026, following a $100M Series B in July 2025. Oxide said the Series C came entirely from existing investors; Intel Capital said US Innovative Technology Fund led the round. The financing gives Oxide room to keep extending a capital-intensive physical product after delivery, including platform work that starts with a customer's Kubernetes request and ends inside the hypervisor.

Sanabria's account shows the operating model behind that spending. A customer supplied the first Rancher code. Omni customers forced Oxide and Sidero to debug a filesystem assumption. Cluster API demand justified a larger implementation. Stateful workloads exposed the need for disk hot-plug.

Oxide now has Kubernetes provisioning and runtime integrations, including software that Sanabria says at least one customer was already using in production. Native CSI storage and native load balancing remain unfinished. Each unfinished piece marks another test of the founders' promise that owning the whole cloud computer can make on-premises infrastructure behave like a cloud service.