Hetzner's US Regions Aren't a 2026 Launch — They're the Latency Objection Render and Railway Migrators Never Checked

If you've seen a 2026 migration guide claim Hetzner "just opened" US data centers in Ashburn, Virginia and Hillsboro, Oregon, that claim is wrong on the calendar. Ashburn went live in November 2021. Hillsboro followed in December 2022. Both regions have been taking production cloud traffic for four and five years, respectively — long enough to outlive the "self-hosting means eating German latency" objection that still shows up in nearly every Render-to-self-hosted comparison post written this year.

That objection is the real story, not a launch date. Teams evaluating a move off Render, Railway, or Fly.io keep running the same mental math: "Hetzner is cheap, but Hetzner is in Nuremberg and Helsinki, and routing US traffic across the Atlantic adds 80-100ms I can't get back." That math was true in 2019. It has been wrong for half a decade, and almost nobody migrating in 2026 seems to have re-checked it.

The Latency Math, Corrected​

Here's what actually changes when a Cluster API node pool targets Ashburn or Hillsboro instead of Hetzner's European default.

The gap isn't subtle. A team that defaults to Hetzner's German regions out of habit — because that's where every tutorial provisions its first CX22 — is paying a full round-trip's worth of latency it never had to accept. Ashburn sits in the same colocation-dense Northern Virginia corridor that AWS us-east-1, Google's us-east4, and most of the internet's peering fabric already call home. Hillsboro rides the same West Coast submarine-cable landing points that make it a deliberate choice for Asia-facing traffic, not an afterthought.

The pricing story compounds the latency win, and it's a better ratio than the usual "roughly two-to-one" framing suggests. A Hetzner CX22 in Ashburn — 2 vCPU, 4GB RAM, 40GB NVMe — runs $4.59/month. An AWS t3.medium in us-east-1, the closest like-for-like on-demand instance (2 vCPU, 4GB RAM), runs roughly $30.37/month. That's not "roughly two-to-one" undercutting a hyperscaler equivalent — it's closer to 6.6x cheaper for the same compute shape, before AWS's separate data-transfer charges even enter the picture.

The Bandwidth Gotcha Nobody Mentions​

Here's the catch that the "just as cheap as Europe" framing skips: Hetzner's US regions don't carry the same bandwidth allowance as its European ones. A CX22 in Nuremberg or Falkenstein ships with 20TB of included outbound traffic. The same CX22 in Ashburn or Hillsboro ships with 1TB. Overage beyond that is priced at roughly €1/TB (~$1.20/TB) in both regions — the allowance shrank 20x, but the marginal rate past it didn't move.

That sounds like a real constraint until you put it next to what Render and Railway charge for the same overage, at three realistic traffic levels:

The crossover point is almost immediate. The instant a workload pushes past whatever a platform bundles for free, Hetzner's per-GB overage rate is somewhere between 20x and 500x cheaper than Render's or Railway's, because those platforms are pricing bandwidth as a margin line, not a commodity pass-through. A team sitting comfortably under 500GB a month won't notice much difference in the bill either way. A team pushing 2-5TB — a media-heavy API, a webhook-heavy integration platform, anything serving files or video — is looking at a three-figure monthly line item on Render that costs less than a cup of coffee on a Hetzner US region.

The Honest Gaps​

None of this is a free upgrade, and the same caveats this list already flagged for Hetzner's Singapore region apply here with one addition specific to the US regions.

Cloud-only, no bare metal. Ashburn and Hillsboro, like Singapore, only support Hetzner's cloud product line — Cloud Shared and Cloud Dedicated instances. Hetzner's Robot dedicated-server line, the actual bare-metal boxes many self-hosted PaaS setups lean on for database or storage nodes, isn't orderable in either US region. A fleet that mixes cloud instances with Robot bare metal for cost reasons has to keep that bare-metal tier in Europe, which reintroduces the exact latency problem this piece just solved — just for one tier of the stack instead of all of it.

CAPH support is real, but region-scoped. Cluster API Provider Hetzner does support multi-region clustering across Nuremberg, Falkenstein, Helsinki, Ashburn, Hillsboro, and Singapore, so a HetznerCluster object can legitimately target ash or hil as a node pool's region today. What it can't do is span a cloud-instance control plane in Ashburn with HetznerBareMetalHost workers, since Robot machines don't exist there to attach.

The June 2026 repricing didn't spare the US line. Hetzner's CPX and CCX instance families took the sharpest hikes in the June 15, 2026 adjustment — CPX21 now runs $37.49/month in the US, up substantially from where it sat a year ago. The CX line, including the CX22 this piece prices at $4.59/month, saw a smaller 31-38% increase in the same round. The compute math above still favors Hetzner by a wide margin, but "Hetzner is always the cheap option" is a claim worth re-checking per instance family, not assuming as a blanket rule.

Targeting Both Coasts From One Fleet​

The practical upside of Ashburn and Hillsboro existing as a pair, not a single region, is that a Cluster API-managed fleet can put worker capacity on both coasts without introducing a third provider or a third control plane. A MachineDeployment targeting us-east (Ashburn) can sit alongside one targeting us-west (Hillsboro) inside the same HetznerCluster, each pinned to its own location field:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCloudMachineTemplate
metadata:
  name: worker-us-east
spec:
  template:
    spec:
      type: cx22
      location: ash
      image: ubuntu-24.04

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCloudMachineTemplate
metadata:
  name: worker-us-west
spec:
  template:
    spec:
      type: cx22
      location: hil
      image: ubuntu-24.04

That gets a workload within roughly 10-30ms of the vast majority of US population centers without a CDN in front of it, using two MachineDeployment objects instead of a fleet-wide redesign. It's not the 18-region anycast mesh Fly.io ships by default, but it closes most of the gap between "single European region" and "actually distributed" for a fraction of the operational surface area — and it's a manifest change, not a new vendor relationship.

Who Should Actually Move​

The latency and cost case above doesn't land the same way for every migrator, because Render, Railway, and Fly.io don't share a regional architecture.

Render and Railway users get the clean win. Both platforms default to a single-region deployment per service — Render picks one of four regions (Oregon, Frankfurt, Singapore, Ohio) and runs your app there; Railway is similar, one region per service, chosen once at setup. A team on either platform serving primarily US traffic is already accepting single-region latency, which means routing that same single region through Ashburn or Hillsboro instead of Frankfurt is a straight upgrade with no architectural tradeoff — plus the bandwidth math from the table above.

Fly.io users are a different calculation. Fly's whole pitch is a global anycast network across 18+ regions with sub-100ms latency from most populated areas — Fly.io customers already have the latency problem solved by design, often better than a two-region Hetzner setup can match without deliberately building out a wider footprint. For that audience, the migration case has to be made on cost and control, not latency: owning the machines, avoiding Fly's per-resource metering, and accepting that matching an 18-region anycast footprint with two US regions plus Hetzner's European locations is a real architectural downgrade in raw geographic coverage, even if the economics still favor leaving.

The honest framing: this is a strong, overdue correction for anyone who ruled out Hetzner because of a latency assumption that stopped being true in 2022. It is not a reason to leave a platform whose actual value proposition is the global footprint itself.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned through Cluster API onto regions like Hetzner's Ashburn and Hillsboro without hand-wiring the node pools yourself. Star the repo on GitHub or deploy your first app today.