Architecture
Before integrating Prysm:ID it pays to understand a foundational decision that makes everything else cohere: each workspace gets its own dedicated instance. This isn’t marketing — it’s the shape of the product.
The model in one sentence
Section titled “The model in one sentence”A Prysm:ID workspace = one dedicated instance, with its own domain (
auth.<slug>.prysmid.com), its own user database, its own key store, its own audit log.
When you sign up as a Prysm:ID customer, we provision an independent stack for you. When your customer audits you and asks “do you share a database with other tenants?”, the answer is no.
Why it matters
Section titled “Why it matters”The B2B auth industry mostly sells logical multi-tenancy: one database, all tenants coexisting, separated by a tenant_id column. It’s efficient for the provider and adequate for many use cases. But it breaks on three axes:
1. Data isolation.
A query bug (missing WHERE tenant_id = ?) leaks data across tenants. There are public precedents. Physical isolation eliminates that class of bug.
2. Compliance. GDPR, LGPD, SOC2 enterprise: the auditor asks “where does my company’s data live?”. With a dedicated instance, the answer is “in this host, this DB, this key store” — not “in a column among 50,000 other customers’ data”.
3. Portability. If you want to leave, the export of your instance is complete and self-contained. You stand up your own infrastructure, import the dump, point DNS. No “shared-table dependencies”.
What it looks like in practice
Section titled “What it looks like in practice” Prysm:ID Platform┌──────────────────────────────────────────────────────────────────────┐│ ││ app.prysmid.com ◀── you (admin) ─┐ ││ api.prysmid.com ◀── your app ────┤ ── control plane ││ npx @prysmid/mcp ◀── your agent ──┘ ││ ││ ┌──────────────────────────────┐ ┌──────────────────────────────┐ ││ │ workspace acme │ │ workspace globex │ ││ │ ─ auth.acme.prysmid.com │ │ ─ auth.globex.prysmid.com │ ││ │ ─ dedicated instance │ │ ─ dedicated instance │ ││ │ ─ own DB schema │ │ ─ own DB schema │ ││ │ ─ own JWKS │ │ ─ own JWKS │ ││ │ ─ users, IdPs, apps │ │ ─ users, IdPs, apps │ ││ └──────────────────────────────┘ └──────────────────────────────┘ ││ ▲ ▲ │└───────────┼──────────────────────────────────┼───────────────────────┘ │ │ users of acme users of globexControl plane (app.prysmid.com, api.prysmid.com, npx @prysmid/mcp): where you administer your workspaces. Dashboard, webhooks, billing, API and MCP live here.
Data plane (auth.<slug>.prysmid.com): your workspace’s own dedicated instance. Your end users talk here to log in. Your app talks here to validate JWTs via JWKS.
The two planes are separated by design. An outage on app.prysmid.com does not stop your users from logging in — their instance is still there.
Terms worth pinning
Section titled “Terms worth pinning”| Term | What it is | Who owns it |
|---|---|---|
| Workspace | Your account in Prysm:ID. One of your organizations. | You (Prysm:ID customer) |
| Instance | The auth engine of your workspace. One per workspace. | You (Prysm:ID operates it) |
| Tenant | Your B2B customer. Lives inside your instance. | You (one per each of your customers) |
| Project | A “logical app” grouping. Contains OIDC clients. | You (one per app you register) |
| OAuth client | A concrete app (web, mobile, SPA) with its client_id/secret. | You |
| User | A real person who logs in. Lives in your instance. | You (Prysm:ID persists them) |