Hetzner's Second Price Hike of 2026: Why Your CCX Fleet Just Got 169% More Expensive

Hetzner Cloud was the cheat code for self-hosted PaaS economics — until June 15, 2026, when the cheat code split in two.

On that morning at 08:00 CEST, Hetzner applied its second price adjustment of the year. The headline most people repeated — "about 30 percent" — was only half true. Shared Intel CX and ARM CAX instances did rise about 30 to 38 percent. But dedicated vCPU CCX and shared AMD CPX instances, the two lines most production teams actually default to, more than doubled: CCX13 jumped 169 percent, CCX23 jumped 173 percent, and the CPX line rose 144 to 154 percent on top of an April increase that had already lifted every cloud line 30 to 37 percent.

If your Cluster API fleet's default MachineDeployment still says ccx13 or cpx32, its monthly burn just tripled while the box next to it in the catalog barely moved. "Self-hosted is cheaper" is still true — but for the first time, which Hetzner line you provision matters more than whether you self-host at all.

Here is the recompute, line by line, with the fleet totals early so you can decide before you read the why.

The answer up front: one fleet, two very different bills​

We priced the same reference fleet everywhere Hetzner lists it: EU regions (Nuremberg/Falkenstein/Helsinki), euros excluding VAT and excluding the €1-odd IPv4 add-on Hetzner now bills separately, post-June-15, 2026 rates from Hetzner's official price-adjustment page.

Pick a typical starting fleet — three worker nodes, the minimum for a useful HA Kubernetes control plane plus workload headroom — and a modest growth fleet of six workers. Each row is the monthly node-pool cost alone (compute, before volume or load balancer). Annual cost is just ×12. The delta is the price of staying on the wrong family.

* Pre-April estimates back-calculated from Hetzner's stated 30-37% April lift; April and June figures are from Hetzner's published tables.

Now multiply by a fleet:

In dollars for US regions the same CCX13 move was $19.99 → $50.99 (+155%) and CCX23 was $39.99 → $102.99 (+158%), so the fleet math translates almost one-for-one at ~€1.08/$.

Two things to read out of the table before we touch the why:

1. The April and June hikes compound. A CCX13 that cost roughly €12.40 at the start of the year costs €42.99 now — not 169 percent more, but about 247 percent more than you budgeted in January. Anyone whose "Hetzner is €16 for 2 vCPU" mental model froze after April is quoting a price that died in June.
2. The gap between families is now the whole PaaS arbitrage. A 6-node CCX13 fleet at €258/mo is suddenly in the same conversation as a managed-PaaS bill the Hetzner box was supposed to undercut by 5x. The same 6 nodes as CX33 or CAX21 stay at €81-93/mo — still the classic Hetzner discount, just on a different SKU. Family selection erased or preserved the advantage single-handedly.

That is the core deliverable the title promised. The rest of this post shows where those numbers come from, why only two families got hit that hard, and what to set your CAPH defaults to now.

What actually changed on June 15 — and what didn't​

Hetzner announced the adjustment in two parts.

April 1, 2026 was the broad lift. In a press-room statement dated February 19 and widely reported via Tom's Hardware and 365i, Hetzner raised Cloud servers, dedicated hardware, and object storage across the board by 30 to 37 percent, effective for every customer — new and existing. The company pointed to DRAM and NAND price shocks already showing up in the AI hardware supply chain. CX22 went €3.79 → €5.49 in some entries, CPX22 €5.99 → €7.99, CCX13 €12.40-ish → €15.99. If you re-ran your cost model after April, you already absorbed one repricing.

June 15, 2026 at 08:00 CEST was the second, surgical lift — and the one this post is about. Hetzner's docs page titled "Price Adjustment 15 June 2026" and the companion press-room post "Details regarding the standardization and price adjustment of our server products effective 15 June 2026" describe it as a standardization of the dedicated-server portfolio combined with a price adjustment for certain cloud lines on new orders and rescales only. Existing instances keep their old hourly and monthly rate unless you rescale them — a nuance that matters enormously for fleet operators and that billing pages quoting only the new price hide.

The official table (EU, monthly, excluding IPv4) reads:

Sources that include IPv4 quote slightly lower pairs — e.g. CCX13 €15.99 → €42.99 and CCX23 €31.49 → €85.99 are the excl-IPv4 EU numbers most fleet calculators use; a US-region CCX13 is quoted by Hetzner at $19.99 → $50.99. The percentage moves the same either way: 113 percent is the floor, 176 percent the ceiling reported by Gart Solutions' review of the full line, with the mid-tier production workhorses clustered at 144-173 percent.

Three caveats worth naming plainly so the table doesn't mislead:

• Renamed SKUs. The June standardization renamed some shared lines — old CPX11 became CPX22, CX22 became CX23 — so a tutorial quoting "CX22 at €3.79" is naming a plan you cannot buy at a price that hasn't existed since April. If your Terraform still references cpx11, it will fail on new orders, not just cost more.
• EU vs US pricing. Hetzner's US regions (Ashburn/Hillsboro) run higher absolute dollars and slightly different percentage lifts than EU, but the family ranking is identical: CCX/CPX triple, CX/CAX bump a third.
• Bandwidth is untouched. Every cloud server still includes 20 TB of outbound traffic with €1/TB overage after that. For a bandwidth-heavy app that was the reason you picked Hetzner in the first place, the storage/compute repricing hurts but the egress advantage over AWS/GCP's per-GB meters is unchanged — a point the "Hetzner got expensive" takes often omit.

The fleet math: wrong pool vs right pool​

A single-node quote doesn't tell you what a platform costs. A Cluster API fleet does. Here is a worked MachineDeployment comparison that mirrors how Bex and other CAPH-based platforms actually provision.

Scenario A — The default that just got expensive​

Assume a team bootstrapped in 2024 with the obvious default: dedicated vCPU for "production seriousness." Their Cluster.spec.infrastructureRef points at a HetznerCluster, and the worker MachineDeployment is:

# the default that now costs 2.5x
infrastructureRef:
  kind: HetznerMachineTemplate
  name: workers-ccx13
spec:
  template:
    spec:
      type: ccx13  # 2 dedicated vCPU, 8 GB — the "safe" pick last year

Three replicas of that template cost €46.47/mo in June pro forma versus €128.97/mo now — an extra €990 a year for the same three boxes. At six replicas the gap is €1,980 a year, before you add volumes, load balancers, or the control plane.

Scenario B — The same RAM on the right family​

Swap one field:

# same 8 GB RAM, shared vCPU — the right default for most stateless apps
      type: cx33  # 4 shared Intel vCPU, 8 GB — €15.49 post-June
# or, if your images are ARM-clean:
      type: cax21 # 4 shared ARM vCPU, 8 GB — €13.49 post-June

For a typical API + frontend + background worker that sleeps on I/O and spikes on fan-out, CX33 or CAX21 deliver equivalent user-visible throughput at a third of the CCX13 price. Dedicated vCPU matters when you pin a core — a Postgres primary, a game server tick, a video encoder that pegs the CPU at 95 percent wall-clock. It does not matter when your P95 CPU is 12 percent and you picked CCX because "shared feels risky."

The numbers:

• Stateless fleet, 6 nodes: CCX13 ×6 = €257.94/mo. CX33 ×6 = €92.94/mo. You save €165/mo (€1,980/yr) by switching family, not provider.
• Shared AMD fleet, 6 nodes: CPX32 ×6 = €209.94/mo. CAX21 ×6 = €80.94/mo. Save €129/mo (€1,548/yr). CAX41 (16 ARM vCPU / 32 GB) at €40.99/mo is the current value outlier for ARM-clean workloads — it barely moved in June and undercuts an 8-vCPU dedicated box at a quarter the price.

When CCX is still the right call​

Keep CCX for the narrow case it was designed for: workloads where you measured noisy-neighbor impact and proved shared hurts. That is usually one MachineDeployment in the cluster, not the whole node pool. A sensible split:

• Default pool (cx33 or cax21, 3-6 replicas) — all stateless apps, workers, ingress.
• Pinned pool (ccx13/ccx23, 1-2 replicas, tainted workload=pinned:NoSchedule) — only the Postgres primary, the persistent queue, or the single service with a latency SLO tied to core isolation.

You pay the CCX premium where it buys you something measurable, not as a fleet-wide tax.

The grandfathering trap​

Because June 15 only applies to new orders and rescales, an existing CCX13 provisioned in May still bills at €15.99 until you touch it. Rescaling that node — adding disk, changing type and back, or replacing it via a rolling CAPH update — snaps it to €42.99 with no warning in kubectl. Fleet operators doing a routine Kubernetes version bump that recreates machines have reported surprise bills for this reason. Pin your HetznerMachineTemplate type explicitly and treat a rescale as a pricing event, not just an API call.

Why CX and CAX survived and CCX/CPX didn't​

The press-room language and the DRAM market data behind it are unusually candid. Hetzner cited a global DRAM price surge of +171 percent year-over-year driven by high-bandwidth memory (HBM) demand for AI accelerators, compounded by NAND and NVMe tightness. 2026 infrastructure coverage from Gartner and 365i framed the same squeeze: AI data centers are power- and memory-bound, not just GPU-bound, and the spot price for server DRAM doubled while consumer SSDs rose 20-30 percent.

Why that hit families unevenly:

• CCX/CPX bundle the scarcest resource. Dedicated vCPU means a physical core (or hyperthread) is reserved for you whether you use it or not — that's more silicon and more DRAM per billable unit than a shared core that overcommits. Shared AMD (CPX) sits on EPYC silicon also favored for AI-adjacent hosts; dedicated (CCX) reserves it outright. When DRAM and NVMe spike, the SKU with the most reserved headroom absorbs the most cost.
• CX/CAX are the cost-optimized leftovers. Intel shared (CX) runs on older, abundant cores; ARM CAX runs on Ampere Altra, which is efficient and was deliberately priced as the loss-leader for ARM adoption. Both carry less DRAM per vCPU and were easier for Hetzner to keep near the 33-38 percent lift rather than the 113-176 percent the reserved families required.
• US vs EU amortizes differently. US regions carry higher power and transit costs and a smaller physical footprint for Hetzner, so the June increase translated to a slightly lower percentage there (+155% vs +169% on CCX13) but a higher absolute dollar. The EU catalog is the price anchor most Cluster API cost models use, and it's where the gap is widest.

None of this is Hetzner-specific moral hazard. It's the predictable end of a two-year window where Hetzner underpriced dedicated silicon relative to the memory market and then corrected in two steps — April for everyone, June for the reserved lines — instead of smearing one 80 percent lift across the whole catalog.

What this means for your CAPH defaults​

If you run a Cluster-API-managed fleet on Hetzner — whether via Bex, Cluster API Provider Hetzner (CAPH) directly, or a homegrown Terraform wrapper — three concrete changes pay for themselves this quarter:

1. Change the default MachineDeployment type. In your cluster template, set type: cx33 (Intel shared) or type: cax21 (ARM shared) as the worker default. Leave ccx13 only where a workload has a measured steady-CPU profile. This is a one-line diff in HetznerMachineTemplate that saves four figures a year on a six-node fleet, as shown above. If your images aren't ARM-clean yet (many agent CLIs and Docker images now are, but verify), start with cx33 and benchmark CAX in staging — the €2/mo per-node saving from CX33 to CAX21 is real but secondary to the €27/mo saving from CCX13 to either.

2. Treat rescale as a billing event. Add a pre-apply check in your GitOps pipeline that diffs HetznerMachineTemplate.spec.template.spec.type and warns when a rolling update would recreate grandfathered CCX/CPX nodes at June prices. Bex's own fleet templates now annotate this — bex fleet diff surfaces the per-node delta before you apply. If you must keep a CCX pool, cordon it so autoscaling doesn't silently replace it.

3. Budget the second-provider fallback the way Hetzner budgets capacity. Hetzner's status page has carried "limited availability" notices on several cloud lines through 2026, driven by the same hardware squeeze. A fleet that can only provision ccx13 in fsn1 has a second failure mode now: sold-out inventory on the expensive family plus a bill shock if it does provision. Keep a one-line fallback — a second MachineDeployment of cax21 in nbg1 or hel1 — so the autoscaler has somewhere to go that isn't just "pay more for the same box in the same DC."

The honest footnote is that Hetzner even after June remains the cheapest EU cloud for bandwidth-heavy workloads by a wide margin — 20 TB included versus per-GB egress on every hyperscaler — but the "cheapest compute" claim now requires an asterisk. On CX/CAX it holds. On CCX/CPX at post-June prices, a Vultr High Frequency or a Netcup RS 1000 G12 at €8.74/mo for 4 dedicated EPYC cores can undercut Hetzner on raw dedicated cores, though neither offers a mature Cluster API provider today. That is a cost-comparison footnote, not a migration plan, but it's the correct baseline to quote when someone says "Hetzner is always cheapest" without naming the family.

Self-hosted is still cheaper — when you pick the right box​

The lesson of the second hike isn't that self-hosting stopped saving money. It's that self-hosting stopped saving money automatically.

For two years the Hetzner arbitrage was so wide you could pick any family and still beat a hosted PaaS. After April and especially after June 15, the arbitrage lives entirely inside the catalog: choose CX or CAX and you keep the classic 5-10x advantage over metered platforms; stay on CCX or CPX and you gave most of it back to a DRAM market you never intended to bet on.

That's a healthier place for a platform to be — a default that requires one intentional choice is a better default than a price that only worked while memory was artificially cheap — but it does mean the next time you git push and a new node appears, the type string on that node is a budgeting decision, not just an infrastructure one.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Its default CAPH templates already pin the right family, so git push doesn't also push a surprise line item. Star the repo on GitHub or deploy your first fleet today.