Cloud-managed Kubernetes is the default. Bare-metal Kubernetes is the choice when the cloud's tradeoffs do not work for you. The reasons to choose bare metal are specific — predictable costs, hardware control, latency, compliance — and the operational work is substantial.
This post is when bare-metal Kubernetes is the right call, what it actually involves, and the costs that the cloud-vs-bare-metal comparisons usually understate.
What Counts as Bare Metal
"Bare metal" here means: physical servers you control, running Kubernetes directly on the OS. The cloud's hypervisor is not in the picture. Could be:
- Servers in your own data center
- Servers in a colocation facility
- Bare-metal cloud offerings (Equinix Metal, OVH bare metal, Hetzner dedicated)
- On-premises hardware
The common thread: you (or your provider) own physical hardware, and Kubernetes runs directly on it.
Why Bare Metal
The legitimate reasons people choose bare metal:
Cost. At sustained high utilization, dedicated hardware is dramatically cheaper than equivalent cloud capacity. A $5,000 server amortized over three years is $138/month. The cloud equivalent (a hefty VM running 24/7) might be $1,000/month.
Performance. No hypervisor overhead. Direct hardware access. Specific NICs, GPUs, or storage that the cloud does not offer.
Compliance and sovereignty. Some regulators require data to live in specific physical locations under specific operational control.
Hybrid integration. Connecting Kubernetes to existing on-prem systems that cannot easily move to the cloud.
Network requirements. Specific switching, custom protocols, or peering arrangements that public clouds do not support.
Vendor lock-in avoidance. Strategic value in not being captive to any one cloud.
For most teams, the first reason is the main one. The cost difference at scale is the driver.
What Bare Metal Costs
The cost equation is not just hardware. Real costs:
Hardware: purchase or lease. Plan for 3-5 year refresh cycles.
Colocation or data center: power, cooling, rack space. $200-$1,000/month per rack depending on density and region.
Network: transit costs, peering, hardware switches. Variable; meaningful at scale.
Operations team: humans to provision, repair, and maintain hardware. The biggest hidden cost.
Redundant infrastructure: UPS, generators, multiple ISPs. Required for production reliability.
Time: hardware procurement takes weeks. Capacity additions are not instant like the cloud.
When all costs are tallied, bare metal is cheaper than the cloud at scale — but the threshold is higher than people think. A small team with 10 servers may not save money vs the cloud after operational overhead.
What Cloud Provides That You Have to Replace
The work that goes into running Kubernetes on bare metal:
Load balancing. Cloud LBs (ALB, GLB) do not exist. You need MetalLB, Cilium Service Mesh, or a hardware LB.
Storage. No EBS or Persistent Disks. You need Longhorn, Rook (Ceph), OpenEBS, or a SAN.
Networking. No managed VPC. You configure switches, routes, BGP. Calico or Cilium handle the cluster-internal networking.
DNS. No Route 53 equivalent. You set up CoreDNS plus external DNS for public-facing.
TLS. No ACM. cert-manager with Let's Encrypt or your own CA.
Container registry. No ECR. Harbor, GitLab Container Registry, or hosted.
Auto-scaling. No managed autoscaler. Cluster Autoscaler against your own hardware pools, with limits on physical capacity.
Backups. No managed backup. Velero plus offsite replication.
Identity. No IRSA or Workload Identity. You bring your own identity solution.
Every one of these is a real project. None are individually impossible, but they accumulate.
The Hardware Layer
What hardware you actually buy:
- Compute nodes: 2-socket servers with 32-64 cores, 256-512GB RAM. Optimized for VM density.
- Storage: NVMe SSDs locally, plus separate storage servers if using distributed storage.
- Network: 25 GbE or 100 GbE for high-density clusters; 10 GbE is the minimum.
- Top-of-rack switches: managed, with support for the protocols you need (BGP, VXLAN, etc.).
- Power and cooling: redundant power supplies, environmental monitoring.
For Kubernetes specifically, the patterns favor "many smaller servers" over "few giant servers." Failure of one server is less impactful when nodes are smaller.
Network Architecture
The networking model is the most consequential bare-metal design decision.
Layer 2 (single subnet). All nodes in one large VLAN. Simple, limits scalability and broadcast domains.
Layer 3 (BGP-based). Each rack or each node advertises its pods via BGP. Calico and Cilium both support this. Scales to large clusters.
Overlay (VXLAN, Geneve). A logical network on top of the physical. Easier to manage, has encapsulation overhead.
For small clusters (under 20 nodes): Layer 2 is fine. For larger: Layer 3 or overlay. The right choice depends on the network team's preferences and what the underlying switches support.
Storage Options
The storage problem is the hardest part of bare-metal Kubernetes.
Local storage with replication at the app layer: databases that replicate (Postgres with replicas, MongoDB clusters) can use local SSDs on each node. Fast, simple, but the app handles availability.
Distributed block storage (Longhorn, Rook-Ceph, OpenEBS): Kubernetes-native, replicates data across nodes. Operationally complex; performance depends on the network.
NFS server: simple for shared file storage; single point of failure unless you build HA.
SAN/external storage: dedicated storage appliance. Expensive, mature, the enterprise default.
For most bare-metal Kubernetes deployments: Longhorn is the right starting point. It is Kubernetes-native, handles replication, and is operationally feasible.
For workloads with serious performance needs: local storage with app-level replication. A Postgres cluster on local NVMe outperforms any distributed storage for the same workload.
Cluster Bootstrap
How you actually install Kubernetes on bare metal:
kubeadm: the official tooling. Manual but well-documented. Most popular for self-managed setups.
k3s: lightweight, single-binary. Good for small or edge bare metal.
Cluster API for bare metal: provisions clusters declaratively. Multi-cluster capable but operationally heavier.
Talos Linux: an immutable Linux distribution designed for Kubernetes. Strong choice for "we run Kubernetes and nothing else."
For most teams: kubeadm or Talos. The trade is between conventional Linux (kubeadm on Ubuntu) and Kubernetes-purpose-built (Talos).
Operational Patterns
Patterns that hold up:
Treat hardware as cattle. Servers that fail are replaced, not nursed back to health. Spare capacity allows this.
Automate everything. PXE boot, automated OS install, automated cluster join. Manual node provisioning does not scale.
Monitor hardware. Disk SMART, network interface errors, temperature, power. Hardware failure is your problem now.
Spare hardware on the floor. When a server dies, the replacement should be ready, not ordered.
Document the runbooks. "How to replace a failed node" should be a written procedure, not tribal knowledge.
These patterns are second nature in data center operations. They are unfamiliar to teams that have only used the cloud.
When Bare Metal Is Wrong
Specific cases where the cloud is dramatically better:
- Variable workloads with frequent capacity changes. Bare-metal capacity is fixed; bursting requires cloud or overprovisioning.
- Geographic distribution. Multi-region bare metal is dramatically more expensive than multi-region cloud.
- Small team. Bare-metal operations is a real job that does not fit "we have one person who knows infrastructure."
- Short time horizon. The setup cost of bare metal does not amortize over months; it needs years.
If any of these apply, the cloud is probably the right answer despite higher per-unit costs.
The Hybrid Reality
Most bare-metal Kubernetes setups in 2026 are part of a hybrid:
- Bare metal for steady-state, predictable, performance-critical workloads
- Cloud for bursting capacity, experimentation, geographic distribution
The split is not 100/0 in either direction. It is "use each for what they are good at."
A Practical Path
For a team considering bare metal:
- Be honest about the cost math. Cloud costs and projected bare-metal costs over 3 years, including operations.
- Pilot in a non-critical environment. Build a non-production cluster on bare metal. Operate it for 6 months. See what breaks.
- Build the operational discipline first. Monitoring, runbooks, on-call. Bare metal exposes operational gaps faster than the cloud.
- Migrate workloads gradually. The right workloads (steady-state, performance-sensitive) move first. The rest stays in the cloud.
This is a multi-year journey, not a sprint.
When Bare Metal Wins
For the right team and the right workload:
- 60-80% cost savings on compute
- Performance that the cloud cannot match (specific hardware)
- Operational predictability (no surprise cloud bills)
- Compliance with strict data residency requirements
The teams that do this well treat bare metal as a strategic capability, not a cost-cutting tactic. The investment is real; the payoff at sustained scale is also real.
For most teams, the cloud is still the right answer. For a specific set of teams with specific workloads, bare metal becomes the differentiator that lets them operate economically at scale.
Evaluating bare-metal Kubernetes for a workload that has outgrown cloud economics? We help teams scope the actual cost and operational implications before they commit. scopeforged.com