Provisioning
3verest provisions OrthID for you as a dedicated, isolated, region-pinned sovereign cell. This page describes what that managed deployment looks like - the data-plane and control-plane split, capacity, and the checks that confirm your cell is ready - and what you choose before it is stood up.
You do not deploy OrthID. 3verest provisions a dedicated, isolated deployment - your sovereign cell - in the region you choose, and operates it for you. For the managed model overall, start with Sovereign deployment. To run in more than one region, 3verest provisions one cell per region; see Regions.
What you choose before provisioning
Before your cell is stood up, you settle a small number of decisions with 3verest:
- Region. The jurisdiction your cell is pinned to. Identity data never leaves it.
- Key custody. Whether OrthID manages your encryption key or you hold it yourself with BYOK.
- Public origin. The HTTPS origin your cell is reached at. It is baked into token issuer and audience claims and into redirect URLs, so it is fixed at provisioning time.
Inside your cell: data plane and control plane
A sovereign cell separates two responsibilities so they can scale and fail independently. This split is operated for you, but it is useful to understand how your cell behaves.
- Data plane: the request-path services that verify sessions, issue tokens, mint agent credentials, and serve sign-in. This is the hot path. It is stateless and horizontally scaled, and it is the only tier your apps reach. It holds open connections to the database and your key provider but keeps no local state.
- Control plane: the management services behind the admin consoles, plus background workers (audit archiving, key rewrap, SCIM sync, scheduled exports). It tolerates brief downtime without affecting live sign-ins and is never exposed to the public internet.
Both planes share one database and one key provider, all inside your region. Keeping them separate means a surge of console or batch activity cannot starve the sign-in path, and each can be scaled independently.
Capacity
OrthID is light on the request path because sessions.verify() validates JWTs locally and adds no network hop. 3verest sizes your cell to your scale and lets the data plane autoscale from there. The figures below are indicative of how a cell is sized.
| Prop | Type | Default | Description |
|---|---|---|---|
Up to 100k MAU | data plane | baseline | Stateless request path with headroom for bursts; in-region managed Postgres with point-in-time recovery. |
Up to 1M MAU | data plane | autoscaled | Data plane autoscales with sign-in volume; the database scales up with a read replica for the control plane. |
Control plane | any size | fixed | Consoles and workers, sized by background job volume (SCIM, exports) rather than sign-in traffic. |
Database | shared | - | The capacity constraint at scale. 3verest provisions connections and IOPS for peak sign-in bursts and enables point-in-time recovery. |
TLS and the public origin
All traffic to your cell is HTTPS; the API rejects plaintext, and session cookies are set Secure. 3verest provisions and renews the certificate for your origin. The publicUrl you choose is the exact HTTPS origin OrthID is reached at; because it is baked into token issuer and audience claims and into redirect URLs, it is settled before provisioning.
Ready to use
Before your cell carries real traffic, 3verest confirms both planes are healthy: the request path reports every dependency connected (database, storage and the key provider), TLS terminates on your origin, and a sign-in round trip succeeds. You are handed a cell that is already verified and serving.