Deployment models — managed SaaS & self-host

Zynth Auth is delivered two ways, and — this is the important part — both run from one codebase. The tier you're on is a configuration/entitlement value, never a fork, a separate branch, or a different product. What a plan grants in the cloud and what a licence grants on-premise resolve through the same mechanism, so the feature set does not drift between them (ADR-0051, ADR-0053).

Private beta (2026-09). The managed service is in a private, invitation-only beta: nothing can be purchased yet and self-host is not offered to customers during it. Everything below describes the committed model, not what you can buy today.

What's available today vs. what's sequenced. This page describes the committed model. To avoid overselling: managed SaaS is the live delivery path. The distribution machinery licensed self-host depends on — signed release channel, verifiable offline bundle, licence-gated per-customer download, customer-safe self-service patching — is now built and dogfooded (Phase 25); what remains sequenced is commercial self-host GA (the last step in the launch order below), a business decision, not an engineering gap. The reference deployment self-host packages is the exact stack we run in production — see Self-hosting.

The two models

	Managed SaaS	Licensed self-host
Who runs it	Zynth (our infrastructure)	You, in your own region/infrastructure
Isolation	Pooled — shared infrastructure, isolated at the row level by two independent boundaries. A single-tenant tier with its own database is designed for and not yet built	Your instance is inherently single-tenant
Best for	Fast start; individuals → SMB → enterprise	Regulated / sovereignty / air-gapped buyers
Entitlements from	Your plan (control-plane database)	A signed offline licence bundle
Availability	Live	Machinery built (Phase 25); commercial GA sequenced last — see below

How the tier actually resolves — the features and caps a plan or licence grants, how usage is metered, and why a limit never interrupts sign-in: Plans, entitlements & usage.

One codebase, no forks. Because the tier is an entitlement and the reference deployment is the distribution artifact, a self-hosted install and a SaaS tenant get the same protocol surface, the same security posture, and the same upgrade path. There is no "community edition" that lags behind — the day a capability ships, it ships for both models (gated by entitlement, not by build).

Tenant isolation (both models)

On managed SaaS, each organization is a tenant with an isolation strategy. Every organization is pooled today — shared infrastructure, isolated at the row level; the dedicated value (its own database) is reserved for a single-tenant tier that is designed for and not yet built, and no organization holds it. See Tenants & users. Pooled isolation is enforced by two independent boundaries — an always-scoped data layer and Postgres row-level security beneath it — so a bug in one is not a cross-tenant leak. The buyer-facing detail is in Security & tenant isolation. A self-hosted install is a single-tenant deployment by nature, but runs the identical isolation machinery.

Integration: standards-based, with an SDK on top

Zynth Auth is a standards OpenID Provider (OAuth 2.1 + OIDC Core, ADR-0052) — point any OIDC library at the issuer URL and it works, no bespoke code:

Discovery: GET https://<your-issuer>/.well-known/openid-configuration
/authorize (authorization code, PKCE S256 required), /token (authorization_code · refresh_token with rotation + reuse detection · client_credentials), /userinfo, and RP-initiated + back-channel logout (end_session_endpoint).
id_token signed RS256, verifiable offline against the same JWKS; the issuer is your own domain on a self-hosted install.
Register apps under Organization → OAuth Clients (confidential or public, show-once secrets, exact-match redirect URIs); users manage grants under Account → Connected apps.

Full walkthrough — register a client, run authorization-code + PKCE, verify the id_token, wire up logout: Log in with Zynth Auth (OIDC).

The SDK does not go away — it stays the value-add layer (embedded rate limiting, sanitization, CSRF, anomaly reporting, agent ergonomics) on top of the standard floor, the same pairing you see from Auth0 and Clerk. Prefer plain REST + JWKS verification? See Verifying tokens; prefer the batteries-included path? See the TypeScript SDK.

Bounded profile (ADR-0052). Implicit and ROPC grants are never implemented; device grant, CIBA, dynamic client registration, PAR, and JAR/JARM are out of scope for this profile. "Supports OIDC," not "certified" — formal OpenID Foundation conformance is a later milestone.

Why self-host is sequenced last

Self-host is the highest-value tier and the one with the most permanent obligation: the day a customer installs a release, we owe supported versions and security backports for that install going forward. So it is deliberately launched after the standards floor (the OpenID Provider) and the release-engineering tooling that make it safe to service exist. The staged order is:

Tenancy hardening (done — the isolation boundaries above)
OpenID Provider (live)
Dogfood a real second tenant over standard OIDC (done)
Control plane + pooled SaaS (live — plans & entitlements)
Public surface + trust centre (live — pricing, trust centre, legal)
Release engineering + distribution (done — Phase 25: signed channel, offline bundle, licence-gated per-customer download, self-service patching connected and air-gapped)
Self-host GA ← the remaining step, a commercial decision

Interested in self-host before GA? The self-hosted page takes licence enquiries now — early enquiries shape what the distribution packages.

What a self-host buyer can count on (when it ships)

Feature parity with SaaS — same codebase, tier as entitlement.
A clear upgrade path — semantic versioning with an enforced meaning: patches carry security/bug fixes only (no schema migrations, no new required config) and are safe to self-apply unattended, with automatic rollback; minor/major upgrades run a gated runbook (ADR-0054).
The same signed supply chain we use — release images are cosign-signed and verified before they run; an offline bundle supports air-gapped installs.
Offline by design — licence verification is fully offline (no phone-home), and an expired or missing licence never blocks authentication — it degrades premium features, never core IAM (ADR-0053). Your identity layer cannot be bricked by a licensing edge case.