Multi-Region SaaS on Hetzner Cloud: Data Residency and Low Latency Without AWS Complexity

A German enterprise customer signs the contract, then their security team asks where the data actually lives. A French customer complains that the app feels sluggish compared to a competitor's. A Polish prospect wants proof that nothing touches a US data center. These are the three pressures that push a growing SaaS company toward multi-region infrastructure, and running multi-region SaaS on Hetzner Cloud solves all three without the account complexity that AWS or GCP add to a small engineering team's plate.

Hetzner runs data centers in Falkenstein and Nuremberg (Germany), Helsinki (Finland), and Ashburn, Virginia. For a product selling into DACH, France, BeNeLux, and Eastern Europe, the three European locations already give you meaningful geographic spread inside the EU, which is the part that actually matters for GDPR and for latency to your paying customers.

Three ways to structure multi-region

Not every SaaS product needs the same shape of multi-region deployment, and picking the wrong one adds cost and operational risk without buying you anything.

Active-active with geo-aware routing sends each request to the nearest healthy region and keeps write paths open in more than one location at once. This is the right model when you have real usage in multiple countries and users expect the app to feel local wherever they are. It is also the hardest model to run correctly, because you now have to think about conflict resolution any time two regions accept writes for the same record.

Primary-secondary with regional read replicas is a much smaller lift. Writes go to one primary region, and read-heavy traffic (dashboards, reports, search) gets served from replicas closer to the user. Most SaaS products that think they need active-active actually need this. Latency on reads drops for everyone, writes stay simple, and you avoid the conflict resolution problem entirely.

Dedicated-region per enterprise customer is less an architecture pattern and more a sales requirement dressed up as one. Some enterprise buyers, particularly in regulated industries, will only sign if their tenant's data sits in an isolated deployment they can point to in an audit. If you have one or two customers like that, standing up a separate Hetzner project per customer, in the region they specify, is often cheaper than redesigning your core architecture around it.

Most teams start with primary-secondary, because it solves the immediate latency and residency problems without committing to the operational overhead of active-active before there's a proven need for it. If your traffic and revenue later justify writes closer to the user, you migrate to active-active as a deliberate step rather than building it speculatively.

DNS routing and load balancing

Hetzner Load Balancers handle traffic distribution and health checks within a region: if an instance in Falkenstein stops responding, the load balancer stops sending it traffic within seconds. What Hetzner Load Balancers do not do natively is geo-aware routing across regions, so that piece sits with Cloudflare in front of your Hetzner infrastructure.

Cloudflare's geo-steering (available on their load balancing product) routes a French user to your Helsinki or Falkenstein endpoint based on configured proximity rules, and fails over to a healthy region if the closest one goes down. The practical setup is a Cloudflare Load Balancer pointed at origin pools per Hetzner region, with health checks hitting a lightweight endpoint on each region's ingress. Cloudflare terminates TLS and handles the failover decision; Hetzner Load Balancers handle the distribution once traffic lands in a region. Neither layer needs to know much about the other, which keeps the configuration auditable instead of turning into a tangle of routing rules nobody fully understands six months later.

PostgreSQL replication across Falkenstein, Helsinki, and Ashburn

For the primary-secondary model, PostgreSQL streaming replication does the heavy lifting. A primary in Falkenstein streams its write-ahead log to standby replicas in Helsinki and, if you serve US customers, Ashburn. Reads for EU users get routed to the EU replicas; reads for US users go to Ashburn; writes always go back to Falkenstein.

The latency between Falkenstein and Helsinki over Hetzner's private network is low enough that synchronous replication is viable if you want a hot failover target with zero data loss. Asynchronous replication to Ashburn is the more realistic choice given the transatlantic distance, which means a small replication lag window and an acceptance that a US failover, if it ever happens, could lose the last few seconds of writes. Decide which trade-off is acceptable before an incident forces the decision for you.

A detail that's easy to miss during setup: replication traffic itself must stay inside the EU when your data residency commitment is EU-only. That means the Ashburn replica, if you have one, should only ever receive data from customers who are contractually and technically scoped to it, not a mirror of the entire database. Segmenting this at the data model or database level from the start avoids a much harder retrofit later.

Making the data residency guarantee hold up

Saying data stays in the EU is easy. Proving it to an auditor is the part most teams get wrong. Three things matter here.

First, your database, backups, and any queue or cache that touches customer data all need to live in EU regions, not just the application servers. It's common to see the app correctly deployed in Falkenstein while the error logging pipeline quietly ships stack traces (which often contain PII) to a US-based SaaS tool. Audit every service in your stack, not just the obvious ones.

Second, encryption keys need to be managed somewhere the US CLOUD Act can't reach through a US-headquartered provider. Hetzner is a German company, so keys managed and stored through Hetzner-native tooling stay outside that exposure in a way that keys managed through a US cloud provider's KMS do not, even if the KMS region is technically set to Europe.

Third, keep a record of where data physically lives at each processing step, because "we believe it's all in the EU" is not what an auditor wants to hear. A short architecture document naming each service, its region, and its data flow is worth more during due diligence than a polished pitch deck.

Deploying across regions without a scary release process

Rolling out a change across three regions at once is how a bad deploy becomes a multi-region outage instead of a contained one. A canary sequence protects against that: deploy to Helsinki first, watch error rates and response times for a defined window, then Falkenstein, then Ashburn. If Helsinki looks wrong, you stop before it reaches the regions serving the bulk of your traffic.

Kamal 2 handles this well for teams already running a Docker-based deploy pipeline, since it's built around exactly this kind of multi-host rollout. A minimal multi-region Kamal configuration groups hosts by region and lets you target a single region for a deploy:

servers:
  web:
    hosts:
      - 10.0.1.10
      - 10.0.1.11
    labels:
      region: falkenstein
  web-helsinki:
    hosts:
      - 10.0.2.10
    labels:
      region: helsinki
  web-ashburn:
    hosts:
      - 10.0.3.10
    labels:
      region: ashburn

Running kamal deploy -d helsinki pushes the release to the Helsinki group only. Once the canary window passes cleanly, the same command targets the remaining regions. It's a plain, inspectable process that doesn't require a service mesh or a dedicated release engineering function to operate.

What this costs against AWS or GCP

A rough comparison, using the kind of setup a mid-size SaaS product would run: three regions, a primary database with two read replicas, load balancing, and enough compute to handle real production traffic.

On Hetzner, that setup runs somewhere in the range of 400 to 700 euros a month, largely because Hetzner's compute and bandwidth pricing is a fraction of the hyperscalers' and because there's no charge for cross-region data transfer within their network the way there is between AWS regions. The equivalent setup on AWS, using RDS Multi-AZ read replicas, Application Load Balancers per region, and EC2 instances sized to match, typically lands between 2,000 and 3,500 euros a month once you account for data transfer charges between regions, which AWS bills separately and which add up quickly with cross-region replication traffic.

The gap isn't just sticker price. AWS's multi-region primitives (Route 53 latency routing, cross-region RDS replicas, VPC peering) are more powerful and more automated at very large scale, but they also come with a steeper learning curve and more moving parts to secure and monitor. For a team without a dedicated platform engineer, Hetzner plus Cloudflare plus Kamal is a setup one or two backend engineers can actually own end to end.

Where this fits into a broader technology decision

Multi-region infrastructure is rarely a decision made in isolation. It usually comes up alongside a bigger question about whether your current stack, hosting strategy, and deployment process can support where the business is heading. If you're weighing this against a wider tech stack strategy review, or the infrastructure question has come up as part of a larger digital transformation push, it's worth working through the full picture before committing to a region topology you'll need to live with for years.

If your existing application needs work before it can support multi-region deployment cleanly, whether that's decoupling the data layer or rebuilding parts of the deployment pipeline, that's the kind of project we handle through custom software development.

Wolf-Tech works with SaaS teams on exactly this kind of infrastructure decision, from picking the right deployment model to setting up the replication and rollout process that keeps it running quietly in the background. If you're weighing Hetzner against AWS for a multi-region build, get in touch at hello@wolf-tech.io or find more of our work at wolf-tech.io.