Architecture: single Zitadel instance vs multiple virtual instances for the Catholic OS umbrella

[JohnRDOrazio]

As we prepare to deploy production Zitadel (and OpenFGA) at auth.catholicdigitalcommons.org / authz.catholicdigitalcommons.org serving cdcf-website, LiturgicalCalendarAPI, BibleGet API, and OntoKit, there are two reasonable architectures. Posting the tradeoffs here for input before we commit.

Option A — Single Zitadel instance, one Project (or Org) per property

One Zitadel runtime at auth.catholicdigitalcommons.org. Each property is either a separate Zitadel Project under one shared CatholicOS Org, or a separate Zitadel Org with its own Project(s).

Pros

• Lower ops burden: one runtime to upgrade, one database to back up, one TLS cert, one set of monitors, one admin console.
• Per-property branding still supported via Zitadel's private-labeling (each Project/Org can have its own logo, colors, login background) — and since each property implements its own login UI anyway, branding is effectively unlimited.
• Cross-property SSO is optional, not mandatory: if everything lives under one shared Org, signing in to CDCF gives the user a Zitadel session other properties can reuse silently — automatic SSO. If properties are in separate Orgs, users are isolated and there is no automatic cross-property session. We choose.
• Cheaper to run: one Postgres database, one Go process (~200–300 MB RAM idle).
• Project-level authorization is still independent: each Project has its own roles, audience, and projectRoleCheck toggle. A user with no grant for Project B doesn't gain access just by holding a session.

Cons

• Shared fate: a Zitadel outage takes auth down for all four properties at once. Mitigated by Zitadel being a small stable service and by daily backups, but it's real coupling.
• One masterkey protects everything. If compromised, all four properties' auth tenants are at risk. (Realistically the masterkey lives in VPS env and is no more exposed than any other shared secret.)
• Org-level admin scope: in the shared-Org variant, admins of CDCF can in principle see/manage users of LitCal. Mitigated by the per-Org variant (one Org per property), but that means per-Org admin chains have to be set up.

Option B — Multiple virtual instances (one per property)

Each property runs as its own Zitadel virtual instance, accessed via its own hostname (e.g. auth.cdcf.org, auth.liturgicalcalendar.org, auth.bibleget.io, auth.ontokit.org). All instances live inside one Zitadel deployment but are fully isolated tenants — separate users, orgs, masterkeys, branding, settings. Managed through Zitadel's System API.

Pros

• Hard isolation: a misconfiguration or compromise in one property's tenant doesn't touch the others. Each instance can have its own admin chain, password policy, IdP federation, branding — no shared state.
• Independent lifecycle: properties can be sunset, transferred, or spun off into their own legal entity without unwinding a shared user pool.
• Closer to how Zitadel positions multi-tenancy: their own docs frame it as the right shape "for business customers who require self-service options and custom domain demands."

Cons

• No cross-property SSO — a user who signed up at CDCF is unknown to BibleGet, period. We'd have to either accept double signups or wire upstream IdP federation.
• More moving parts: separate instance bootstrap per property, separate org-admin chain, separate System API operations, separate masterkey to back up, separate setup script invocations per property.
• No per-property SSO win: most of Zitadel's appeal is one-sign-on-many-apps. We'd be giving that up at the umbrella level by design.
• Operationally closer to "four small Zitadels" than one shared identity layer.

Where we're leaning

Single instance with one Zitadel Org per property (Option A's per-Org variant). Per-property admin isolation without the operational cost of separate runtimes. But genuinely open to input — particularly from anyone who's run multi-instance Zitadel in anger, or who has a use case that benefits from hard tenant isolation.

Comments welcome on

• Anything we're underestimating about multi-instance operational cost (positive or negative)
• Whether per-Org isolation inside a single instance is sufficient for our admin-separation goals
• Whether anyone wants cross-property SSO and would be unhappy with the per-Org choice
• Backup/DR considerations specific to either model

---

Implementation plan (working draft) lives in cdcf-infra — once that repo is created, look there for the actual compose file, secrets handling, and Phase 1 wiring details (LitCal first).