UpCloud's €3 Starter Plans Undercut Post-Hike Hetzner: What a Second EU Provider Actually Buys Your Node Pool

Hetzner just repriced the same servers you already run twice in ten weeks, and the cheapest US VPS is now $20.49 a month. Meanwhile a Finnish provider you've probably benchmarked and forgotten about quietly put a usable 1 vCPU box at €3. The question isn't whether $3.50 is cheaper than post-hike Hetzner — it is. The question is what that €3 actually buys a self-hosted PaaS that deliberately runs on a single IaaS, and how far that provider is from being a second Cluster API target you could actually fail over to.

Short answer: UpCloud's May 2026 Starter tier undercuts Hetzner's repriced entry by roughly 25-50% at the bottom end, matches Hetzner's EU footprint city for city, and removes nothing you need for dev and many prod workloads — but there is no community Cluster API Provider for UpCloud today, so diversification is a real hedge you have to build, not one you can toggle.

That table first, then the why and the how.

TL;DR — The €3 Number That Changes the Baseline​

UpCloud reorganized its line on April 16, 2026 into two families: Starter (replaces Developer, ~25% cheaper, 99.99% SLA) for dev and self-hosting, and Premium (replaces General Purpose, 5th-gen AMD EPYC 9575F Turin on MaxIOPS, 99.999% SLA) for production. Starter list starts at €3 / $3.50 a month in May 2026. Hetzner, on the same calendar, repriced cloud twice — April 1 by ~30-37% across CX/CAX/CPX/CCX, then June 15 by another 107-204% on dedicated CCX/CPX alone on top of the April base.

* June 15 added 107-204% on CCX/CPX specifically; CX/CAX rose a milder ~33-38% that round. Exact post-June CPX22 lands near $18-26 depending on location (DE/FI vs US/SIN where the multiplier was up to 3.1×).

Two things to read off this:

• Entry is where UpCloud wins cleanly. If your comparison starts at "cheapest always-on box I can park a side project on," Starter undercuts Hetzner's cheapest surviving cloud SKU by about a third, with MaxIOPS that independent benchmarks consistently rank ahead of providers twice its price.
• At 2 vCPU/4 GB, the price story is parity plus tradeoff. UpCloud charges $20 for that slice; Hetzner after both hikes lands in the same teens-to-mid-20s window but bundles an order of magnitude more included transfer (20 TB vs 1-4 TB). Which is cheaper depends on whether you are compute-bound or egress-bound.

For a Bex-style fleet, entry price is not the whole fleet cost — but it is the price that determines where a second pool starts being worth the operational overhead.

What UpCloud Starter Actually Is (and Isn't)​

UpCloud is Finnish, founded in Helsinki in 2012, and has sold the same pitch for a decade: proprietary MaxIOPS block storage that the vendor claims is twice as fast as industry standard, and that outside benchmarks keep confirming at the top of the VPS chart. The April 2026 reshuffle made that pitch cheaper at the bottom:

Starter replaces the older Developer family explicitly, pitched for "development, testing, self-hosting and cost-conscious workloads." Premium replaces General Purpose and is the family that carries the 5th-gen AMD EPYC 9575F Turin hardware, MaxIOPS, and the 99.999% SLA. Starter's SLA is 99.99% — a decimal less, still above what most self-hosted control planes budget for.

Regions matter more than specs for a sovereignty story. UpCloud operates from:

• EU: Helsinki, London, Frankfurt, Amsterdam, Warsaw, Madrid
• Outside EU: Chicago, San Jose, Singapore (and others via partner footprints)

Hetzner operates from Falkenstein (FSN1), Nuremberg (NBG1), Helsinki (HEL1), Hillsboro (US-West), and Singapore (SIN). Overlap is exact where you'd want it for a second EU pool: both vendors are in Helsinki, Frankfurt, and London/Amsterdam proximity. A node pool that today pins to FSN1/NBG1 could add a parallel pool in UpCloud Frankfurt or Helsinki without changing latency assumptions or data-residency narratives.

What Starter isn't: it is not a bare-metal line, not a GPU line, and not a 99.999% SLA line. If your fleet's default node is a dedicated CCX/CCX-class machine with local NVMe and you rely on that SLA for tenant SLOs, Starter is the wrong comparison — Premium is. Starter's value is as a second pool: cheap, fast enough, and EU-sovereign, for overflow, burst, dev, and non-critical tenants.

Repriced Math: Where Hetzner's Hikes Land You Now​

Hetzner's 2026 pricing story has three chapters. The media covered chapter one; the pain for production pools is in chapter two.

April 1 — the broad hike​

Hetzner raised cloud servers 30-37% in Germany/Finland (38-40% in US/Singapore), hit the US cheapest VPS hardest at +193%, bumped object storage 30% (€4.99 → €6.49), and — most tellingly — raised memory add-ons ~575%. The CPX22 example that circulated on Hacker News went €5.99 → €7.99 in a single step. Even there, the consensus was still "even after +30%, Hetzner is the cheapest option."

June 15 — the dedicated-line shock​

The second round, applied to new orders only (existing servers keep their price until a resize), standardized the portfolio into -1/-2/-3 fixed SKUs, introduced a lower-spec -1-Ltd tier to hold a price floor, and then repriced the lines that actually run production:

• CCX (dedicated vCPU) and CPX (shared AMD vCPU): +107% to +204% in DE/FI, up to +3.1× in the US, on top of the April base. A CCX23 cited in community teardowns went $39.99 → $102.99 (+158%). One tracker summarized the worst case as +113-176% for AMD shared, +2.1-2.75× for dedicated.
• CX (cost-optimized) and CAX (ARM): ~33-38% that round — painful but not fleet-breaking.

For a Cluster API fleet, the distinction matters: if your machineDeployments default to CX/CAX, your bill rose ~30% twice and you can still model it. If they default to CPX/CCX — which most production fleets do for dedicated cores — your next scale-out costs roughly double to triple what the same Machine object cost in March.

Side-by-side at fleet scale​

Take a small Bex-like fleet: 3 control-plane nodes + 6 workers, all CPX/CCX-class before June:

• March 2026 baseline: 9 × ~€18-39 = ~€200-310/mo in cloud compute alone.
• After April 1: ~€270-420/mo (+35%).
• After June 15 (new capacity): ~€500-850/mo for the same shape if scaled on CCX/CPX — the fleet's marginal cost per added worker roughly doubled.

Put UpCloud next to that: a parallel 6-worker Starter pool at $10-20 per node (1-2 vCPU, 1-2 TB transfer each) lands at $60-120/mo for the same node count at smaller slices, or ~$150-200/mo if sized like-for-like at 2 vCPU/4 GB. It does not erase Hetzner's hike on the primary pool, but it caps the marginal cost of the next 10-20 tenants on a vendor whose price moved independently — and did not move 100%+ that quarter.

The inventory constraint behind both hikes is the same: DRAM contract prices rose 90-95% quarter-over-quarter in Q1 2026 and another 58-63% projected for Q2 (TrendForce), with IDC calling the shortage "not just cyclical but a potentially permanent strategic reallocation" of wafer capacity toward HBM for AI. HBM eats ~40% of world DRAM output now; server DDR5 is what is left. That is why Hetzner cites "extremely high procurement costs for new hardware" and why the hikes are not Hetzner-specific.

What a Second Provider Actually Diversifies​

Running a whole fleet against one bare-metal vendor was the rational cost play when Hetzner's entry box was €3-5 and stable. In 2026, the same single-vendor Fleet has three new risks that a second EU provider mitigates even if you never fail over:

Price risk. Three repricings in five months, each citing the same DRAM/NVMe cost driver, with grandfathering only until a resize. A fleet that can only scale on Hetzner inherits Hetzner's procurement cost curve verbatim. A second pool on a vendor with an independent cost structure and a fresh $3.50 entry point lets you price the next MachineDeployment where it is cheapest that quarter.

Capacity risk. Hetzner restricted new cloud-server creation starting June 26 for new customers and a random subset of existing ones, citing hardware availability. That's distinct from price — it's a hard ceiling. The workaround is not "pay more," it's "provision elsewhere." A stocked second pool, even small, is the difference between queued Machines and running Machines during a provisioning delay.

Concentration risk. The DRAM crunch is industry-wide (TrendForce +90-95% QoQ, IDC "permanent reallocation," 50-60% of HBM/server capacity locked through 2027 via long-term contracts per Digitimes). Every provider that buys DDR5 is paying more. But not every provider reprices the same SKU, at the same time, by the same multiplier. EU sovereignty buyers already pay for that diversification in other forms — OVHcloud's SecNumCloud qualification going GA in June 2026 exists precisely because "EU-headquartered" alone stopped being a sufficient sovereignty answer for regulated buyers.

A second EU pool is not multi-cloud in the hyperscaler sense. It is two independent European IaaS vendors with overlapping regions, overlapping jurisdictions, and independent failure modes — which is exactly what a self-hosted PaaS needs to keep its "you own the hardware" pitch from becoming "you own hardware from exactly one vendor whose price just doubled."

How Far Is UpCloud From Being CAPI-Ready?​

This is where the honest gap matters.

There is no community Cluster API Provider for UpCloud today. The Cluster API book lists providers for AWS, Azure, GCP, Hetzner (CAPH via Syself, supporting both Hetzner Cloud and Robot bare metal), OpenStack, vSphere, Equinix Metal, and a handful of niche IaaS — UpCloud is not among them. A search of the provider ecosystem and of GitHub's cluster-api-provider-* namespace returns hits for Hetzner, Exoscale, Scaleway, Ionos, and a Sovexa meta-provider that lists upcloud as an enum value for a future NodePool abstraction — but no implemented CAPU.

The API itself is mature. UpCloud has a documented REST API, a maintained Terraform provider, CSI and CCM community efforts, and SDK bindings in Go and Python. Teams already provision UpCloud with Terraform+cloud-init and with Talos nocloud or Sidero in production. In other words, you can manage UpCloud declaratively today — you just cannot manage it through the Cluster API Machine/MachineDeployment abstraction without building or adopting that abstraction.

What building it entails:

• Infrastructure provider: A cluster-api-provider-upcloud controller that reconciles UpCloudMachine resources to the UpCloud API (create/delete/reboot, NICs, storage). Model it on CAPH (Go, controller-runtime) — CAPH is ~15k lines of provider code plus vendored CAPI. A minimal viable fork that only supports cloud servers (not bare metal) is weeks of work for a team that knows CAPI, months otherwise.
• Cloud Controller Manager + CSI: UpCloud's CCM and CSI driver exist as independent projects but are not bundled with a CAPI provider the way Hetzner's hcloud-cloud-controller-manager and hcloud-csi-driver are wired through CAPH. You would need to validate or harden them for the workload cluster.
• Images and bootstrap: Talos, Ubuntu, or Flatcar images already run on UpCloud; CABPT/CABPK bootstrap providers do not need UpCloud-specific changes.

Interim paths without a full provider:

• Terraform + clusterctl hybrid: Keep the management cluster on Hetzner/CAPH, and provision a secondary UpCloud node pool via Terraform, joining workers to the same workload cluster with kubeadm/Talos join tokens. Operationally uglier (two provisioning paths), but it ships this quarter.
• Crossplane or Sveltos: Treat UpCloud as a managed-resource backend rather than a CAPI infrastructure provider, if you already use those tools.
• Wait for Sovexa/meta-provider: If the provider: upcloud enum in Sovexa matures into a real provider, adoption could be a config change rather than a build.

The effort is real but bounded — and, crucially, one-time. Once a CAPU exists, adding UpCloud to a Bex fleet is a ClusterClass patch: a second control-plane or worker MachineDeployment with provider: upcloud and region: de-fra1 instead of fsn1.

Decision Framework: Single-Pool, Dual-Pool, or Wait​

Stay single-pool on Hetzner when:

• Your fleet is CX/CAX-only and you rarely resize — the June shock barely touched you, and UpCloud's entry advantage does not offset the operational cost of a second vendor.
• You need bare metal Robot servers (UpCloud has no equivalent).
• You cannot afford a second API surface right now.

Add a secondary UpCloud pool now (Terraform-joined, not CAPI) when:

• You are provisioning new CCX/CPX capacity this quarter and the marginal cost jump is the blocker.
• You want a burst/overflow pool for dev tenants or preview environments where 99.99% vs 99.999% is an acceptable trade for 30-50% lower entry cost.
• You need to demonstrate vendor diversification for sovereignty-conscious buyers (EU vendor, EU regions, EU law) without building CAPU yet.

Invest in a proper CAPU when:

• Your roadmap assumes fleet growth through 2027 while the DRAM/HBM crunch (IDC: permanent reallocation, wafer capacity locked through 2027) keeps repricing pressure on every DDR5 buyer.
• You run multiple workload clusters and want MachineDeployment parity across pools — one reconciler, one scale signal, two vendors.
• You can staff the controller for a quarter or fund it via a PAAS-level abstraction like Bex where the cost amortizes across tenants.

The broader point is portable: a self-hosted PaaS whose value prop is "push a git repo, get a running HTTPS service on machines you own" should not be locked to the procurement curve of one machines-you-own vendor. Hetzner's 2026 repricings and UpCloud's simultaneous entry-tier cut are the same market forcing a choice — absorb the hike, or have somewhere else to schedule the next 10 Machines.

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.