We spend a lot of time working with clients who are evaluating options when they are faced with large expenditures for infrastructure refreshes and hypervisor software renewals. Arctiq can offer an array of common alternatives, help modernize to cloud-native patterns, or point toward something different entirely…

Oxide Computer is different.

It is a challenger. Oxide has built something unique and did not try to compete with what others are doing. It started from scratch and rebuilt the stack from the silicon up, published the software on GitHub, and made a rack-scale bet that the rest of the industry said was too hard to be worth it.

Whether or not it ends up being the right fit for your environment, it's the kind of engineering-first thinking that I don't see enough of in this market, and it's worth looking at.

Why this matters right now

Broadcom's 2023 acquisition of VMware brought a shift to subscription-only licensing and new packaging, and it's prompted a lot of IT teams to revisit their virtualization renewals and look at what else is out there. At the same time, more workloads are moving back on-prem for cost, data sovereignty, and performance reasons, while data centers everywhere are running out of power to feed AI buildouts. Oxide Computer Company sits at the intersection of all of these pressures.

What is Oxide Computer?

Oxide builds what it calls the Cloud Computer: a rack-scale system that treats an entire rack, not an individual server, as the unit of compute. Customers provision virtual machines, elastic block storage, and VPC-style networking through an API, web console, or SDK, the same self-service model hyperscale clouds offer, except the hardware sits in your own data center.

From the carefully considered ergonomics, blind-mated data paths, and integrated control-plane, the whole platform is designed with empathy for the operator. Blind-mating means there are no cables to wrangle, the sleds plug right into the backplane, and you’re done.

Founded in 2019 by veterans of Joyent and Sun Microsystems, including Bryan Cantrill and Steve Tuck, Oxide closed a $200 million Series C in February 2026 led by Thomas Tull's US Innovative Technology Fund, with Eclipse, Riot Ventures, and Jane Street also participating.

The current-generation rack is a 7.8-foot, roughly 2,500-pound system rated for 15 kW, packing 32 compute sleds (64 AMD EPYC "Milan" cores each, up to 1 TB memory, 32 TB NVMe) connected by a backplane delivering 12.8 Tbps of switching capacity. A refresh with AMD's "Turin" EPYC (up to 192 cores) and DDR5 memory is in the pipeline.

Oxide's pitch is general-purpose, API-first infrastructure for whatever a business runs on-prem: VMs, containers, CI/CD runners, data pipelines. You can explore the rack itself using Oxide's 3D Explorer.

How is the hardware built, and why is it all on GitHub?

This is where Oxide diverges hardest from other server vendors. Rather than adapting reference designs from an original design manufacturer (ODM), Oxide built its own service processor from scratch instead of using an off-the-shelf baseboard management controller (BMC) and hired an electrical engineering team to design its own compute sleds.

CTO Bryan Cantrill's reasoning, as he's put it: proprietary layers you can't inspect become impossible to debug when something goes wrong in production, so Oxide pushed to make its parts and silicon clearly documented at the lowest layers of interface.

The software side of that philosophy lives in public. Oxide's GitHub organization hosts the components that run the rack:

• Hubris: a memory-protected, message-passing operating system for the service processor and other embedded controllers, written in roughly 2,000 lines of Rust, with no dynamic memory allocation and no C code in the system (GitHub: Hubris)

• Humility: the companion debugger for Hubris, used to inspect and dump the state of any task on a running system (GitHub: Humility)

• Omicron: Oxide's control plane, the software that exposes the rack as a single API-driven system (GitHub: Omicron)

• Propolis: a Rust-based virtual machine monitor userspace, described below (GitHub: Propolis)

• Helios: Oxide's own illumos distribution, used as the host operating system on every compute sled (GitHub: Helios)

• Crucible: Oxide's distributed network-replicated block storage service, providing reliable state management at rack-scale (GitHub: Crucible)

• and more... (see: github.com/oxidecomputer)

The commitment holds up under a real test case. When Intel discontinued its Tofino switch silicon, which Oxide had already built its networking stack around, Intel open-sourced the Tofino P4 compiler rather than let the investment go to waste, and Oxide is now evaluating open alternatives for the next generation of its switch hardware. Cantrill has said the company expects to carry fewer proprietary "blobs" over time, not more, though it hasn't built its own SSD controllers and doesn't claim to have eliminated every closed component.

How power-efficient is it, and against what benchmark?

Oxide's central power efficiency claim is straightforward: 55% better power efficiency and roughly 12x more efficient cooling than a comparable legacy rack, translating into double the compute density per rack. Concretely, Oxide fits 32 sleds and redundant switches into less than 15 kW, versus roughly 16 kW for just 16 conventional 1U servers, so Oxide gets 2,048 CPU cores where a legacy rack gets 1,024.

Three design decisions drive that number.

First, a DC bus bar replaces AC power supplies: power is converted once at a universal power shelf and distributed as DC up and down the rack via a copper bus bar, eliminating the roughly 70 individual AC power supplies found across the servers and switches in an equivalent legacy rack. Cantrill has called the bus bar "one of the most glaring differences between the rack-scale machines at the hyperscalers and the rack-and-stack servers that the rest of the market was stuck with."

Second, a custom sled form factor accommodates bigger fans that move more air for roughly 12x less energy than the many small fans in a typical 1U/2U server, partly by removing legacy components like PCIe risers and storage backplanes that a general-purpose off-the-shelf server needs but a purpose-built cloud sled doesn't.

Third, the rack geometry is counter-intuitive on purpose: Oxide made its sleds taller and narrower, which sounds like it should reduce density, because most racks run out of power long before they run out of space. A half-empty rack because of a tripped power budget is common, and spreading the design out actually improves airflow and lets the rack use its full physical footprint.

How does Oxide pair with a GPU-based AI factory?

Oxide doesn't sell GPUs today. Its focus so far is CPU, storage, and networking, though Cantrill has said accelerators are on the roadmap. Its AI solutions materials position Oxide as the data-engineering and orchestration layer of an AI stack: ingesting and transforming data, running vector search and retrieval pipelines, and serving fine-tuned models via LoRA/PEFT on CPU, framed as a way to "reserve valuable GPUs for the workloads that require them".

This makes Oxide a natural neighbor to a GPU/accelerator-dense AI factory: accelerator-based nodes handle training and inference, while Oxide handles the data pipelines, orchestration, and general-purpose services around them on the same floor and on the same network fabric.

Why did Oxide build its own hypervisor instead of licensing one?

For years, "virtualization" mostly meant picking a hypervisor off a short list: VMware ESXi, Microsoft Hyper-V, AHV, or an open-source option like KVM or Xen. Oxide's answer wasn't to package one of those. It built its own, from the OS up, with Helios as the host operating system and Propolis handling device emulation and VM lifecycle. The piece that completes the stack is bhyve, the open-source virtual machine monitor originally built for FreeBSD and ported to illumos, which provides the core virtualization primitives underneath Propolis. Propolis also has live migration support.

The rationale is documented publicly in RFD 26, Oxide's engineering design document on the host OS and hypervisor choice and was discussed at length on the Oxide and Friends podcast episode "Helios". Oxide's engineers came out of Sun and Joyent's illumos/SmartOS lineage and judged that owning the full stack, from firmware to VMM, was the only way to get the observability, debuggability, and update story they wanted, rather than treating the hypervisor as a black box licensed from someone else.

That decision also reframes the conversation. The question stops being which hypervisor to license and becomes whether you want a vendor-licensed virtualization layer at all, versus a vertically integrated, open-source stack where the rack vendor and the hypervisor vendor are the same company and the code is auditable.

Asked directly whether that makes Oxide hyperconverged infrastructure, Cantrill's answer was: it depends on your associations with the term, but "there's a way in which we are even more converged than hyperconverged," since the rack's network switches and their operating system are also part of the same managed system.

How does Red Hat OpenShift run on Oxide for Kubernetes workloads?

Oxide instances are standard VMs, and Oxide lists Red Hat OpenShift alongside SUSE Rancher and Talos Linux as a supported way to run Kubernetes on the platform.

The integration work is public and specific. RFD 493, "Initial Kubernetes Integrations," lays out three layers of support: creating a cluster (a Rancher node driver, plus a Sidero Labs Omni infrastructure provider for Talos Linux clusters), managing a cluster (an Oxide cloud controller manager for node health and, in progress, load-balancer services), and using a cluster (a Container Storage Interface plugin, under active development, to back persistent volume claims with Oxide storage).

Because OpenShift is a standard Kubernetes distribution, it runs on Oxide the way any Kubernetes distribution runs on any cloud: as VMs provisioned through the API, with the cloud controller manager and CSI plugin handling the infrastructure plumbing. Pairing OpenShift's application platform and operator ecosystem with Oxide's open, API-driven substrate gives teams a complete on-prem Kubernetes stack, built from two systems that are each designed to be inspected and operated on their own terms rather than a single all-in-one proprietary appliance.

How does Oxide's model work for native VM workloads?

If you're running native VMs rather than Kubernetes, Oxide's model is a one-time hardware purchase with the software included. There's no per-core, per-socket, or per-node software fee: the control plane, CLI, and API ship with the rack, and support is a separate, predictable line item rather than a renewing per-core license. Oxide also advertises zero egress fees for moving data between compute and storage.

That's a different model from the subscription, per-core licensing that's become common across the broader virtualization and hyperconverged infrastructure market. Oxide's own comparison of itself against other on-prem platforms and public cloud highlights the areas it leans into: vertical integration, an open-source stack, a one-time purchase, hardware root of trust, and API-first design.

The trade-off is purchasing flexibility. A platform licensed core-by-core lets you scale spend with usage as it changes. An Oxide rack is more of a fixed capital commitment, which tends to suit organizations with steady, budgetable infrastructure needs rather than highly variable ones.

What's the migration path from a current solution?

Oxide VM instances are standard VMs and the platform is compatible with common tooling. There is an Oxide Terraform provider and an oxide.computer Ansible collection. You can carry over most existing automation and redeploy your workloads onto Oxide's resources and networking without a heavy lift.

Where to go from here?

Oxide isn't for every shop. Its fixed rack-scale configuration and young ecosystem mean it fits best for organizations with steady, budgetable infrastructure needs and an appetite for a new vendor and an open-source culture. For teams reconsidering their virtualization renewal, planning a Kubernetes platform on-prem, or figuring out what is next in a general purpose compute buildout, it's a genuinely different architecture worth evaluating as part of your next infrastructure investment.

If you're weighing options for your data center, talk to Arctiq about mapping the available options against your goals, workloads, and timelines.