Hetzner After the June 2026 Price Hikes: Auction Metal vs Cloud VMs as Kubernetes Fleet Nodes

A whole dedicated server now costs less than one small cloud VM. Hetzner's June 15, 2026 price adjustment pushed the 2-vCPU dedicated cloud instance (CCX13, 8 GB RAM) to €42.99 a month — while the Server Auction lists the AX42, a full 8-core Ryzen box with 64 GB of DDR5 ECC RAM and 1 TB of NVMe, at €46. Same monthly price. Eight times the RAM, a whole physical CPU, and a terabyte of local NVMe. The AX41-NVMe, with 64 GB RAM and 2x512 GB NVMe, goes for around €37 — cheaper than that single cloud VM.

That gap is the whole story for anyone running a self-hosted Kubernetes fleet on Hetzner in the second half of 2026. But the auction price is only half the math. A dedicated box is not a cloud API call: you cannot provision it from Terraform in 90 seconds, the autoscaler cannot create one, and replacing a dead one means a support ticket, not a controller loop. This post does both sides of the accounting — the euro-level capacity comparison, the operational tradeoffs of running Cluster API nodes on auction metal, and which fleet roles each kind of machine actually fits.

What June 15 changed​

Hetzner's price adjustment took effect for new orders and rescales on June 15, 2026 at 8 AM CEST, documented under ID GE-D9256. It was the second broad increase of the year — an April 1 round had already raised cloud prices by up to 37% — and it landed very unevenly across product lines.

The dedicated and performance tiers took the real hit:

Prices are net EUR per month for Germany/Finland, excluding VAT and IPv4. The pattern is clear: the cost-optimized shared CX and ARM CAX lines rose about a third, while the dedicated-vCPU CCX and performance CPX lines — the machines production workloads actually run on — roughly tripled.

The same rotation deprecated the old CX22/CX32 generation outright: the hcloud API now rejects provisioning calls against those types, so anything pinned to them has to move to the CX23/CX33/CX43 generation anyway. If you are re-pinning instance types this year, you are repricing at the same time — which is exactly why the auction comparison matters now.

The auction math, honestly computed​

The Server Auction (formerly Serverbidding) sells previous-generation dedicated machines on Dutch-auction pricing: the longer a box sits unsold, the cheaper it gets. Two current staples:

Now put those next to the cloud equivalents on a per-GB-of-RAM basis, which is the binding constraint for most fleet worker nodes:

Two ratios fall out. Against shared-vCPU cloud, auction metal is about 1.5x cheaper per gigabyte — a real but modest win, and the shared instance still has the smaller absolute bill. Against dedicated-vCPU cloud, auction metal is roughly 7.5x cheaper per gigabyte, with a whole physical CPU and a terabyte of local NVMe attached. To assemble 64 GB of dedicated cloud RAM you would spend several hundred euros a month; the auction gives it to you for €46.

Three honesty adjustments before you act on that table. First, auction machines carry a one-time setup fee, listed per box and typically in the tens of euros — amortized over a year it adds a few euros a month, not enough to change the ranking but not zero either. Second, auction prices float: the Dutch-auction mechanism means today's €46 box can be €52 or €41 next week, and the exact configuration you want may simply be out of stock. Third, granularity cuts the other way at small scale: if one tenant needs a single 8 GB node, a €8.56 CX33 beats a €46 box eight times over. The auction wins when you can fill — or bin-pack across tenants — tens of gigabytes per machine. A multi-tenant fleet node almost always can; a side project cannot.

What you trade away: provisioning, networking, and failure handling​

The capacity math is the easy half. The harder half is operational: a dedicated server is a fundamentally different object than a cloud VM, and every layer of fleet automation feels the difference.

Provisioning is a purchase, not an API call. Cloud VMs come from the hcloud API: Terraform, Cluster API Provider Hetzner (CAPH), or a dashboard click returns a running machine in about a minute. Auction boxes are ordered through the Robot console by a human. The Robot web service API (robot-ws.your-server.de) manages servers you already own — rescue boot, hardware resets, firewall rules, rDNS, SSH keys — but it does not sell you a new machine. Your provisioning pipeline gains a manual step at the very start that no controller can close.

OS install means rescue mode, not cloud-init. A fresh auction box boots into Hetzner's rescue system, and the OS goes on via installimage, Hetzner's scripted installer. There is no cloud-init datasource handing the machine its identity at first boot the way a cloud VM gets one. CAPH does bridge most of this gap for day-to-day operations: its HetznerBareMetalHost CRD models each dedicated server as a Cluster API object, drives the rescue-SSH-to-installimage flow, and reconciles the machine into the cluster declaratively. Once a box is registered, it behaves like any other CAPI machine. But registration itself — buying the box, recording its Robot credentials, creating the CRD — stays a human workflow, and community tooling like caphcli exists precisely because validating that handoff is fiddly enough to deserve its own CLI.

There is no autoscaler for metal you do not have. The cluster-autoscaler pattern assumes an API that mints nodes on demand. Fixed auction hardware cannot scale out under load or scale to zero overnight. Capacity planning reverts to the old discipline: provision for peak plus headroom, and eat the idle cost. At €0.72 per GB that idle cost is cheap — which is exactly why the auction math still wins for baseline capacity — but a spiky tenant that needs 10x burst for an hour a day wants cloud burst nodes, not a permanently idle second rack of metal.

Failure replacement is a ticket, not a reconcile loop. When a cloud VM dies, the controller deletes it and a fresh one appears in minutes. When an auction box loses a disk, the sequence is: notice, open a ticket, wait for Hetzner to swap hardware, reboot into rescue, reinstall via installimage, rejoin the cluster. The mirrored NVMe pairs in the AX41/AX42 (2x512 GB, RAID-able) blunt the most common failure mode, and CAPH's MachineHealthCheck support still evicts workloads off the dead node — but the node itself comes back on human timescales, measured in hours, not controller timescales measured in minutes. Size control planes and stateful pools so that one box being gone for a day is an inconvenience, not an outage.

Networking is cloud-native first. Cloud private networks, floating IPs, and the managed load balancer attach to cloud VMs with a checkbox. Dedicated servers join that world through a vSwitch uplink — an extra, billable construct to provision and a second network topology to document. It works, including pointing cloud load-balancer targets at bare-metal addresses (CAPH even carries patches for the address-family edge cases), but every "just attach the LB" moment in your runbook needs its bare-metal variant written down. And geography constrains you: the auction is Germany and Finland only. Tenants needing US or Singapore presence stay on cloud VMs regardless of the math.

None of these is disqualifying — every one of them is the normal price of bare metal, and fleets have paid it for decades. The mistake is pricing the metal like cloud and then being surprised that it does not behave like cloud.

Which fleet roles fit which metal​

With both sides accounted for, the assignment practically writes itself. The rule of thumb: auction boxes for stable, fillable, long-lived capacity; cloud VMs for elastic, granular, or geographically spread capacity.

The pattern this converges on is hybrid by default: a floor of auction metal carrying everything predictable, with cloud VMs as the elastic margin. In Cluster API terms that is two machine pools under one management cluster — CAPH reconciles both, HetznerBareMetalHost for the owned boxes and HCloudMachine for the burst tier — with the autoscaler enabled only on the cloud pool. Size the metal floor at roughly your p50 load and let the cloud tier absorb everything above it. The June price hikes actually sharpen this split: burst on shared CX/CAX instances rose only ~33%, so the elastic margin stayed cheap, while the always-on dedicated capacity that tripled is precisely the shape the auction replaces.

One operational footnote for the hybrid design: keep the two pools' failure domains explicit. A dead auction box heals in hours, a dead cloud VM in minutes — so never let a quorum or a single-replica stateful set depend on exactly one specific dedicated server. The metal is cheap enough to run N+1; the correct response to slow repair times is redundancy you can afford, not repair times you cannot change.

The bottom line​

Hetzner's 2026 repricing inverted the default answer. Before June, a €15.99 dedicated cloud VM was cheap enough that reaching for auction metal was an optimization. At €42.99 for 2 vCPUs and 8 GB, the default flipped: a €46 box with 64 GB of ECC RAM and a terabyte of NVMe is now the obvious home for every stable gigabyte in the fleet, and cloud VMs are the tool you reach for when you need elasticity, granularity, or geography that metal cannot give you.

Run the numbers for your own fleet's fill rate — if your worker nodes average even half of 64 GB utilized, the auction wins by multiples. Then budget the real cost honestly: a human in the provisioning loop, rescue-mode installs behind CAPH's declarative veneer, hours-long hardware repair, and a vSwitch between your metal and your load balancers. That is a good trade at 7.5x per gigabyte. It is just not a free one.

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.