Back to Blog

Hetzner Repriced. Here Is the Math for Your Kubernetes Cluster.

10 min read
On this page

On June 15, 2026 at 8 AM CEST, Hetzner’s new cloud prices took effect. If you run Kubernetes on the CPX or CCX families, the numbers are not subtle: a CCX23 in Germany went from €31.49 to €85.99 a month, a CPX41 in the US regions went up 209 percent, and the CCX33 that a lot of teams use as their default worker node went from €62.49 to €138.49. The cost-optimized CX and Arm-based CAX lines got off lighter, up roughly 30 to 38 percent.

The increase applies to new orders and rescales. Servers you already had before June 15 keep their old price until you resize them, which turns out to matter for how you should react.

Plenty of teams built their entire infrastructure story on “Hetzner is a fifth the price of AWS.” Those teams just got a letter reminding them that a price is a snapshot, not a contract. This post does three things: works the actual numbers for what a production cluster costs today, explains why the panic takes are wrong, and makes the argument the incident actually supports. The lesson is not “find a cheaper provider.” The lesson is “never build in a way that makes repricing your problem alone.”

The new numbers, without the outrage

All prices are Germany/Finland monthly caps, excluding IPv4 and VAT, from Hetzner’s published adjustment table.

InstancevCPU / RAMBefore June 15AfterChange
CX33 (shared x86)4 / 8 GB€6.49€8.49+31%
CX43 (shared x86)8 / 16 GB€11.99€15.99+33%
CAX31 (shared Arm)8 / 16 GB€15.99€20.99+31%
CPX41 (shared AMD)8 / 16 GB€38.99€120.49+209%
CCX33 (dedicated)8 / 32 GB€62.49€138.49+122%

Two observations that most of the commentary missed.

First, the increase is wildly uneven across families. The shared Intel and Arm lines rose about a third. The AMD shared and dedicated-vCPU lines doubled or tripled. If your node groups happen to be on CX or CAX, this event barely touched you. If you defaulted to CCX “because production deserves dedicated cores,” your bill more than doubled for the same compute.

Second, grandfathering changes the tactics. Your existing servers keep their old prices until you rescale them. That means the worst possible response is casually churning nodes: every replacement server is a new order at new prices. The right response is to decide deliberately what your next node group looks like, and leave the old one alone until you do.

Is Hetzner still cheap? Yes, embarrassingly so

Here is the comparison that matters, because the alternative to Hetzner is not free compute, it is a hyperscaler.

Take a real production baseline: 24 worker vCPUs, a highly available setup, ingress, and a managed control plane. On AWS EKS in us-east-1 at on-demand list prices, that looks like:

  • EKS control plane: $0.10 per hour, about $73 a month, per cluster, even when idle
  • 6 x m6a.xlarge workers (4 vCPU, 16 GB each): about $126 each, $757 a month
  • NAT gateways across three availability zones: about $98 a month before data processing
  • An application load balancer: about $22 a month base

That is roughly $950 a month before storage, egress, and observability, and cost guides for EKS routinely tell you to add 20 to 35 percent on top for the pieces everyone forgets. Savings plans and spot can cut the worker line substantially, at the price of commitment or interruption tolerance.

The same 24 worker vCPUs on Hetzner through Ankra, at the new, post-increase prices:

  • 3 x CX43 workers (8 shared vCPU, 16 GB each): €47.97 a month
  • 1 x CX33 control plane: €8.49 a month
  • A small bastion host and IPv4 addresses: call it €8 a month
  • Ankra platform fee: €0, because 24 worker vCPUs is inside the 30 vCPU free allowance, and control planes are never billed

About €65 a month, all in. If shared vCPUs make you nervous for your workload profile, do it with dedicated cores: three CCX33 nodes at the new price is €415 a month, still less than half the EKS figure, with double the RAM per node.

The honest caveat: those are shared cores versus dedicated EC2 cores in the first comparison, one region versus three availability zones, and EKS brings an ecosystem Hetzner does not. This is not a like-for-like SLA comparison, it is a “what does the invoice say” comparison. But the invoice gap is 14x, and it did not stop being enormous because Hetzner raised prices. What changed is something else.

What the repricing actually broke

The price increase did not break anyone’s budget on its own. A 33 percent increase on a €65 cluster is €20. What it broke is a mental model: the idea that you pick the cheap provider once, build everything there, and the decision stays made.

Cloud pricing is an input that moves. Hetzner just proved it, AWS quietly reprices too, in both directions, and your negotiated discount expires. The teams that got hurt by June 15 are not the ones paying an extra €20. They are the ones who did the math, realized they should move from CCX to CAX, or from Hetzner to OVHcloud or UpCloud for a specific workload, and then looked at what moving actually involves:

  • Reprovision a cluster by hand, or resurrect the Terraform that built the last one
  • Reinstall the fifteen Helm charts that make a cluster production-grade: ingress, cert-manager, monitoring, logging, the works
  • Port the values files, and rediscover which of the hundred settings were load-bearing
  • Rewire DNS, secrets, CI/CD, and kubeconfigs
  • Do it all without an outage

If that list costs you three weeks of a senior engineer, you do not move. You eat the increase, this one and the next one. The provider knows it. Migration friction is exactly what makes repricing safe to do to you.

This is the same trap we described in the edge computing post from the fleet angle: the cost of Kubernetes is rarely the compute, it is the operational plumbing around every individual cluster.

Portability is a property you build in, not a migration you run later

Here is how the same event plays out when the platform layer is portable, which is the actual design goal behind how Ankra treats clusters and stacks.

The cluster is a commodity. Ankra provisions managed k3s clusters on Hetzner, OVHcloud, and UpCloud from the same interface: pick a location, control plane count and type, and worker node groups. One command, or a few clicks, and the full topology comes up, private network, bastion, control planes, workers, optional ingress stack included.

Terminal window
ankra cluster hetzner create \
--name prod-fsn1 \
--credential-id <hetzner-credential-id> \
--ssh-key-credential-id <ssh-key-id> \
--location fsn1 \
--control-plane-count 1 \
--control-plane-server-type cx33 \
--worker-count 3 \
--worker-server-type cx43

The software layer is a stack, and stacks travel. Everything installed on top, ingress, cert-manager, monitoring, your applications, lives in Stacks with their dependency graph and Helm values, versioned in Git. Standing up the same platform on a second provider is Clone to Cluster, not a quarter-long project. Variables resolve per cluster, so the same template lands with the right domains, storage classes, and replica counts. Secrets deliberately do not travel with clones; they stay SOPS-encrypted and get reconfigured per environment.

That combination changes the negotiation. When “move this workload to OVHcloud” costs an afternoon instead of three weeks, you can actually respond to a repricing. Benchmark the same stack on two providers with real traffic, compare the invoices, and keep whichever wins. Providers compete for portable workloads. They tax captive ones.

The three cost levers you get on top

Portability is the strategic lever. Day to day, three smaller ones do most of the work.

Node groups let you re-shape instead of overpay. Workers live in named groups, each with its own instance type, count, labels, and taints, scalable from 0 to 100 nodes independently. The June increase made instance family the single biggest cost decision on Hetzner, and node groups are how you act on it: add a CAX Arm group at a third of the CCX price, taint it, move the workloads that are multi-arch clean, and watch. One warning from the trenches: instance type changes on an existing group are upgrade-only and irreversible, because disks grow but never shrink. To go smaller, add a new group and delete the old one. Which, conveniently, is also the pattern that preserves your grandfathered pre-June prices on the nodes you keep.

Scale to zero means idle environments cost zero. A staging cluster that only matters during business hours does not need servers at 3 AM. Deleting the Kubernetes layer tears down every Hetzner resource, servers, network, SSH keys, and stops the charges completely, while the cluster record, its stacks, and its credentials stay in Ankra. Bringing it back is adding a node group: the control plane restores automatically, workers join, and the stacks reconcile onto the fresh infrastructure on their own. Fresh servers, same platform. For review environments and client demos, this is the difference between “we keep a cluster around just in case” and “we pay for hours we use.”

You can see the spend before the invoice does. Ankra’s Cloud Cost view estimates what each cluster costs from the live node and volume inventory plus public pricing, broken down by compute, storage, and network, and allocated per namespace and stack. The fleet rollup puts every provider on one page. Estimates are for trend-watching and right-sizing rather than invoice reconciliation, and that is precisely what you want in the week after a provider reprices: which node groups, which namespaces, which teams does this actually hit?

And to close the loop on Ankra’s own pricing, since this is a post about invoices: the platform bills on worker vCPU only, control planes are free, every plan includes a 30 vCPU free allowance, and clusters and team members are unlimited. The billing page shows current burn, projected month-end, and a full-month average from your actual hourly usage. No per-cluster fee, which matters exactly when the right answer is “run more, smaller clusters on whichever provider is cheapest this quarter.”

The playbook for this month

If you run Kubernetes on Hetzner today:

  1. Do not churn grandfathered nodes. Servers from before June 15 keep old prices until rescaled. Stability is now literally worth money.
  2. Audit your instance families. CPX and CCX took the hit; CX and CAX barely moved. If your workloads are not pinned to x86 or dedicated cores, a CAX node group at €20.99 for 8 vCPU and 16 GB is the cheapest production compute in Europe, still.
  3. Turn off what idles. Every staging and demo cluster that survives the night out of provisioning fear is pure waste once restoring it is a one-step operation.
  4. Price the alternatives with data, not vibes. Clone your stack to an OVHcloud or UpCloud cluster, run it for a week, read the Cloud Cost page, decide.
  5. Whatever you choose, choose it from portability. The next repricing is not hypothetical. It is scheduled, somewhere, by someone, and the only durable defense is a platform layer that moves.

Hetzner after June 15 is still, by a comfortable margin, the cheapest serious place to run Kubernetes in Europe. That is not the point. The point is that you should never again be in a position where a pricing PDF from any provider dictates your architecture. Build the platform layer portable, and the pricing PDF becomes an input to a decision you can actually make.


Get started: Create a free account on Ankra and provision your first cluster inside the free 30 vCPU allowance.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]

ShareXLinkedInHN

Get the next post in your inbox

Platform engineering guides and product updates. No spam, unsubscribe anytime.

Related Posts