Hetzner's Warsaw PoP and the GEX45: What Changes — and Doesn't — for a CAPH Fleet

In early-September 2026 news, Hetzner paired two moves: a new network point of presence in Warsaw, and the GEX45, a dedicated GPU server built around NVIDIA's RTX PRO 4000 Blackwell card. If your fleet is pinned to Hetzner and managed by Cluster API, both matter — but in completely different ways, and one of them is easy to misread as something it isn't.

TL;DR: two launches, one sentence each​

The Warsaw PoP buys your tenants better Eastern-European peering and redundancy — it is not a region, no workload runs there, and no CAPH MachineDeployment can target it. The GEX45 puts entry-level Blackwell acceleration (24 GB of GDDR7) on a dedicated box at €214/month, a credible inference-node candidate that reaches your cluster through Robot and a bare-metal inventory, not the Cloud API. Your region math — FSN1, NBG1, HEL1, Ashburn, Hillsboro, Singapore — is unchanged.

That's the whole verdict. What follows is the evidence and the operator playbook.

PoP vs region vs datacenter: the 60-second version​

The confusion these announcements invite is terminological, so let's fix terms first:

A PoP is where Hetzner's backbone meets other networks — local ISPs, exchanges, transit providers. Traffic to and from Polish and nearby eyeball networks can now enter and leave Hetzner's network in Warsaw instead of tromboning through Frankfurt or Berlin first. Nothing about that sentence involves a hypervisor.

What Warsaw actually buys you: a worked latency example​

Consider a tenant serving users in Warsaw, with the app running in Falkenstein (FSN1) — the closest German region to Poland. Before the PoP, a plausible path for that traffic was:

Warsaw eyeball → Polish transit → Frankfurt/DE-CIX → Hetzner backbone → FSN1

After the PoP, the same traffic can plausibly take:

Warsaw eyeball → Warsaw PoP → Hetzner backbone → FSN1

Fewer networks, fewer hops, one fewer city. Hetzner's own framing matches: the announcement describes the site as adding local connectivity and redundancy. Note the second word — redundancy. A PoP is also a second ingress/egress path, so a fiber cut or congested transit link on one route stops being a single point of failure for the region's traffic.

How much latency is actually on the table? Honest answer: nobody outside Hetzner's netops can quote you a number until traffic moves — so here is the physics floor instead of a fabricated benchmark. Light in fiber travels at roughly 200,000 km/s, which makes round-trip time about 1 ms per 100 km. Warsaw to Falkenstein is roughly 700 km as the fiber flies, so the theoretical RTT floor is around 7 ms; Warsaw to Nuremberg (≈900 km) sits near 9 ms, and Helsinki further still. Real traffic always lands above the floor — routing, queues, last-mile — but the floor tells you the shape of the win: eliminating a Frankfurt detour removes hundreds of kilometers of path plus a peering handoff, which is a single-digit-millisecond improvement, not a tens-of-milliseconds one.

That pins down exactly what a self-hosted PaaS may now claim to tenants east of Berlin:

The third row is the trap. "Hetzner expands to Warsaw" reads like region news; it is peering news. Your status page can celebrate it, but your placement docs must not list it.

What Warsaw doesn't change: the region math​

For a CAPH-managed fleet, the provisionable world is still exactly six Cloud locations:

There is no waw1, no Warsaw network zone, and no change to the rule that every location in one private network must share a zone. Your HCloudMachineTemplate manifests, your clusterctl flavors, your autoscaler bounds — none of them gain a new valid value. If your platform exposes a region picker to tenants, the correct code change for this announcement is no code change at all, plus maybe a docs note that Eastern-European RTT improved.

This asymmetry is worth internalizing because it recurs: Hetzner opens PoPs far more cheaply than datacenters, and every future "Hetzner expands network to X" headline deserves the same three-second test — did a location code appear in the Cloud API? If not, it's peering, and your fleet config stays untouched.

The GEX45 in numbers: Blackwell on a budget line​

The second half of the announcement is compute, and it's the more actionable half for a fleet operator. The GEX45 is a dedicated (Robot) server built around the NVIDIA RTX PRO 4000 Blackwell SFF Edition, positioned for inference, fine-tuning, 3D rendering, and CAD — explicitly an entry-level professional GPU box rather than a datacenter training card. Full spec: Intel Core i5-13500 (14 cores / 20 threads), 64 GB DDR4, 2× 512 GB NVMe, and the Blackwell card with 24 GB of GDDR7 ECC VRAM.

Its predecessor, the GEX44, carries the Ada-generation RTX 4000 SFF with 20 GB of GDDR6. Side by side:

Two things stand out. First, the price-per-gigabyte of VRAM is essentially flat (~€9/GB either way) — you pay about 16% more per month for 20% more memory plus a generation jump in architecture. Second, the setup fee more than doubles, which punishes short experiments: the GEX45 only makes sense as a box you keep for months, not one you spin up for a weekend eval. Amortized over a year, setup adds ~€17/month; over three months, it's ~€70/month.

What does 24 GB fit? The inference class this card targets is roughly: 7B–14B-parameter models in full precision with headroom, 30B-class models in 4-bit quantization, a single-tenant fine-tuning run with LoRA adapters, or a small shared pool of agent sandboxes doing embedding and rerank work. It is not a training box and not a multi-tenant inference farm — but for a self-hosted PaaS, "one owned box that holds the house model" is exactly the shape that turns metered inference spend into fixed cost.

Wiring a GEX45 into a CAPH fleet: the Robot-shaped caveat​

Here is where operators used to Cloud-API provisioning trip. The GEX45 is a dedicated server, and dedicated servers don't come from the Cloud API — they're bought in Robot, Hetzner's dedicated-server portal. CAPH handles this split with two different machine types:

• HCloudMachine — CAPH calls the Cloud API and creates a VM matching the object. Declarative, autoscalable, the path every fsn1/nbg1 worker node takes.
• HetznerBareMetalMachine — CAPH does not buy anything. It consumes a host from your HetznerBareMetalHost inventory: servers you already purchased manually in Robot and registered one-to-one.

So the GEX45 onboarding runbook is: order the box in Robot, wait out provisioning, register it as a HetznerBareMetalHost, then let a HetznerBareMetalMachine claim it into the cluster. The consequences flow from that shape:

1. No autoscaling. The cluster autoscaler can't conjure dedicated boxes. Your GPU capacity is the integer count of GEX45s you own — plan the pool size up front.
2. Static topology. You decide which racks/regions the boxes live in at purchase time (dedicated hardware sits in Hetzner's German and Finnish datacenters, not in Cloud regions like Ashburn or Singapore). There is no "GEX45 in ash" — US and Singapore tenants get served over the backbone.
3. Version pinning discipline. The bare-metal inventory is hand-tended, so "which GPU driver / which host OS is this pool on" is your spreadsheet, not an API field — treat it with the same rigor as a Cloud image pin.

None of this is a reason to skip the box; it's the reason to model it as a static inference pool behind your autoscaled CPU fleet, not as another fungible node type. One GEX45 serving the house embedding model for every tenant is a clean architecture. Ten GEX45s pretending to be an elastic GPU cloud is a procurement department.

Operator playbook: what to do this week​

Concretely, for a Hetzner-pinned, CAPH-managed platform:

1. Verify the Warsaw win yourself. Run RTT comparisons from RIPE Atlas probes or your own Eastern-European vantage points to your German load balancers, and watch for the step change as traffic shifts to the new peering. Publish the measured delta, not the physics floor.
2. Update latency docs with the honest template. "Improved peering for Eastern Europe via Hetzner's Warsaw PoP" — not a new region, not a placement option.
3. Price a GEX45 inference pool. One box at €214/month against your current metered inference bill is usually a short conversation; the setup fee means you commit by the quarter, minimum.
4. Touch nothing in region config. No new location code, no new zone, no MachineDeployment change. The fleet manifests are already correct.

Two expansions, one lesson​

Hetzner expanded in two directions at once: sideways into the network with a Warsaw PoP, and upward into accessible GPU compute with the GEX45. The sideways move improves every tenant's packets a little and changes no manifest; the upward move changes your cost model for inference but arrives through the manual Robot door, not the API. Both reward the same operator habit — checking which layer of the stack actually moved before updating either your marketing or your manifests.

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.