Skip to main content

Hetzner's Singapore Region Isn't a 2026 Launch — It's a 2026 Repricing: What APAC Self-Hosting Actually Costs

8 min readDora NodaDora Noda
Share
On this page

If you've read anywhere in 2026 that Hetzner "just opened" a Singapore region, that's wrong — it opened on August 6, 2024. What's actually new in 2026 is the price: two separate repricing rounds, one in April and one in June, both of which hit Singapore harder than the German and Finnish locations self-hosted PaaS operators default to. For a team weighing whether to finally point a Cluster API node pool at Asia-Pacific instead of routing every APAC tenant's traffic back to Europe, that distinction matters more than the marketing framing does — the region has been production-ready for two years, but what it costs and what it's missing changed twice this year alone.

The Region Is Two Years Old, Not Two Months

Hetzner's own press announcement dates the Singapore launch to August 2024, positioning it as a way to cut latency to China, India, and Japan and to enable "a custom geo-redundant cloud setup between Hetzner's locations in Europe, North America, and Asia." It's had two full years of production traffic, feature updates, and — as of 2026 — price adjustments behind it. Nothing about it is a fresh rollout.

That confusion is worth clearing up before the numbers, because it changes what question you're actually answering. "Should I wait for a new region to mature" is a different decision than "should I use a two-year-old region that just got a lot more expensive." The second is the one that's actually in front of a self-hoster today.

What Actually Happened in 2026: Two Price Hikes, Not One Launch

Hetzner adjusted cloud pricing globally on April 1, 2026 — a 30-37% increase across most EUR-priced instances, driven by a DRAM contract-price spike Hetzner cited directly (TrendForce tracked conventional DRAM contract prices up 90-95% quarter-over-quarter in the same window, as AI server and HBM demand ate into global memory supply). Singapore and the US locations, which Hetzner leases rather than owns outright, saw a steeper 38-53% increase in that same round — leased datacenter space passes supplier cost shocks through faster than owned facilities do. A second, separate standardization pass followed on June 15, 2026, collapsing custom configurations into fixed tiers and repricing again.

Track a single shared-vCPU plan — CPX22 (2 vCPU, 4 GB RAM), the tier that actually matters for the "cheap latency-sensitive node" use case this topic is about — across both rounds, and the two-region gap shows up cleanly:

PlanGermany/Finland (old → new)Singapore (old → new)
CPX22€7.99 → €19.49/mo€15.99 → €26.49/mo
CCX13 (dedicated, for comparison)€15.99 → €42.99/mo€27.49 → €53.99/mo

Two things fall out of that table. First, Singapore was already pricier than the EU baseline before either 2026 hike — it's never been price-parity with Falkenstein. Second, after both rounds, a Singapore CPX22 costs about 36% more than the identical spec in Germany or Finland (€26.49 vs €19.49), and a Singapore CCX13 costs about 26% more (€53.99 vs €42.99). That's the real 2026 story: not a new region appearing, but the existing region's price gap to the EU baseline this list keeps benchmarking against holding steady or widening while both sides get more expensive.

What Singapore Doesn't Have That Falkenstein Does

Price is the smaller gap. Feature parity is the one that actually blocks architecture decisions:

CapabilityEU (Falkenstein/Nuremberg/Helsinki)Singapore
Shared/dedicated vCPU cloud serversYesYes
Dedicated Robot root serversYesNo — cloud products only
Object StorageYes (FSN1, HEL1, NBG1)No — not offered in Singapore at all
Load BalancersYes, full IP-target supportYes, but IP-based targets only work in the eu-central zone
Cross-region private networkingAny eu-central location, same networkNo — Singapore sits in its own ap-southeast network zone; a single Hetzner Cloud Network cannot span zones

The Object Storage gap is the one that bites first for a PaaS control plane: build artifacts, backups, and TLS state that a Falkenstein-based deployment routes to local S3-compatible storage have nowhere to land in Singapore — that traffic has to leave the region entirely, back to an EU bucket, defeating some of the latency win the region exists to provide. The load-balancer IP-target restriction is narrower but concrete: if a design assumes an LB can front an arbitrary external IP (a third-party origin, a non-Hetzner backend), that only works in eu-central — a Singapore LB has to target Hetzner Cloud servers, not bring-your-own IPs. And because network zones don't bridge, a Singapore node pool can't join the same private network as an EU control plane; cross-region traffic has to go over the public internet or a self-managed overlay (WireGuard, Tailscale), not Hetzner's native networking.

The Traffic Tax: 0.5 TB Included, €7.40 Overage

The number that changes the calculus most for a media- or API-heavy tenant is traffic. Hetzner's own Singapore announcement states the region includes 0.5 TB of outbound traffic, against the 20 TB bundled with an equivalent EU instance — a 40x smaller allowance. Overage in Singapore is priced at €7.40/TB, versus €1.00/TB in the EU — 7.4x the per-terabyte cost once you're past the included amount.

Put a number on it: a modest APAC-facing API service doing 3 TB of outbound traffic in a month would burn through the included 0.5 TB and pay overage on the remaining 2.5 TB. At Singapore's rate, that's €18.50 in overage alone, on top of the base instance price — for a workload that would incur zero overage charge in the EU, where 3 TB sits comfortably inside the 20 TB allowance. Push the same workload to 10 TB/month — still a routine number for an image-serving or video-adjacent app, nowhere near exotic — and the Singapore overage bill climbs to €70.30, more than double the CPX22's own €26.49 monthly rate. Scale further, to a genuinely traffic-heavy service in the 15-20 TB/month range that a single EU instance absorbs entirely inside its bundled allowance, and the Singapore overage alone can run into the hundreds of euros on top of an instance that costs €26.49-53.99 to rent in the first place. This is the number that should drive the shared-vCPU-vs-dedicated-vCPU choice in Singapore specifically: the instance price gap between CPX and CCX tiers is a rounding error next to what an under-provisioned traffic estimate costs there.

Does Cluster API Even Point at ap-southeast?

Nothing in Cluster API Provider Hetzner (CAPH) hardcodes an allowed region list — the location a machine deploys to is a free-form value (HCLOUD_REGION or the equivalent field on HCloudMachineTemplate) passed straight through to the Hetzner Cloud API. Set it to sin1 and CAPH has no code path that rejects it; there's no CAPH-side reason ap-southeast can't host a node pool.

The catch is that nothing in CAPH's public documentation has actually been exercised against Singapore. The quickstart, the management-cluster setup guide, and the worked tutorials all use fsn1 as the example location. Combine that with the two structural gaps above — the load-balancer IP-target restriction and the network-zone isolation — and a CAPI control plane spanning EU and Singapore has two real design problems to solve that a single-zone EU cluster never has to: how the API server's load balancer reaches nodes if it needs external targets, and how nodes in different zones talk to each other at all, since Hetzner's own private networking won't bridge the gap. Neither is a blocker — WireGuard between zones and a Hetzner-Cloud-server-only LB target list both work — but "technically unblocked" and "documented, exercised path" are different claims, and today only the first one is true for Singapore.

The Verdict: When Singapore Earns Its Node Pool

Point a node pool at Singapore when the tenant's actual users are in Southeast Asia and the round-trip savings versus serving from Helsinki or Falkenstein — 180-300ms of submarine-cable latency by some estimates — genuinely matters to the product: real-time APIs, interactive dashboards, anything latency-sensitive enough that a CDN cache in front of a European origin can't paper over it.

Keep serving APAC from Europe behind a CDN when the workload is read-heavy, cacheable, or traffic-heavy enough that the 40x smaller bundled allowance and 7.4x overage rate turn into a real line item, or when the deployment needs Object Storage, arbitrary LB targets, or a single private network spanning regions — all of which the EU zone gives you today and Singapore doesn't.

Concretely, before pointing a Cluster API node pool at sin1, budget for three things a Falkenstein-based deployment doesn't need: a traffic estimate with real headroom (the 0.5 TB allowance leaves almost no margin for error), an object-storage plan that routes back to an EU bucket rather than assuming local storage, and a cross-zone networking design — WireGuard or an equivalent overlay — since Hetzner's own private networking stops at the eu-central boundary. None of those are blockers. All three are costs the EU baseline this list keeps recomputing against simply doesn't carry. "Self-host in Asia" is a real option on Hetzner now — it has been for two years — but it's a narrower one than the EU baseline, and 2026 made it a more expensive narrower option, not a newly-arrived one.

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.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex