OrthıD
Browse the docs
Operations

Regions

A region is a sovereign boundary. Your managed cell lives in exactly one region, and every record, key and token belongs to it - nothing crosses that boundary unless you make it.

One region live today
One region is live today. The wider region map and the public hosted regional API are target architecture on our roadmap. Identifiers and endpoints below describe the model OrthID is built around, not a set of live public endpoints.

Your sovereign cell is a dedicated, isolated managed deployment in the region you choose. Identity data, encryption keys, audit logs and session state are written, read and processed only inside that region. There is no shared global control plane that can see your tenants’ data, which is what lets OrthID make hard residency guarantees instead of best-effort ones. For the model behind this, read Regions & sovereignty.

Available and planned regions

One region is live today; the others are on our deployment roadmap. Each region has a short, stable identifier. That identifier names where your cell runs, appears in your region’s API base URL, and is carried by ORTHID_REGION in your application config and when issuing region-bound agent credentials.

RegionLocationResidencyStatus
au-syd-1Sydney, AustraliaAUAvailable
au-mel-2Melbourne, AustraliaAUPlanned
uk-lon-1London, United KingdomUKPlanned
eu-fra-1Frankfurt, GermanyEUPlanned
us-chi-1Chicago, United StatesUSPlanned

Reach your region

Set ORTHID_REGIONon every process that talks to OrthID. The SDK uses it to route to your cell’s regional endpoint, and the server rejects any request whose key does not belong to that region, so a misconfigured client fails closed rather than leaking across a boundary.

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

The region also fixes the API base URL. The target architecture gives every regional cell a predictable host of the form api.<region>.orthid.io. The live region is reachable today; the rest follow as each region is stood up:

Region endpoint (target architecture)
https://api.au-syd-1.orthid.io   # available now
https://api.eu-fra-1.orthid.io   # planned
https://api.us-chi-1.orthid.io   # planned
Keys are region-scoped
A secret key issued in one region is not valid in another. If you move a workload between regions you must rotate to a key issued in the new region; the old key will start returning region_mismatch errors immediately.

Residency guarantees

For a cell pinned to a region, OrthID guarantees that:

  • Data at reststays in-region. The database, object storage and backups are provisioned and replicated only within the region’s jurisdiction.
  • Keys never leave.Signing and encryption keys live in the region’s KMS or HSM. With BYOK, OrthID never holds the key material at all - see BYOK.
  • Processing is local. Token verification, RBAC evaluation and audit writes all run in-region. Tokens are signed by region-local keys and cannot be verified elsewhere.
  • Telemetry is scrubbed. Operational metrics carry no tenant or subject data, so nothing identifying crosses the boundary.

Multi-region

Each region is independent. Operating in several regions means 3verest provisions several cells, each with its own keys, database and identifiers. OrthID does not silently replicate identities between them, because that would defeat the residency guarantee.

If you operate in more than one jurisdiction, the common patterns are:

  • Route by tenant.Decide a tenant’s home region at sign-up and send that tenant’s traffic to the matching regional endpoint for its entire lifetime.
  • Separate keys per region. Keep one key pair per region and select them with ORTHID_REGION rather than sharing a single key across deployments.
  • Bind agents to a region. When you issue an agent credential, set region so the delegated identity is only ever usable inside that boundary.
agents.ts
import { orthid } from "@orthid/sdk";

// An agent credential issued in au-syd-1 is only valid in au-syd-1.
const agent = await orthid.agents.issue({
  onBehalfOf: "user_5f3a",
  scope: ["records:read"],
  ttl: "10m",
  region: "au-syd-1",
});
Need cross-region behaviour?
Federating users across regions (for example, letting one human sign in to tenants in two jurisdictions) is an application-level decision you make explicitly, never a default. Model it as separate identities that your app links, so each region’s data stays sovereign.

Next steps