If you’re choosing your hosting in 2026 with a “modern SaaS” reflex, you reach for AWS or GCP, click the EU region toggle, and spend the next six months scaling auto-managed services until the bill is the second-largest line item on your P&L. We did not do that. We are on Hetzner — dedicated 1U servers, in Falkenstein, Germany, racked metal — and we plan to stay there for the foreseeable future.

This post walks through the decision honestly. There are real tradeoffs. We pay them deliberately.

What we evaluated

The shortlist for an EU-sovereign-by-architecture product was:

  • Hetzner Online GmbH (Germany). Dedicated and cloud servers. EU-incorporated, EU-owned, EU-operated. Pricing that’s in a different universe from US hyperscalers.
  • Bunny.net / OVHcloud (Slovenia / France). Cloud + CDN. We use Bunny for static assets and CDN; we considered them for compute but the developer ergonomics weren’t there yet for our application stack.
  • Scaleway (France). The French sovereign-cloud player. Solid product, prices closer to AWS than to Hetzner.
  • AWS-EU / Azure-EU / GCP-EU. Out from the start. The “EU region of an American cloud” is the precise thing we’re rejecting on principle. We can’t differentiate on sovereignty if our entire stack runs on US-incorporated infrastructure.
  • Self-host on a co-located server. Considered for ten minutes, rejected. Solo-founder companies don’t run racks.

We chose Hetzner for compute and Postgres, Bunny for CDN and static assets, and Plausible (German company, EU-hosted) for analytics.

Why Hetzner specifically

Three reasons.

Pricing that lets us run a real product on a real budget. A 1U dedicated server with 64GB RAM, NVMe storage, and a gigabit pipe is around €35–50/month. The equivalent EC2 instance — by raw compute and memory — is six to eight times that, before you add EBS volumes, NAT gateway costs, S3, CloudFront, RDS surcharges, and the support plan. For a bootstrapped solo-founder company, the difference between €50/month and €400/month per server is the difference between “we can afford to run this” and “we can’t.”

EU-incorporated by primary structure. Hetzner is a German company, owned by German individuals, headquartered in Gunzenhausen, with datacenters in Falkenstein, Nuremberg, and Helsinki. The corporate structure is not a tax-optimization vehicle for a non-EU parent. It’s actually European. That matters for the sovereignty pitch in a way that’s hard to overstate.

Boring, durable infrastructure. Hetzner has been running this business for over thirty years. The interface is utilitarian. The provisioning experience is “fill in the form, server is racked in 90 seconds.” The support is German-engineering-thorough but not pamper-the-customer. The thing they sell is uptime and bandwidth at a price that hasn’t dramatically changed in a decade. We can plan around that.

What we accept as the tradeoff

The honest list:

No managed Postgres. No managed Redis. No managed anything. We run Postgres on dedicated metal with pgBackRest for backups. Redis on dedicated metal. Reverb (Laravel’s WebSocket layer) on dedicated metal. Application on dedicated metal. We are responsible for upgrades, security patches, replication topology, failover testing, and on-call. This is a real cost. We mitigate it with: explicit runbooks, weekly verified backup-restore tests, monitoring via Plausible + a self-hosted Prometheus. The application architecture is designed forward to make this manageable — for example, Postgres RLS is an architectural choice partly because it removes the need for application-layer tenant-scoping bugs to become incidents.

No instant horizontal autoscaling. We can’t conjure ten more application servers in 60 seconds when traffic spikes. We can provision a new dedicated server in 90 seconds via Hetzner’s UI, but spinning up the application on it is a deliberate operation, not an autoscale event. We size capacity for the peak we expect, plus a margin. For a B2B chat product where the user base grows on a predictable curve, this is fine. For a viral consumer product, it would be terrible. We are not a viral consumer product.

No fancy regional failover stories. We are single-region (Falkenstein, with Helsinki backups). True multi-region active-active with global read replicas is not on the v1 roadmap. We have a cold-standby in Helsinki that we can failover to within a few hours; we accept the few-hours RTO. Customers who need 99.999% multi-region uptime today are not our target customer for v1.

Limited ecosystem of “I can integrate with this in one click” services. Hetzner doesn’t have a Marketplace of pre-baked AWS-style integrations. Everything we need (queue, search, object storage) we either run ourselves or pair with a separate EU-incorporated provider. We have made peace with running our own components and treating it as a competitive advantage in pricing pass-through to customers.

The mental shift back to “ops is a real job.” This is the biggest one. SaaS companies of the 2015–2025 era treated infrastructure as a managed-service abstraction. Going back to “we run servers” is a regression in some sense — but it’s also the thing that makes single-region simple, single-team operable, and structurally European.

Why this isn’t risky

The most common objection is: “what about availability?” Three things mitigate it.

Dedicated 1U metal with redundant power, cooling, and network is more reliable per-unit than a comparable cloud VM. AWS EC2 instances live and die on shared hardware whose failures are abstracted. A bare-metal Hetzner server has fewer abstractions to fail through. The failure mode is “the entire physical machine dies,” and we plan around it with hot-spare hardware and known-good restore procedures.

Backups and disaster recovery are tested, not assumed. Per our integrity principles, backups are checksum-verified at write time and restored to a scratch instance weekly. An untested backup is treated as no backup. The Helsinki cold standby has a documented restoration path that we run quarterly.

The application is designed to lose any single component. The Postgres-then-broadcast pattern (database commit before WebSocket dispatch) means a Reverb crash doesn’t lose data. RLS at the database means an application-layer bug doesn’t leak data across tenants. The audit log is database-enforced immutable, so even a compromised application role cannot tamper with the trail.

The longer-term call

We will outgrow this setup. The honest forecast is “in eighteen to thirty months, we will need multi-region with active-active replication and the on-call story for that requires more than a solo founder.” We have a plan for that, and the plan is to add a hire, not to migrate to a hyperscaler. The infrastructure that will replace today’s Hetzner setup is more Hetzner servers, in more European cities, with better tooling around them. Not GCP-EU.

Sovereignty is an architectural decision, and reversing it for ergonomic reasons is the slip the entire incumbent set has already made. We chose differently because we think the customer base we’re building for cares about that choice, in writing, in their DPA. The Hetzner-as-primary-host call is one of the consequences of that decision. We pay it deliberately, and we’ll keep paying it.

— The founder, Stockholm, 2026-05-03