Netcup Vouchers vs Hetzner Post-Hike Prices: A Fleet-Role Placement Guide

In August, this site did the single-node math: one netcup RS 1000 G12 — four dedicated EPYC cores, 8 GB of DDR5 ECC, 256 GB of NVMe — against Hetzner's post-hike CCX13, and the dedicated core came out roughly ten times cheaper on the netcup side. That comparison answered the node question. It did not answer the fleet question, which is the one an operator actually has to act on: you don't run one node, you run control-plane machines, hourly-scaled workers, and storage-hungry build boxes, and each of those roles prices a different thing — API-driven lifecycle, quorum latency, raw euros per core.

So here is the fleet-placement verdict first, with the worked math behind it. All prices are Germany, excluding VAT, monthly:

The punchline in one sentence: Hetzner's hike repriced its performance tiers, not its whole catalog, so the shared lines you scale by the hour are still cheap — while netcup's voucher-priced dedicated cores undercut Hetzner's dedicated line by ~6x on batch-shaped capacity. Split by role, not by brand loyalty. The rest of this post is the evidence: what each catalog actually costs now, the per-role math, and whether a second provider genuinely diversifies your single-vendor risk or just buys you a second lifecycle model to operate.

What changed since the single-node math​

Two things moved since August, one in each catalog. First, the Hetzner side needs a correction to a number that keeps circulating: the €3.79 entry price is gone. That was the April post-hike price of the CX22/CAX11 generation; the CX22 line was deprecated in 2026Q1 and replaced by the CX23 generation, and the June 15 adjustment — which applies to new orders and rescales only — lifted shared lines ~1.3–1.4x. The entry shared-vCPU shape today is the CX23 (2 shared vCPU, 4 GB RAM, 80 GB) at €5.49/month, with the ARM CAX11 at €5.99 and the 4-vCPU CAX21 at €10.49.

The dedicated lines are where June 15 really landed. CCX (dedicated vCPU) rose 2.1–2.73x and CPX (shared AMD) 2.4–2.75x in Germany/Finland, with US CPX up to ~3.1x. The canonical data point: the CCX13 (2 dedicated vCPU, 8 GB) went from €15.99 early this year to €42.99/month for new orders — a dedicated core at an effective €21.50. The CCX63 now lists at €853.49, up from €374.49.

Remember the grandfathering rule, because it shapes every recommendation below: instances ordered before June 15 keep their old price until you rescale or recreate them. Your existing nodes are an asset; your next MachineDeployment rollout pays the new tariff.

Second, netcup didn't stand still either — its RS line rose roughly 18–24% this year — but September brought voucher pricing that more than offsets it for new terms. The current G12 root-server lineup (12-month term, dedicated AMD EPYC cores, DDR5 ECC, hardware-RAID NVMe, IPv4+IPv6 and flat traffic included):

Voucher-effective here means the 12-month term cost spread monthly (2 free months = pay 10/12ths). Two caveats before you annualize anything: voucher pricing applies to the first term — budget the renewal at list — and RS plans are fixed-term KVM root servers, not hourly cloud VMs. There is no per-hour billing, no rescale API, and no Cluster API provider for netcup. That last fact does most of the work in the placement table, so let's walk the roles.

The worked placement, role by role​

Control plane: keep it on Hetzner, on the cheapest shared shapes. Three CX23s cost ~€16.50/month total — less than half of one CCX13. Control-plane nodes don't need dedicated cores; etcd cares about stable disk latency and low inter-node RTT, and keeping all three members plus the Hetzner Cloud Controller Manager and load balancers inside one provider's network is worth more than any per-core saving. Splitting quorum members across providers to "diversify" is the one move that converts a billing problem into an availability problem. Absolute cost is tiny; don't optimize it.

Hourly-scaled app workers: keep them on Hetzner, on shared lines. This is the role where Hetzner's Cloud model still wins despite the hike, for two reasons the price table doesn't show. First, billing: Hetzner Cloud bills by the hour capped at the monthly ceiling, so a MachineDeployment that scales from two to eight CAX21s for a deploy spike and back costs roughly one node-day, not eight node-months. Netcup RS is a fixed monthly term — every box you hold for the spike, you hold for the month. Second, lifecycle: CAPH (Cluster API Provider Hetzner) can create, join, drain, and delete Hetzner Cloud servers declaratively, which is what makes cluster-autoscaler actually work. There is no CAPI provider for netcup — automation tops out at community Terraform providers against the SCP API plus Ansible over SSH. A worker pool that can't reconcile itself isn't a pool, it's a petting zoo. At €5.49–€10.49/month per shared node, Hetzner remains the right substrate for elastic capacity.

Build and batch workers: this is the netcup-shaped hole. CI builders, image builds, batch jobs, and agent sandboxes want sustained dedicated cores, lots of RAM, and big local NVMe — exactly what Hetzner repriced hardest and exactly what RS plans sell cheapest. Compare like with like: an RS 8000 G12 gives 16 dedicated cores, 64 GB RAM, and 2 TB NVMe for ~€55/month voucher-effective. The Hetzner equivalent in dedicated cores is eight CCX13s (16 dedicated vCPU, 64 GB, 640 GB total) at €343.92/month — over six times the price for less than a third of the disk. Even at netcup list (€59.97) and even against Hetzner's pre-hike CCX13 (€15.99 × 8 = €127.92), the RS box wins on cores-per-euro and isn't close on storage. The condition is that these nodes join statically — provisioned once via panel/API, joined with kubeadm, labeled as a batch pool, and left alone. Batch capacity doesn't autoscale by the hour anyway; it runs hot for hours and idles overnight, which is precisely the shape a fixed-term dedicated box serves well.

Does a second provider actually diversify you?​

This is the question the TODO behind this post asked most pointedly, and it deserves an honest two-column answer, because "don't put all eggs in one basket" is true for some failure modes and theater for others.

Where a netcup leg genuinely helps: price-shock hedging (you just lived through the reason — a second catalog means the next unilateral repricing hits part of your bill, not all of it), provider-incident blast radius (a Hetzner region or API outage degrades your elastic pool while batch keeps building, and vice versa), and capacity access (when one provider's cheap lines are stock-constrained, the other catalog is still orderable). There is also real precedent for the mixed pattern: Tuist's in-house bare-metal CAPI work joins Scaleway and OVH machines as workers into CAPH-managed Hetzner clusters through CAPI's standard Machine shape — foreign legs under one control plane is a proven architecture, not an experiment.

Where it doesn't help, and what it costs: your control plane still has one home, and that's correct — quorum doesn't diversify. You now operate two lifecycle models: declarative MachineDeployments on the Hetzner leg, static Terraform-plus-Ansible pets on the netcup leg, with different provisioning runbooks, different monitoring enrollment, and different decommissioning hygiene. There is no autoscaler for the netcup leg and no cloud-controller niceties — no automatic load-balancer targets, no floating IPs failing over. And cross-provider pod-to-pod traffic (batch jobs pulling from services on the Hetzner leg) traverses the public internet unless you build the WireGuard/overlay mesh yourself, with the latency and the secrets-management bill that implies.

The recommendation that falls out: hedge batch capacity, don't split the cluster. Keep one CAPH-managed cluster (or one fleet of them) on Hetzner for everything elastic and everything serving traffic; attach netcup RS boxes as a statically-joined batch pool with taints that keep serving workloads off. You get ~80% of the price and resilience benefit for one extra runbook, instead of two half-clusters that share nothing but your pager.

What to do this week​

1. Freeze rescales on grandfathered nodes. Audit which Hetzner instances predate June 15; every rescale or recreate reprices them to the new tariff. Pin MachineDeployment templates deliberately and roll workers only when the workload change justifies the new rate.
2. Price your next batch box at netcup's voucher rate — and budget its renewal at list. The September vouchers (2 months free on RS 1000, 1 month on RS 2000/8000) are first-term only. The renewal math still beats CCX by multiples, but put the list price in the budget so month thirteen isn't a surprise.
3. Keep MachineDeployments on Hetzner shared lines. CAX21 at €10.49 (4 vCPU / 8 GB) is currently the sweet spot for elastic workers; CX23 at €5.49 for small or ARM-incompatible shapes. Don't chase dedicated cores for spiky workloads.
4. Join netcup boxes statically, taint them for batch. One Terraform module against the SCP API, one Ansible playbook for kubeadm join, a workload=batch:NoSchedule taint, and labels the scheduler can target. Resist the urge to build a general-purpose autoscaler for a fixed-term fleet — that's the complexity the split was supposed to avoid.
5. Revisit after the next repricing, on either side. Both catalogs moved twice this year. The placement above is priced, not principled — rerun the three-role table whenever either provider announces, because the only durable lesson of 2026 is that the tariff is a variable.

The RAMpocalypse didn't kill the own-your-fleet thesis — our September tally put breakeven near 8 GB on performance tiers, and the August single-node shootout showed dedicated cores going for one-tenth the price across the provider line. What it killed is the single-catalog fleet: Hetzner's hike fell almost entirely on the performance tiers, netcup's vouchers discount exactly the dedicated shapes Hetzner repriced, and no one provider now wins every role. Place the control plane where the API is, the elastic workers where the hourly billing is, and the batch cores where the euros-per-core is — and let the next price shock hit somebody else's monoculture.

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.