CAPH's Bare-Metal Hetzner Robot Servers vs Cloud VMs: The Real Cost Delta on a Cluster API Node Pool

Somewhere on the "self-hosted PaaS" side of the internet, "40% cheaper" has become the accepted number for what a Hetzner Robot bare-metal box saves you over an equivalent Hetzner Cloud VM. Run the actual, RAM-and-core-matched numbers after 2026's cloud price hikes, and the real figure is 4.2x to 5.6x — not 40%. An AX42 dedicated server (8 cores/16 threads, 64GB ECC RAM, 512GB usable NVMe RAID1) costs about €49/month all-in. A CCX43 cloud VM with the identical 64GB of RAM and matching 16 vCPUs costs €275.99/month at Hetzner's post-June-2026 pricing. That's not a rounding error in a spreadsheet — it's the difference between a Cluster API Provider Hetzner (CAPH) fleet that treats bare metal as a footnote and one that treats it as the default.

The catch is that CAPH doesn't make that decision for you. It's perfectly happy provisioning either a Hetzner Cloud VM or a Hetzner Robot dedicated server as a node in the same Kubernetes cluster — but nothing in its API tells you which workloads belong on which side of that line, and the operational cost of getting it wrong isn't billing, it's a three-day wait for a database node that needed to exist an hour ago. This is the concrete comparison, and the concrete decision rule, that's actually missing from most "just use bare metal, it's cheaper" advice.

The Matched-Spec Price Table​

Most bare-metal-vs-cloud comparisons fail before they start, because they compare a dedicated server's raw core count against a cloud VM's vCPU count — an apples-to-oranges number that mechanically flatters whichever side has more of the bigger unit. The comparison below matches on RAM first, thread/vCPU count second — the two dimensions CAPH actually schedules against — and shows two tiers so the ratio isn't a cherry-picked single data point.

Tier 1 — 64GB RAM class:

Tier 2 — 128GB RAM class:

Ratio, Tier 1: 5.6x. Ratio, Tier 2: 4.2x. Even amortizing the one-time setup fee over a conservative 12 months (stretch it to the 24–36 months a dedicated box actually stays in service, and the ratio only widens), the dedicated side wins by a factor, not a percentage — on RAM- and thread-matched hardware, not a lopsided comparison.

Why did the gap blow past "40%" specifically in 2026? Hetzner's own June 15, 2026 price adjustment raised CCX-line (dedicated vCPU) cloud pricing 2.1x–2.73x in Germany and Finland, on top of an already-steep April 1 increase — driven by the same AI-datacenter DRAM and NAND demand squeezing memory and storage costs industry-wide. Dedicated-server pricing on the Robot side moved far less in the same window. Both sides of this market got more expensive in 2026; they did not get more expensive at the same rate, and the gap between them is now structural, not incidental.

What Bare Metal Doesn't Give You for Free​

None of that is a reason to default every node pool to Robot servers, because the price table above hides the operational cost that makes bare metal a genuinely different kind of resource, not just a cheaper VM:

• Provisioning takes 1–3 business days, not seconds. A Hetzner Cloud VM boots in the time it takes an API call to return. A Robot dedicated server has to be racked, imaged, and network-configured by Hetzner before CAPH's controllers can even start reconciling it. You cannot autoscale a bare-metal node pool in response to a traffic spike — the spike will be over before the hardware exists.
• Registration is manual and exact. A HetznerBareMetalHost maps one-to-one to a physical server you register by hand, pointing at a serverID from the Hetzner Robot dashboard. The SSH key name in the robot-ssh secret has to match, character for character, what's registered in Hetzner Robot — a mismatch doesn't error loudly, it just leaves the controller stuck reaching for a machine it can't authenticate to.
• Hosts persist independent of any one cluster. A HetznerBareMetalHost isn't scoped to a HetznerCluster — the same physical host can sit "available," get claimed by a HetznerBareMetalMachine, get released back to "available" when that machine is deleted, and get claimed again by a different cluster later. That's a feature for fleet-wide reuse, but it means deleting a host requires first parking it in maintenance mode so nothing is actively consuming it — you can't just delete a bare-metal machine the way you terminate a cloud VM.
• There's no live resize. Outgrow a cloud VM's RAM and you rescale it. Outgrow a dedicated server's RAM and the only path is provisioning a new one and migrating — which means eating the 1–3 day lead time again, at the worst possible moment: after you've already discovered you're out of capacity.

This is the real trade the price table doesn't show: bare metal is cheaper per unit of RAM and compute, but it's inventory, not elastic capacity. A CAPH fleet that wants the Tier 1/Tier 2 savings above has to hold bare-metal nodes as a pre-provisioned warm pool sized ahead of demand — the opposite of the just-in-time scaling that makes cloud VMs convenient in the first place.

Why Disk-Heavy Workloads Skew the Math Further​

The "bare metal is better for disk-intensive workloads" claim needs a real number behind it too, because Hetzner's cloud VMs aren't running on slow storage — their local NVMe RAID10 benchmarks around 40.9k 4k-random IOPS and 1.54–3GB/s sequential throughput, which is genuinely fast. The bare-metal advantage isn't "cloud disk is bad." It's three narrower, still-real things:

1. No noisy neighbor on the I/O bus. A cloud VM's NVMe throughput is a share of the physical host's total I/O capacity, split across every other tenant's VM on that host. A dedicated server's NVMe bandwidth belongs to exactly one workload, all the time — the number on the spec sheet is the number you actually get under load, not the number you get when nobody else on the box happens to be busy.
2. ECC RAM as standard, not an upsell. Both AX42 and AX102 ship ECC memory. For a stateful workload — a Postgres primary, in particular — a flipped bit that ECC catches and a flipped bit that silently corrupts a page are the difference between a logged correction and a support ticket you can't explain.
3. Newer NVMe generations land on dedicated lines first. Hetzner's current AX-series servers ship Gen4 NVMe (Gen5 on newer configurations); cloud tiers standardize on whatever generation the shared host fleet runs, which lags the dedicated lineup by design.

Concretely: a tenant's Postgres primary sharing a CCX43's I/O bus with three bursty, CPU-bound co-tenants on the same physical host will see its p99 write latency spike exactly when those neighbors spike — a failure mode that doesn't exist on an AX42, because there are no neighbors. That's the case for putting the database on bare metal even before the 5.6x price delta enters the conversation.

The Decision Rule for a Mixed Node Pool​

Put the cost table and the operational trade-offs together and the rule for a CAPH-managed fleet is straightforward:

Bare-metal (Robot) node pool — for workloads that are stateful, disk-heavy, and roughly constant in size:

• Tenant Postgres/MySQL primaries and other stateful databases
• Any tenant whose disk I/O profile is large enough that noisy-neighbor variance shows up in their own latency graphs
• Sized as a warm pool held slightly ahead of forecasted demand — not scaled to exact current usage, because there's no such thing as scaling a bare-metal pool "just in time"

Cloud VM node pool — for workloads that are elastic, bursty, or genuinely disposable:

• Stateless application tenants that autoscale with traffic
• CI/build workers, preview environments, anything spun up and torn down inside a single deploy cycle
• Any workload where the value of scaling to zero (or scaling up in seconds) outweighs the per-unit cost premium

In CAPH terms, this is two node pools in the same management cluster, not two clusters: one MachineDeployment referencing an HCloudMachineTemplate for the elastic pool, a second referencing a HetznerBareMetalMachineTemplate for the pinned, disk-heavy pool. Both reconcile under the same HetznerCluster, the same Cluster API contract, the same self-healing loop — the split is a scheduling and node-pool-selection decision, not a second control plane to operate.

What a Self-Hosted PaaS Should Actually Expose​

The gap most self-hosted PaaS tooling leaves open is that this decision is invisible to the tenant. A team deploying a disk-heavy database gets bin-packed onto whatever node pool has capacity, with no signal that a bare-metal pool would cost the platform (and, transitively, the tenant) a fraction of what a cloud-VM pool costs for the identical workload. The fix isn't automatic migration — moving a stateful tenant to bare metal still costs the 1–3 day provisioning lag — it's a visible cost/latency indicator at deploy time: this workload's I/O profile matches the bare-metal pool; expect a longer initial provisioning window and a materially lower steady-state cost. That's the concrete thing a Cluster-API-based platform can automate that a flat, cloud-VM-only fleet structurally can't: not a magic price cut, but giving a tenant enough information to choose which side of the ratio their own workload sits on.

This is close to the exact problem Bex.co is built around — a Cluster API fleet running on owned Hetzner hardware, where node-pool placement is a scheduling decision the platform makes visible instead of a cost buried in an invoice. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

The Gap Widens From Here​

Hetzner's cloud pricing moved twice in 2026 already, both times upward, driven by a DRAM and NAND shortage that IDC has characterized as a permanent reallocation of memory supply toward AI infrastructure, not a cyclical squeeze that eases on its own. Dedicated-server pricing has absorbed the same input-cost pressure far more slowly. There's no structural reason to expect that gap to close in the next repricing cycle — if anything, a self-hosted platform's default node-pool math should assume the 4–6x delta this piece measured today is closer to a floor than a ceiling for how much bare metal will save over cloud VMs by the time the next Hetzner price adjustment lands.

Sources:

• Hetzner Price Adjustment 15 June 2026.
• AX42 Dedicated Server.
• AX102 Dedicated Server.
• Hetzner CCX and CPX: the Price Increases — webhosting.today.
• Hetzner cloud server price increases in 2026: full breakdown — Northflank.
• CCX43 specs — Spare Cores.
• CCX53 specs — Spare Cores.
• HetznerBareMetalHost reference — CAPH docs (syself/cluster-api-provider-hetzner).
• Hetzner Cloud Review 2026: Benchmarks, Pricing, and the Real Trade-offs — Better Stack Community.