Regions
Where your services and databases physically run, and what that means for latency and data residency.
How regions work
A region is chosen per project, when you create it. Every service, managed database and volume in the project runs in that region, on Hetzner hardware, so a service and its database are always close to each other.
Services you run on your own machines are the exception: they run wherever that machine is.
Available regions
| Region | Slug | Hetzner location | Status |
|---|---|---|---|
| Helsinki, Finland | eu-central-1 | hel1 | Available · default |
| Nuremberg, Germany | eu-central-2 | nbg1 | Planned |
| Falkenstein, Germany | eu-west-1 | fsn1 | Planned |
| Ashburn, Virginia, US | us-east-1 | ash | Planned |
Every project runs in Helsinki today, and the create-project dialog offers only that region. A planned region appears in the dialog once HostStack has machines running in it; the API refuses a project in a region that isn't available yet.
Latency
Traffic between a service and its database stays on the project's private network inside the region, so a managed database behaves like a local one.
Your users reach Helsinki over the public internet, so their latency depends on where they are. Northern and central Europe is close; the rest of Europe is further; North America and Asia are across an ocean. Measure from where your users are rather than relying on a table — this prints the time to open a connection, in seconds:
curl -o /dev/null -s -w '%{time_connect}\n' https://web-a1b2.hoststack.devData residency and GDPR
Helsinki is in the EU. Customer data in it — database contents, volumes, backups and logs — stays inside the EU. The Nuremberg and Falkenstein regions are in the EU too.
The planned Ashburn region will be for workloads that must run in the US. It will not be EU-resident, so keep EU users' personal data in an EU region.
The formal commitments, sub-processors and locations are in the Data Processing Agreement and the privacy policy.
Next steps
Was this page helpful?