Hetzner Doubled Your x86 Bill and Barely Touched ARM: The CAX Cost-per-vCPU Recheck

On June 15, 2026 at 08:00 CEST, Hetzner repriced its entire cloud catalog and the bill split in two. The Ampere Altra ARM line you probably ignored rose about 30 percent. The AMD and dedicated lines you probably run production on more than doubled — some nearly tripled.

Same provider. Same datacenter. Same 20 TB of included traffic. A 2 vCPU box on CAX now costs €5.99 a month; the same 2 vCPU on CCX 13 costs €42.99. That gap did not exist last year, and no pricing-page headline tells you it is there now. If your Cluster API fleet's default node pool is still on CPX or CCX out of habit, you are paying for a choice you never re-evaluated.

This is the recheck.

The answer up front: one vCPU costs wildly different depending on the letter in front of it​

Every price below is the post-June-15, 2026 monthly cap, euros excl. VAT, DE/FI regions, from Hetzner's official price-adjustment page (new orders and rescales; existing instances keep the old price until you touch them). The delta is old → new.

Three things jump out when you read it by column, not by row:

CAX and CX rose together, roughly a third. Every CAX tier moved 30-33%. Every CX tier moved 30-38%. That is the April-1-style correction — painful but proportional.

CPX and CCX left the chart. CPX tiers jumped 144-175%. CCX tiers jumped 113-173%. A CPX22 now costs 3.3× a CAX11 for the same 2 vCPU. A CCX13 costs 7.2× a CAX11. At 4 vCPU the spread is even starker: CCX23 is 8.2× the CAX21 per vCPU.

CX is still the cheapest at 16 vCPU, but CAX wins where most fleets live. At the small and medium tiers where a typical Kubernetes worker actually runs — 2 to 8 vCPU — CAX and CX trade the lead by cents per vCPU, while CPX sits 3-4× above both. The price-performance star is no longer "Hetzner is cheap." It is "Hetzner's ARM and Intel shared lines are cheap; its AMD and dedicated lines are a different vendor now."

The same pattern holds all the way up the catalog. The widely repeated "Hetzner went up about 30%" is true for CX and CAX and flatly wrong for CPX and CCX, where more than doubling is the rule, not the exception.

Why it was so uneven: the hardware bill underneath the price list​

Hetzner attributes the June adjustment to a "massive increase in procurement costs" and specifically to the same DRAM and NVMe squeeze every provider is absorbing. Industry coverage in June tied it to AI-driven demand for memory and flash — the same pressure that pushed DDR5 spot prices up through the spring and kept H100s power-constrained.

That squeeze does not hit all instance families equally:

• CAX (Ampere Altra, ARM64) uses fewer high-margin x86 dies per socket, lower per-core power, and a simpler memory footprint. It is also Hetzner's youngest line, with supply negotiated on a different cycle. Result: +30%.
• CX (Intel shared) is Hetzner's cost-optimized, contention-tolerated tier. It shares aggressively and commits fewer dedicated resources per tenant. Result: +31-38%.
• CPX (AMD EPYC shared) and CCX (dedicated) pin real cores and reserve memory bandwidth a tenant can actually saturate. When DRAM and NVMe spike, the lines that promise you can use every cycle you paid for are the lines whose cost base moves first. Result: +113-175%.

There is also a generational rotation hidden in the same date: CX22→CX23, CPX11→CPX22 and friends. If a runbook still quotes CX22 at €3.79, it names a plan you cannot order at a price that no longer exists. The index that tracks every Hetzner type against its source URL makes this explicit: a quoted price without a generation suffix and a verification date is stale by definition.

What the math does to a real fleet​

Pick the tier most Cluster API workers actually run: 4 vCPU / 8 GB (16 GB on dedicated). Here is what ten workers cost — the whole node pool, not one box.

The CAX vs CX gap at this tier is €10 a month for ten nodes — noise. The CAX vs CPX gap is €285 a month, €3,420 a year for the same ten slots in the same zone, same traffic allowance, same autoscaler. A 30-node growth stage multiplies that delta to roughly €850 a month. None of that delta buys more traffic, more disk, or a different SLA. It buys the same vCPU count on a line whose procurement cost spiked and stayed spiked.

At 2 vCPU the picture is similar: ten CAX11s run €59.90 a month; ten CPX22s run €194.90; ten CCX13s run €429.90. At 8 vCPU the CAX31 and CX43 are priced identically today at €19.49, while CPX42 is already €69.49 — 3.6× more per node.

Two caveats your model should carry:

Billing is hourly with a monthly cap. You pay per hour, rounded up, capped at the monthly price. For workers that run 24/7 the monthly cap is your number. For short-lived preview or CI nodes that live 20 hours a month, hourly math can change the ranking — but the 3-4× spread between CAX/CX and CPX survives even at hourly granularity because the hourly rates moved by the same percentages.

Regional footprint is not uniform. CAX and CX exist only in Falkenstein (FSN1), Nuremberg (NBG1), and Helsinki (HEL1). If you need Ashburn (ASH), Hillsboro (HIL), or Singapore (SIN), the only lines you can order are CPX and CCX — at higher list prices in those locations and with a smaller traffic allowance (1-8 TB in the US vs 20 TB in the EU for comparable size). Any EU-vs-US comparison must re-price in the target location; quoting the FSN1 price for an ASH node is a model error the official docs call out explicitly.

What actually runs on ARM without a rebuild​

The reason this lever is cheap to pull on a self-hosted fleet is that most modern workloads already are ARM-clean without anyone planning it.

The practical test is one command against your current registry: docker buildx imagetools inspect your/image:tag lists the platforms an image actually ships. In 2026 most base images — node:20, python:3.12, eclipse-temurin:21, golang:1.23, rust:1.80 — publish linux/amd64 and linux/arm64 side by side. If your image is FROM node:20-alpine, you are probably already multi-arch and just never scheduled it onto an ARM node.

What does not move without work: x86-only vendor binaries, images that ADD a prebuilt amd64 tarball, and anything that assumes amd64 in a RUN step (for example curl -LO https://example.com/tool-linux-amd64). Those are image bugs, not ARM bugs — they break the same way on any arm64 node, and the fix is a multi-arch build, not a different instance type.

Making CAX your Cluster API default​

On a Hetzner-provisioned fleet the switch is a field, not a migration. The Hetzner Cluster API provider (CAPH) takes a HetznerCluster plus HCloudMachineTemplate per node pool, so a fleet that defaults to CPX today can add a CAX pool alongside it or replace the default in one commit.

A minimal MachineDeployment swap at the 4 vCPU tier — CPX32 to CAX21 — looks like this:

# Before
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCloudMachineTemplate
metadata:
  name: workers-cpx
spec:
  template:
    spec:
      type: cpx32   # 4 vCPU / 8 GB, €38.99/mo
      imageName: ubuntu-24.04

# After — same RAM, same zone, 3.7× cheaper per month
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCloudMachineTemplate
metadata:
  name: workers-cax
spec:
  template:
    spec:
      type: cax21   # 4 vCPU / 8 GB, €10.49/mo, ARM64
      imageName: ubuntu-24.04

Roll it out as a separate pool first if you want a canary:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: workers-arm
spec:
  clusterName: prod
  replicas: 3
  template:
    spec:
      infrastructureRef:
        kind: HCloudMachineTemplate
        name: workers-cax
      # taint so only ARM-tolerant workloads land here during soak
      # remove once your DaemonSets and operators are verified arm64-clean

Three operational notes from fleets that already run this mixed:

Build arm64 alongside amd64 in CI. One docker buildx build --platform linux/amd64,linux/arm64 push is worth more than a wiki page about ARM readiness. Push a manifest list so the kubelet pulls the right arch automatically — no node selector needed for stateless services.

Verify your operators. cert-manager, ingress-nginx, cilium, metrics-server, and the CAPH controllers themselves all publish arm64 images. The outlier is usually a bespoke operator someone vendored as an amd64-only image. Inspect it the same way you inspect app images.

Do not casually rescale an existing CPX/CCX box. This is the trap the adjustment keeps. An existing cpx32 at €13.99 or ccx13 at €15.99 keeps that price — until you rescale it, at which point it reprices to €38.99 or €42.99. A routine kubectl scale through an autoscaler does not trigger it, but a HCloudMachineTemplate type change and rolling replacement does. Plan the rollout; do not hot-edit the size.

When to stay on x86 anyway​

ARM did not become universally better. It became situationally cheaper by a lot, which is different.

You need US or Singapore. CAX and CX do not exist in ASH, HIL, or SIN. If the requirement is "US-region node for latency or data-residency," your menu is CPX and CCX at US-priced rates with a lower traffic allowance. Quote the US price for that capacity plan, not the FSN1 price.

You need dedicated cores. For steady, CPU-pinned workloads that cannot tolerate noisy neighbors — saturated databases, predictable CI runners — the dedicated CCX line still has a scheduling guarantee CAX and CX do not. After June 15 that guarantee costs 3-7× more per vCPU, so the bar for "needs dedicated" got higher. Most HTTP services and background workers do not clear it.

You are bottlenecked on single-core IPC, not vCPU count. Ampere Altra trades per-core clock for core count and efficiency. For wide, parallel services it is excellent. For a single-threaded hot loop that already saturates one core, an x86 shared tier can still win on wall-clock time. Benchmark the actual hot path before committing a whole pool.

Your catalog is x86-only and will stay that way. If a vendor contract ties you to a closed x86 binary with no arm64 build on the roadmap, the cheapest correct answer is the cheapest x86 shared tier that meets the RAM and traffic need — today that is usually CX, not CPX.

The lever a fleet owner has and a managed-tenant does not​

A platform that bills you per vCPU-second or per workspace cannot pass an ARM vs x86 price gap through to you as a choice. It absorbs the hardware market into one blended rate, and when its own procurement cost spikes, your invoice rises with nothing to switch. You cannot tell Render "schedule this service on the ARM pool" or tell Vercel "run these functions on the cheaper silicon." The abstraction is the product.

A fleet you own under Cluster API inverts that. The instance type is a field in a template. The price delta — €285 a month for ten 4-vCPU nodes between CAX and CPX, €3,420 a year before you grow — is a line you can act on in one PR, one clusterctl move, one rolling replacement. No migration to a new vendor, no re-platform, no egress toll to leave. The same API that provisions the fleet reprices it.

That is the whole point of the June 15 numbers. The hike did not make Hetzner expensive. It made the choice of Hetzner line load-bearing. Treating "Hetzner pricing" as one number — the habit most cost models still have — now mispredicts by 2-3×. Carrying four numbers and a default — CAX first, CX as the EU cost floor, CPX/CCX only when the workload earns the premium — is the model that matches the catalog as it actually ships today.

If you run a Bex fleet, the default to revisit is spec.type in your HCloudMachineTemplate and the image platforms coming out of buildx. If you have not looked at that field since before April 1, June 15 quietly changed what it costs.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. It provisions the same Hetzner fleet this post just repriced, under Cluster API, with a Render-compatible API and an MCP server your agent can call today. Star the repo on GitHub or ship your first app and let the scheduler pick the cheap silicon.

Sources​

• Hetzner Docs — Price Adjustment 15 June 2026 (effective 08:00 CEST, new orders and rescales; existing instances keep old price; generated-type rotation CX22→CX23, CPX11→CPX22).
• Hetzner Pressroom — Standardization and Price Adjustment of Our Server Products, 15 June 2026.
• PrivateDevOps — Hetzner More Than Doubled Some Cloud Prices Today and What To Do About It (June 15, 2026) — full old→new table and rescale trap.
• GartSolutions — From Azure to Hetzner: Why European Companies Are Switching in 2026 — portfolio-wide 30-37% April 1 context and 33-38% CX/CAX vs 107-204% US CPX/CCX framing.
• The Stack Technology — Hosting Firm Hetzner Hikes Prices Sharply Amid Supply Chain Pain (June 15, 2026).
• CostGoat — Hetzner Cloud VPS Pricing Calculator (Aug 2026) — instance specs, traffic allowances by region, monthly-cap billing model.
• vps-gpu-price-index — Open price index tracing every Hetzner row to its source URL and verification date; documents per-line increases (e.g., CPX22 +144%, CCX13 +169%).
• Hetzner Cloud — Server Types & Pricing (hetzner.com/cloud).