Hetzner's ARM Discount Is Dead: the CAX-vs-CX Math for Your CAPH Fleet

For years, the cheapest way to run Kubernetes on Hetzner Cloud was obvious: pick ARM. The Ampere Altra-based CAX line gave you more vCPU and RAM per euro than the equivalent x86 SKU, so cost-conscious fleets — including Cluster API fleets provisioned through CAPH — standardized on cax31 and friends as the default worker type. That discount is now dead twice over.

ARM capacity in EU regions has been effectively unorderable since January, and after two 2026 repricings the ARM line costs roughly a third more than spec-identical x86. If your HCloudMachineTemplate still says type: cax31, you are paying extra for machines you often cannot even provision.

Here is the flip in one table, at current prices for new orders. Every row compares spec-identical tiers — same vCPU, RAM, disk, and 20 TB of traffic — for a typical small CAPH fleet: three control-plane nodes on the 4 vCPU / 8 GB class and five workers on the 8 vCPU / 16 GB class.

The worker tier — where the architecture default actually bites — now carries a 31% ARM premium (€20.99 over €15.99). Prices are current monthly rates excluding VAT and the €0.50/instance IPv4 fee, which applies equally to both sides and washes out of the comparison. The rest of this post is the evidence behind every cell: how the flip happened, the capacity story that hurts more than the price, what the wrong default costs at three fleet sizes, and the template pattern that survives the next catalog reshuffle.

How ARM went from cheaper to +31% in eighteen months​

Hetzner repriced cloud servers twice in 2026, and the two rounds hit different lines differently. On April 1, prices rose roughly 30–37% across all products, including existing subscriptions. On June 15, cloud servers rose again — this time for new orders and rescales only — with the shared lines (CX Intel, CAX ARM) up 30–40% while the AMD and dedicated lines were structurally repriced: CPX instances went up 2.4x to 2.75x and CCX dedicated-vCPU instances 2.1x to 2.73x in Germany and Finland.

Concrete June-15 moves include CCX13 from €15.99 to €42.99 (+169%), CPX22 from €7.99 to €19.49 (+144%), and CPX32 from €13.99 to €35.49 (+154%), while CX23 moved €3.99 to €5.49 (+38%) and CAX11 moved €4.49 to €5.99 (+33%). The stated cause is upstream hardware cost: global DRAM prices rose roughly 93–98% quarter-over-quarter in Q1 2026 as AI buildout consumed an estimated fifth of total DRAM production.

The ARM-vs-x86 flip predates the June round and survived it. In May, the nexus-stack project — a one-command Hetzner plus Cloudflare stack — documented the inversion in issue #491: at the spec-equivalent 8 vCPU / 16 GB / 160 GB tier, x86 CX43 cost €11.99/mo against ARM CAX31 at €15.99/mo. The project's shorthand called ARM "~40% more expensive"; the May pair itself measured +33%, and at today's post–June-15 prices (€15.99 vs €20.99) the worker-tier premium sits at +31%.

Either way, the direction is unambiguous, and it has now held across two repricings. One more rule matters before we get to fleets: servers ordered before June 15 keep their old rates — but any rescale, in either direction, moves that server to current pricing immediately. Keep that rule in mind; it interacts badly with rolling upgrades, as section four shows.

The capacity half: ARM EU stock dry since January​

Price is only half the story, and for operators it is the less painful half. A premium you can budget for; an unprovisionable server type breaks autoscaling, rolling upgrades, and disaster recovery without warning.

Nexus-stack hit this first and documented it best. Its May 2026 commit switching server defaults off ARM records that Hetzner ARM EU capacity had been unavailable since 2026-01-22 — roughly three and a half months at that point — with creates failing on error during placement (resource_unavailable) before any deploy code even ran. The project then made the switch permanent: its contributor docs state that nexus-stack defaults to x86 cx43 (8 vCPU / 16 GB / 160 GB in hel1) since May 2026 for two durable reasons, chronic ARM EU stock shortage and the flipped pricing, and the v0.55.0 release notes describe the move from ARM cax31 to x86 cx43 as the new default for sustained multi-stack workloads.

Independent operators confirm the drought lasted well beyond spring. Live API measurements on 2026-09-19 found every CAX type failing in every EU region with unsupported location for server type while cx33 creates succeeded in nbg1, fsn1, and hel1. By late September, even the cheap CX and CAX tiers intermittently showed unavailable, and since 2026-06-26 Hetzner has restricted server creation for new customers and some existing ones.

The honest reading is not "x86 is always in stock" — it is that no pinned server type is a safe assumption anymore, and the type most likely to be dry is the ARM one your templates may still pin. A CAPH controller has no built-in fallback: a MachineDeployment whose template pins an out-of-stock type just keeps failing reconciliation while your nodes age underneath it.

The sensitivity table: what the wrong default costs at three fleet sizes​

Section one showed the typical fleet. Here is the same math at three sizes, with each row naming its worker tier so the arithmetic stays checkable. Control-plane nodes stay on the 4 vCPU / 8 GB class (CX33 €8.49 vs CAX21 €10.49, delta €2/node) in all three rows.

Two things stand out. First, the premium scales linearly with workers at roughly €60 per worker per year on the 8/16 class — small enough to ignore on a hobby cluster, large enough to notice the moment you run a real tenant mix.

Second, the June-15 grandfathering rule has a CAPH-shaped hole in it: existing servers keep old rates, but a MachineDeployment rolling upgrade replaces machines, and replacement machines are new orders at current prices. A fleet that has not rolled since June may still be paying May rates today — and will step up to current rates on its next Kubernetes minor-version upgrade, Talos upgrade, or node-image rotation, whichever comes first. Budget the new prices from your next roll date, not from some hoped-for reversion. Nobody in the 2026 coverage expects price relief before mid-2027.

Templates that survive the next reshuffle​

The price gap will keep moving — DRAM markets, not Hetzner product managers, are driving it — and the stock picture already flipped once from "ARM always available" to "ARM never available" within a single year. The fix is to stop hardcoding the bet into your templates. CAPH's HCloudMachineTemplate takes the server type as a plain type string, and the standard clusterctl flow supports environment-variable substitution, so the reshuffle-proof pattern is three small habits, not a platform rewrite.

First, parameterize the type instead of pinning it:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCloudMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-worker
spec:
  template:
    spec:
      type: ${HCLOUD_WORKER_MACHINE_TYPE:-cx43}
      imageName: ${HCLOUD_IMAGE_NAME}
      placementGroupName: ${CLUSTER_NAME}-workers

With the type as a variable, switching the worker default from cax31 to cx43 is a one-line change to your cluster config and a template roll — the same motion as any other machine-template update — instead of a YAML archaeology expedition across every MachineDeployment you ever wrote.

Second, keep per-architecture MachineDeployments rather than one fleet-wide assumption. Even an all-x86 fleet benefits from a small ARM MachineDeployment (or just a retained, scaled-to-zero template) so that validating the other architecture is a replica-count change, not a rewrite, the next time prices or stock flip. CAPH reconciles each deployment's template independently, so mixed-architecture fleets are unremarkable as long as your workloads schedule correctly — which is where node labels and image architecture come in.

Third, check stock before you roll. A one-line hcloud query against the server-type's available locations tells you whether your target type is orderable in your region today; nexus-stack went further and built capacity-aware server selection directly into its deploy tooling after getting burned. Running that check in CI before a template roll converts a 3 a.m. resource_unavailable reconciliation loop into a daytime decision about which type to pin this quarter.

Keep shipping multi-arch images anyway​

Everything above argues for x86 defaults today, and none of it argues for amd64-only images. The stock and price picture flipped once; it can flip again — a single Ampere restock plus a DRAM correction would put ARM back in contention, and your fleet's architecture default should be a scheduling decision, not a rebuild-everything migration. Images that only run on one architecture turn a one-line template change into a weeks-long rebuild.

The cautionary tale comes, again, from nexus-stack: after the project switched its default from ARM to x86, one stack's Dockerfile turned out to hardcode an arm64-only download URL and broke on the new default. The fix was a multi-arch build. Buildpacks users are in better shape structurally — Paketo has been adding ARM64 support across its buildpacks, Java first with more languages following, and the CNB docs cover building ARM app images — but "my builder supports ARM" is a claim worth verifying rather than assuming: not every builder tag is multi-arch, and an amd64-only builder silently produces images that will never schedule on a future ARM pool. The check is one command against whatever builder you actually use:

docker buildx imagetools inspect --raw <your-builder:tag> \
  | grep -o '"architecture": *"[^"]*"' | sort -u

If the output lists both amd64 and arm64, your build output stays portable across whatever the catalog does next. If it lists only one, pin a multi-arch builder before you need it — the worst time to discover your images are single-arch is during the same incident that forces the architecture switch. Concretely: build with a builder you have verified, keep the arm64 variant even while every node you run is x86, and let Kubernetes scheduling (not image availability) be the thing that decides where workloads land.

The default to set this quarter​

To summarize: at current prices, an all-ARM CAPH fleet pays roughly €144–€672 more per year than the identical x86 fleet depending on size, for machines that have been intermittently unprovisionable in EU regions since January. Set your worker default to the CX line, parameterize the server type in every HCloudMachineTemplate, check stock before each roll, and keep your images multi-arch so the next flip costs you a config change instead of a migration. The catalog will reshuffle again — DRAM markets guarantee it — and the fleets that sail through are the ones that never hardcoded the bet.

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.