OrthıD
Browse the docs
Concepts

Regions & sovereignty

Every actor and every byte of their data lives in a region you choose, and it stays there. Sovereignty is the default, not an add-on.

OrthID is built for regulated industries where data residency is a legal requirement, not a preference. A region is an isolated deployment in a specific jurisdiction. When you create an organisation, you pin it to a region, and from then on its users, sessions, tokens and audit records are stored, processed and encrypted there.

Data residency

Residency means the physical location of your data is guaranteed. An organisation pinned to au-syd-1 has its identity data in Sydney: at rest, in transit and in backups. There is no central data plane that aggregates across regions. Each region is a self-contained deployment with its own database, keys and signing material.

Region pinning

You pin a region at the SDK level with the ORTHID_REGION environment variable. The SDK routes every call to that region’s endpoint, and tokens are signed with that region’s keys. Set it once in your environment:

.env
ORTHID_REGION=au-syd-1
ORTHID_SECRET_KEY=sk_live_...
NEXT_PUBLIC_ORTHID_PUBLISHABLE_KEY=pk_live_...

An organisation cannot silently move regions. Migration is an explicit, audited operation, never a side effect of a request.

Customer-managed keys (BYOK)

By default OrthID manages the encryption keys for your region. For stricter control, the model is designed so you can bring your own keys: OrthID encrypts your data with keys held in your own KMS, HSM or Vault, and never sees the key material. Revoke the key and the data is cryptographically inaccessible, even to OrthID. Customer-managed keys and HSM custody are on the roadmap and available to design partners. See the BYOK guide for the planned model.

What never leaves the region

The following are confined to the region you pin and never cross its boundary:

  • User profiles, credentials and passkeys.
  • Sessions, refresh tokens and signing keys.
  • Organisation membership, roles and scopes.
  • Audit logs and provenance records.
  • Encryption keys, including BYOK material in your own KMS.
Tokens are verified in-region
Because each region signs with its own keys, an access token issued in eu-fra-1is verified against that region’s public keys. There is no global key that could validate tokens across jurisdictions.

Available and planned regions

One region is live today. The wider region map is our deployment roadmap: each entry is a residency boundary we operate in or are standing up, and the identifiers below are the targets the model is designed around.

  • au-syd-1 - Sydney, Australia. Available now.
  • au-mel-2 - Melbourne, Australia. Planned.
  • uk-lon-1 - London, United Kingdom. Planned.
  • eu-fra-1 - Frankfurt, Germany. Planned.
  • us-chi-1 - Chicago, United States. Planned.

Next steps