Choosing a region: data residency and your own redundancy

A region here is a physical location: a rack or hall with its own power, network and cooling path. Not an availability zone abstraction, not a logical grouping. Somewhere you could, in principle, drive to.

What choosing one guarantees

Your app, its databases, its volumes, its backups and its logs live in that region and do not leave it. Not for a failover, not for a maintenance window, not for a batch job that seemed convenient.

That last point is where a lot of "EU region" claims get soft. A control plane in another jurisdiction, logs shipped somewhere central, backups replicated to whichever bucket was cheapest — all of that is common and all of it undermines the answer you give when a customer asks where their data is. Ours does not do it.

Choosing is per environment

Not per account. Production in Rotterdam and staging in Frankfurt is an ordinary configuration, and the region appears on the environment, the app, the database, the backup and the invoice line. You should never have to go looking for where something lives.

What we handle, and what we do not

Within a region we handle high availability. Multiple nodes, at least two replicas, database failover, replicated block storage. A node dying is our problem and you should not notice it.

Across regions, redundancy is yours to arrange. We give you the building blocks:

• per-region environments of the same project
• health-driven DNS, so a region that stops answering leaves the rotation
• cross-region read replicas for Postgres

What we do not promise is automatic, seamless multi-region failover. Not in this version. That is a hard problem with real consistency trade-offs, and a platform that claims it casually is either doing something narrower than it sounds or has not been tested by an outage yet.

We would rather write that sentence on the website than have you discover it on a bad afternoon.

Running one app in two regions

cmdz env create production-fra --region de-fra-1
cmdz deploy --env production-fra

cmdz db replica add --from nl-rtm-1 --to de-fra-1
cmdz domains health-dns linktree.dev --targets nl-rtm-1,de-fra-1

Four commands. What you get:

• Two independent copies of your app, in two failure domains.
• DNS with health checks; a failing region leaves the rotation in about thirty seconds.
• A read replica in the second region, with visible replication lag.

What you should be clear-eyed about: writes still go to the primary region. If Rotterdam goes down, the Frankfurt copy serves reads immediately and writes need a promotion, which is a deliberate operation. Synchronous multi-region writes are not something we offer, and if that is your requirement, we are not your platform for it.

The cost

Roughly double the compute, plus the replica. For the Next.js app from an earlier post — about € 7 a month single-region — a two-region setup lands around € 15.

Whether that is worth it depends entirely on what an hour of downtime costs you, and that is a number you know and we do not. Run it through the calculator before you decide.

Which region to pick

Rotterdam (nl-rtm-1) is the default and the flagship. Pick it unless you have a reason not to.

Amsterdam (nl-ams-1) is the second Dutch region — the natural pair for a two-region setup that stays entirely inside one jurisdiction.

Frankfurt (de-fra-1) is the German region. Still EEA, and a genuinely separate failure domain from either Dutch site.

London, New York and Singapore are on the roadmap and are listed as planned, not as coverage. A region that does not exist yet is not a feature, and we are not going to draw a dot on a map that implies otherwise.

If you have latency-critical users in Asia today, we are honestly not the right choice yet. Better to hear that here than from a latency graph.

Residency and the paperwork

Choose an EU region and your data — including backups and logs — stays in the EEA. The data processing agreement names the data center and the supplier per region, and you can read it on this site without giving anyone an email address.

If you deliberately choose a region outside the EEA once we have one, that choice is an instruction under the DPA and we will tell you what it implies rather than let it happen quietly.

Price per region

Power, hardware and connectivity differ per location, so the price book can carry a small per-region factor. You see the price for your region before you create anything.

The ceiling behaves identically everywhere. That is not region-dependent and it never will be.