A Region Is Not A Jurisdiction

When a customer says their data must stay in their own country, resist the instinct to hear "deploy another copy in a different region". A region is a location on a provider's map. A jurisdiction is a set of promises about who can touch the data, who can be compelled to hand it over, and who is allowed to switch it off. Those are different things, and the gap between them is where the real work lives. The sooner you plan for that gap, the cheaper it gets.

I was reminded of this recently when a European requirement turned up for a product we already run happily in Australia. The first, entirely natural question was the one most of us would ask: do we build the server component three times, one per country, or do we build it once and let the client choose where to point? It sounds like a packaging question. It is actually the question that decides whether the next jurisdiction takes a week or a quarter.

Build once, point at runtime

My strong preference is one artefact and a location setting. If every jurisdiction gets its own build, every fix has to be made, tested and shipped several times, and sooner or later the builds drift. Nobody decides that they should drift. One gets a hotfix at a bad hour and the others get it on Tuesday, and now you are supporting three subtly different products under one name.

A single build with the destination supplied as configuration keeps the thing you test identical to the thing you ship everywhere. The client app, whether it is a phone, a handheld scanner or a browser, learns which server to talk to from a setting rather than from the code it was compiled with. That also means a user who legitimately moves between countries, or a support person who needs to look at two environments in one afternoon, does not need a different installation.

The trade-off is real. A location switcher is a new piece of surface area. Someone has to decide who is allowed to change it, how it is protected from tampering, and what happens when it points somewhere unexpected. Data that is supposed to stay in one place is exactly the kind you do not want an accidental toggle to send somewhere else. So the switch needs to be boring, deliberate and hard to flip by accident. It still beats three codebases.

The cloud account is part of the border

The part that surprised me was how much the provider side looks like a separate world once sovereignty is the point. As I understand it, some providers now offer sovereign offerings that are not a region inside the usual global estate at all. They sit in their own partition, with their own sign-up, their own identity system, their own endpoints and their own operating staff. That is the whole point: if the same administrative plane controlled both, you would not really have separation, only geography.

The practical consequence is that none of what you built for your existing environment carries over for free. Your accounts do not exist there. Your pipelines cannot assume the familiar endpoints. Your identity setup, your monitoring, your alert routing and your billing are all fresh. A deployment that took a couple of lines of configuration in the first region now needs someone to create the account, establish trust, and work out how your own delivery tooling is permitted to reach into a place built to resist being reached into.

None of that is a reason to avoid it. It is a reason to put it in the plan as work, rather than discovering it on the Thursday before a customer's deadline. Ask for the account early, because the slowest step is often waiting for something to be provisioned by a human on the other side of a process. Write the stories for the pipeline and the monitoring and the access model before you write the story for the application. The application is usually the easy part, because by then it is already a single build that only needs to be told where it lives.

Who is allowed to operate it

The question I would put on the table earliest is also the least technical: who gets to administer this environment? If the point of a local deployment is that data stays under local control, then the people with production access matter as much as the building the servers sit in. A team that is spread across several countries has to decide, deliberately, whether its usual habits still hold. Can anyone on the team log in to the production console? Can logs, which often contain more than we admit, be shipped back to a central place for convenience?

This is where I think we sometimes confuse compliance with responsibility. It is easy to tick the residency box by storing the database in the right country while the logs, backups, error reports and the person debugging at midnight all sit somewhere else. The customer did not ask for the database to be nearby. They asked for their data to be under their rules. Every copy, every trace and every convenience path is part of the answer.

That is also an argument for restraint. The least risky data is the data you never carried across the border in the first place. Before you replicate a pipeline into a new jurisdiction, ask whether the central dashboard truly needs to see raw detail, or whether counts and health signals would do. You will often find that the cleaner design is also the cheaper one to run.

Small habits that pay off

Little decisions scale surprisingly well in a setup like this. Point clients and proxies at the stable name a platform gives you, not at an address you looked up once, because addresses behind managed load balancers are not a promise and names are. Keep an exact copy of any hand-edited network configuration somewhere versioned, so you know what changed when something goes quiet. Make alerting work in the new environment on day one rather than after the first incident, and check it by actually receiving one.

There is also a commercial side that deserves honesty. A separate jurisdiction costs more to run than a shared one, and it will not pay for itself through volume if it serves one customer. Sometimes that cost is entirely justified, because the work cannot be won without it, and sometimes it is a signal that the price needs to reflect the carrying cost. Better to have that conversation before the account exists than after the invoice.

If I had to compress all of this into one habit, it would be to treat each jurisdiction as a first-class deployable unit: one build, a runtime destination, its own account, its own operators and its own way of knowing when something is wrong. That is more upfront thinking than copying a stack into another region. It is also what the customer was actually asking for, whether or not they knew to put it that way.