Regions · cmdz

The map

Where we run today, and where we are going

The Netherlands is the flagship and the default. Frankfurt is open. London, New York and Singapore are on the roadmap — we list them as planned rather than as coverage, because a region that does not exist yet is not a feature.

Latency figures are indicative, measured from Amsterdam. Price can differ slightly per region because power, hardware and connectivity differ per location; you see the price for your region before you create anything, and the ceiling works the same everywhere.

The rules

What a region does and does not promise

Within a region: we handle it

Multiple nodes, at least two replicas, database failover and replicated storage. A node dying is our problem and you should not notice it.

Across regions: you choose

Run the same app in two regions and split the traffic. We give you the building blocks — per-region environments, health-driven DNS, cross-region read replicas — and you choose the level of redundancy and the recovery objective you actually need.

What we do not promise

Automatic, seamless failover between regions. Not in this version. Saying so now is worth more than saying it after an outage, and anyone who tells you otherwise about their own platform is worth a second question.

Data residency

Choose an EU region and your data stays in the EEA, including its backups and its logs. The data processing agreement names the country and the data center per region, and you can download it without a sales call.

Region is per environment

Not per account. Production in Rotterdam and staging in Frankfurt is an ordinary configuration, and the region is visible on the environment, the app, the database and the invoice.

Moving regions

Redeploy in the target region and migrate the data through a backup restore. It is a deliberate operation rather than a live migration, and the path exists and is documented.

Your own redundancy

What running in two regions actually involves

Create a second environment of the same project in another region and deploy the same commit to it. Put health-driven DNS in front of both: multiple A and AAAA records with health checks, so a region that stops answering drops out of the rotation.

For state, run your database in one region as the primary and a read replica in the other. Writes stay in the primary region; synchronous multi-region writes are out of scope, and we would rather be clear about that than sell you a consistency model we have not built.

The result is a setup that survives a data center outage with a short interruption for writes, at roughly double the compute cost of a single-region setup — which you can see in the calculator before you commit to it.

Calculate what that costs

two regions, one app

$ cmdz env create production-fra --region de-fra-1
  ✓ environment created · de-fra-1

$ cmdz deploy --env production-fra
  ✓ live · 2 replicas · de-fra-1

$ cmdz db replica add --from nl-rtm-1 --to de-fra-1
  ✓ read replica streaming · lag 240 ms

$ cmdz domains health-dns linktree.dev \
    --targets nl-rtm-1,de-fra-1
  ✓ A/AAAA × 2 · health check every 10 s
  a failing region leaves the rotation in ~30 s

Questions

About regions and residency

Which region do I get if I do not choose?

Rotterdam, the default. You can change it per environment when you create one; you cannot silently be moved to another region afterwards.

Can my data end up outside the EEA?

Only if you put an environment in a region outside it yourself. Our EU regions keep everything — app, database, volumes, backups, logs — inside the EEA, and the subprocessor list in the data processing agreement names the supplier per region.

Why so few regions?

Because we own the hardware rather than renting capacity, and a region is a rack we paid for. That is the same reason the limit can exist. Regions open as hardware lands, and we list the ones that are not open yet as planned rather than as coverage.

Do I get my own IP address in my region?

You do not need one, and by default you do not have one. Every region gives your app free IPv6 and a shared IPv4 ingress with automatic certificates, so a custom domain is a CNAME or an A record and it works the same way in every region.

A dedicated IPv4 is the exception — for a raw TCP or UDP service, or a third party that only talks to an address on their allowlist. It is € 7.50 a month, on request, and availability is per region: we only issue one where that region has address headroom.

Does the price differ per region?

It can, slightly — power, hardware and connectivity differ per location, so the price book can carry a region factor. You see the price for your region before you create anything, and your ceiling behaves identically everywhere.

What if a region is full?

It is marked as limited or full and no new environments land in it until we add capacity. Existing workloads in it are unaffected, and you can create the new environment in another region in the meantime.

I have users in Asia today. Should I use you?

Not for latency-critical traffic, not yet. Singapore is on the roadmap and it is not open. We would rather tell you now than have you find out from a latency graph.

Pick a region and deploy into it.

It is a dropdown when you create an environment, and it is on every screen afterwards so you never have to wonder where something lives.

Create account Read the security page