Self-hosting & operations

Regions

A region is a sovereign boundary. Every record, key and token belongs to exactly one region, and nothing crosses that boundary unless you make it.

OrthID runs as an isolated deployment in each region. Identity data, encryption keys, audit logs and session state are written, read and processed only inside the region you choose. 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 regions

Each region has a short, stable identifier. You use that identifier in the ORTHID_REGION environment variable, in API base URLs, and when issuing region-bound agent credentials.

Region	Location	Residency
`au-syd-1`	Sydney, Australia	AU
`au-mel-2`	Melbourne, Australia	AU
`uk-lon-1`	London, United Kingdom	UK
`eu-fra-1`	Frankfurt, Germany	EU
`us-chi-1`	Chicago, United States	US

Pin a deployment to a region

Set ORTHID_REGION on every process that talks to OrthID. The SDK uses it to route to the correct regional endpoint, and the server rejects any request whose key does not belong to that region, so a misconfigured deployment 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. Every regional deployment is reachable at a predictable host:

Region endpoint

https://api.au-syd-1.orthid.com
https://api.eu-fra-1.orthid.com
https://api.us-chi-1.orthid.com

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 deployment pinned to a region, OrthID guarantees that:

Data at reststays in-region. Postgres, 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. Running in several regions means running several deployments, 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

Regions & sovereignty - the concepts behind residency and data boundaries.
Deploy - stand up a regional deployment.
BYOK - keep key material in your own KMS or HSM.