AKS on bare metal Ubuntu is in public preview: can a team without a platform engineer actually run it?

Key Points:

• AKS on bare metal Ubuntu is in public preview, so it carries no SLA, and Microsoft's own docs say preview features "aren't meant for production use" (Microsoft Learn). Managed AKS on Azure VMs, by contrast, ships a paid control-plane uptime SLA of 99.95% with Availability Zones and 99.9% without (Microsoft Learn).
• Removing the hypervisor removes a virtualization layer, not operational work. Firmware, BIOS, NIC and driver versions, disk health, power, rack space and dead-node replacement move from Azure's responsibility to yours.
• For a team with no dedicated platform engineer, bare metal Kubernetes is realistic only if the hardware is already racked and someone is already accountable for it at 2am. Getting there by buying or colocating hardware means budgeting a platform hire or a partner, not just servers.
• Bare metal wins on price per core and loses on total cost of ownership until utilization is high and sustained. Measure first: committed-use discounts, right-sizing, autoscaling and auto-stopping non-production environments are cheaper levers than buying machines.
• A cluster is not a platform. Qovery installs on your existing Kubernetes cluster (self-managed, on-prem, any distribution) or on your own AWS, GCP, Azure or Scaleway account, and gives git-push deploys, preview environments per pull request, environment auto-stop and per-environment RBAC without building an internal platform. It does not operate your hardware.

Removing the hypervisor does not remove the work the hypervisor was doing. That is the one sentence I would want every team to read before they get excited about Azure's new public preview.

Here is my direct answer to the question in the title: in public preview, no, AKS on bare metal Ubuntu is not a production option, because it ships with no SLA and Microsoft explicitly says it is not meant for production. And even at general availability, it moves real operational work from Azure to you. That said, I am not dismissing it. For GPU workloads, data residency and sustained high-utilization profiles, running Kubernetes on your own metal is genuinely interesting. The question is whether a team with no platform engineer can own what comes with it. Mostly, the honest answer is not yet.

Let me walk through what Azure actually shipped, what the trade really is, and what I would do instead.

What exactly did Azure ship with AKS on bare metal Ubuntu?

Azure put AKS on bare metal Ubuntu into public preview in late September 2026, letting you run Kubernetes directly on your own physical Ubuntu servers with no hypervisor between the kernel and the hardware (AKS Engineering Blog). Azure Arc connects the host and cluster to Azure, and AKS manages the Kubernetes layer, while you install, patch and maintain Ubuntu and own everything under it (Microsoft Learn).

One correction to how this often gets described. Unlike managed AKS on Azure VMs, where the control plane runs in Azure, here the control plane and worker components both run on your host hardware, with Arc as the management link (Microsoft Learn). That is why there is no hosted control-plane SLA to point to.

As of the state of the preview on 20 October 2026, the confirmed scope is narrow, and you should plan around it rather than guess (Microsoft Learn):

• Host OS: Ubuntu 24.04.3 LTS or 24.04.4 LTS on x86_64. Ubuntu 24.04.5 LTS is not supported yet.
• Topology: single-node clusters only, one cluster per host. Multi-node clusters and scaling are not supported.
• Region: East US only.
• Creation and upgrades: Azure CLI only (the portal is read-only for Ubuntu), patch-version upgrades only.
• Networking: Cilium CNI; Kubernetes LoadBalancer services are not supported out of the box, so you use NodePort or the MetalLB extension.
• Storage: persistent volumes use host-local storage tied to the node; workload mobility needs a CSI driver.
• Billing: zero-rated meters during preview (no charge for the AKS cluster resources), though standard Azure charges for the Arc-enabled machine and services like Monitor still apply.

The preview caveat is worth quoting as Microsoft writes it, because it settles the production question on its own: "Previews are provided 'as is' and 'as available,' and they're excluded from the service-level agreements and limited warranty... these features aren't meant for production use" (Microsoft Learn). Microsoft also warns that clusters created during preview might need to be deleted and recreated at GA.

Four Azure products sound alike and get confused constantly. Here is the crisp version.

AKS on bare metal itself comes in two flavors: Azure Linux on validated Azure Local small-form-factor hardware, and the newer Ubuntu option on your own hardware (Microsoft Learn).

Does removing the hypervisor actually reduce complexity, or just relocate it?

It relocates it. The hypervisor was never the main source of Kubernetes operational pain. It was quietly doing node replacement, hardware fault isolation, live migration and instant re-provisioning. Delete it and those jobs land on your team, in exchange for direct hardware access and no virtualization tax.

What you genuinely gain is real: no virtualization overhead on CPU and memory, direct device access such as GPU passthrough, NVMe and SR-IOV NICs, deterministic NUMA topology and CPU pinning, and no noisy neighbours. I want to size that honestly, though. On modern hardware-assisted hypervisors the CPU and memory overhead is a few percent, not a tax worth reorganizing your company around. In StorageReview's hypervisor tests, ESXi and Hyper-V hit roughly 96 to 97% of bare metal performance on a kernel-compile workload, and all the hypervisors landed within about 1% of bare metal on OpenSSL (StorageReview). The gain is real for GPUs, latency-sensitive paths and I/O; it is modest for ordinary web services.

What you lose is the part that bites later: one-API node replacement, a cluster autoscaler with an elastic pool behind it, hardware abstraction, and the ability to treat a dead node as a rounding error.

And there is a new work list that nobody hands you a runbook for: firmware and BIOS baselines, out-of-band management over IPMI or Redfish, PXE or image-based provisioning, RAID and disk health, NIC driver and kernel pinning, a spares inventory, and remote-hands contracts.

Kubernetes assumptions also break on metal in ways the preview already shows. LoadBalancer services need MetalLB or BGP, persistent storage needs a real CSI story like Rook/Ceph or Longhorn rather than node-local disks, cluster autoscaling has nothing to scale into, and node image upgrades are physical reboots. For GPU, residency and sustained-load profiles this trade is clearly worth making. It is a trade, not a simplification.

Is this a realistic production option for a team with no platform engineer?

In public preview, no, because there is no SLA and support is best-effort only (Microsoft Learn). Even at GA, bare metal Kubernetes is realistic for a small team only if the hardware is already racked and someone is already on the hook for it at 2am. Running it creates a hardware on-call rotation that managed AKS on Azure VMs simply does not.

Here is a checklist you can self-score in 60 seconds. If you cannot tick all six, this is not your production platform yet:

• A hardware on-call rotation, not just an app on-call.
• Spare nodes physically on the shelf.
• Remote hands or datacenter access you can invoke tonight.
• An automated provisioning pipeline (PXE or image-based).
• A documented, enforced firmware baseline.
• A second person who can do all of the above when the first is on holiday.

"We only have a few nodes" makes this harder, not easier. With no spare capacity, one dead node is a capacity incident rather than a rescheduling event. And the cost that shows up in month six is upgrades: on metal, node image upgrades are reboots of physical machines with drain windows, not rolling VM replacement.

If the driver is cost, measure before you buy. Reserved instances and savings plans, right-sizing, cluster autoscaling, and stopping non-production environments outside working hours usually recover more than buying machines does. It genuinely is the right call when you already own the datacenter, you have a data residency or sovereignty mandate, your GPU economics only work on owned hardware, or you need single-digit-millisecond latency to on-prem systems. For most teams, the middle path wins: managed AKS on Azure VMs for the control and node lifecycle, bare metal only for the specific node pools that need it.

How does it compare to managed AKS, self-managed Kubernetes, and other bare metal distros?

AKS on bare metal Ubuntu sits between managed AKS on Azure VMs and fully DIY bare metal Kubernetes. You keep the Azure management plane, identity, policy and monitoring, but you inherit the same hardware operating model that Talos, RKE2 and OpenShift on bare metal hand you. Compare on the dimensions that decide the call, not feature checkboxes.

For control-plane economics and SLAs as context: managed AKS Standard is about $0.10 per cluster per hour, roughly $73 a month, and that is the tier that carries the SLA (Microsoft Learn). Amazon EKS charges $0.10 per cluster-hour with a 99.95% SLA by default (AWS), and GKE's standard control plane is free for the first cluster, with the 99.95% SLA tied to its paid tier (Google Cloud). Where AKS on bare metal wins is the one AKS API your team already uses, plus Entra ID, Azure Policy and Azure Monitor, under one support contract. Where it loses is preview status, hardware prerequisites, and no elastic escape hatch when you run out of capacity. Credible alternatives if you are committed to metal include Talos Linux with Sidero Omni, Rancher RKE2, OpenShift, and hardware from Equinix Metal, OVHcloud or Hetzner.

A one-line decision rule per reader: already own the datacenter, this is worth piloting; Azure-native and growing, stay on managed AKS and add bare metal node pools only where they pay for themselves; no infra team, do not start here.

Is bare metal actually cheaper once you count the people?

Bare metal almost always wins on raw price per core and often loses on total cost of ownership, because the savings are compute-only while the new costs are headcount, spares, colocation and downtime risk. The break-even depends on sustained utilization, not on the sticker price of a server.

Anchor the headcount honestly. Platform engineers are not cheap or easy to hire. Glassdoor puts the average US platform-engineer salary well over $130k in base pay before the fully-loaded cost of benefits, equity and overhead (Glassdoor). A single fully-loaded platform hire typically runs well past that, which is often more than a year of committed cloud control-plane and node spend for a small team.

Now the cloud side. Azure savings plans advertise up to 65% off pay-as-you-go, and reserved VM instances up to 72% on three-year terms for some families (Azure savings plans, Azure reservations). The utilization math is the whole argument: idle metal is pure loss, while idle cloud capacity can be right-sized, autoscaled or stopped. Flexera estimates 27% of cloud spend is wasted, mostly on idle and over-provisioned resources (Flexera 2025 State of the Cloud). Pull the cheaper levers first, in order: right-sizing, committed-use discounts, cluster autoscaling, and auto-stopping non-production environments outside working hours. With Qovery the cloud account and all commitments stay in your name (BYOC), so every one of those discounts remains yours either way.

If you do run Kubernetes on your own hardware, who builds the developer experience?

You do, unless you install something that already does it. Bare metal gives you a cluster, not a platform. Developers still need self-service deploys, an environment per pull request, secrets, RBAC, safe rollbacks and cost visibility, and none of that arrives with the hardware.

Building it yourself is a real project. Humanitec's research on in-house internal developer platforms describes multi-quarter builds with dedicated platform teams, which is the opposite of what a team with no platform engineer has to spend (Humanitec State of Platform Engineering).

Here is where Qovery fits, and where it honestly does not. Qovery installs on your existing Kubernetes cluster (self-managed, on-prem, any distribution) or provisions into your own AWS, GCP, Azure or Scaleway account, and gives you git-push deployments, preview environments per pull request, environment auto-stop, managed cluster upgrades, per-environment RBAC and databases backed by managed cloud services. What it does not do is operate your hardware. It removes the developer-platform build, not the rack. That boundary is the point: Qovery is how you ship Kubernetes without a dedicated DevOps engineer, not how you avoid owning the metal you chose to own.

The hybrid pattern worth copying: run production on owned metal where it pays off, run preview and staging on managed cloud capacity, and give developers one identical workflow across both.

Evaluate it from Claude Code or Cursor

You can hand the evaluation and the first deployment to your coding agent. Install the Qovery Agent Skills once, then ask in plain language to deploy onto your existing Kubernetes cluster or your own Azure account. The agent proposes every action and waits for your approval before anything runs.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scope the install to the current project
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Enable write access only when you want it (also enable write in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills cover qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform, and the MCP Server then operates what already exists. From there you just ask, for example "deploy this app to my existing Kubernetes cluster with Qovery" or "set up a preview environment for every pull request." The AI agent quickstart and the Claude Code integration walk through the rest.

FAQ

Is AKS on bare metal Ubuntu production-ready today?

No. It is in public preview, which Microsoft states is excluded from SLAs and "not meant for production use," with best-effort support only and a possible delete-and-recreate at GA (Microsoft Learn).

Does running Kubernetes without a hypervisor make it simpler to operate?

No, it relocates the complexity. You gain direct hardware access and shed a few percent of virtualization overhead (StorageReview), but you take on firmware, provisioning, disk health, dead-node replacement and physical-reboot upgrades.

Can a team without a dedicated platform engineer run bare metal Kubernetes in production?

Only if the hardware is already racked and someone is already accountable for it on call. Buying hardware to get there means budgeting a platform hire or a partner, not just servers.

Is bare metal Kubernetes actually cheaper than managed AKS?

It wins on price per core and loses on total cost of ownership until utilization is high and sustained. Committed-use discounts, right-sizing, autoscaling and auto-stopping non-production environments (Flexera) are usually cheaper than buying machines.

What is the difference between AKS on bare metal Ubuntu, Azure Local, AKS enabled by Azure Arc, and AKS Edge Essentials?

AKS on bare metal Ubuntu runs Kubernetes directly on your Ubuntu servers with no hypervisor, Arc-managed. Azure Local is on-prem virtualization on validated hardware. AKS Edge Essentials is a lightweight single-device edge option. See the disambiguation table above and the Microsoft Learn overview.

What do I still have to build myself after I have a bare metal Kubernetes cluster?

Everything developers touch: self-service deploys, preview environments per PR, per-environment RBAC, managed database provisioning, safe rollbacks, environment auto-stop and cost visibility. A cluster is not a platform.

Can Qovery run on an on-prem or self-managed Kubernetes cluster, or only on a cloud provider?

Both. Qovery installs on your existing Kubernetes cluster, including self-managed and on-prem distributions, or provisions into your own AWS, GCP, Azure or Scaleway account. It does not operate your hardware.