0001, Dual-domain architecture

Status: Accepted Date: 2026-02 Stakeholders: Bobby Nannier

Context

Olympus serves two distinct audiences:

Customers of the products Olympus is used to power. They register, log in, recover passwords, manage their own accounts.
Employees of the organization running Olympus. They operate the platform, administer customers, access internal tools.

Industry-standard guidance is to keep these two audiences on separate identity surfaces, Auth0 calls this "CIAM vs IAM," Okta calls it "Customer Identity vs Workforce Identity." The reasons relate to isolation, policy independence, and data residency.

The question is how to realize that separation in Olympus's implementation.

Considered alternatives

Option A, Single Kratos + single Hydra, "domain" as a trait

Run one identity stack. Each identity has a domain: customer | employee trait. Authorization policy gates access based on this trait.

Pros: simpler operational footprint; one upgrade path; one Postgres database.
Cons: A compromise on the customer-facing surface is a compromise of internal employees too. A schema change for customers affects employees. Independent rate-limit and lockout policies require complex per-trait logic. Independent scaling is impossible, both customers and employees share resources.

Option B, Single Kratos + single Hydra, separate OAuth2 clients per audience

One identity stack but different OAuth2 client IDs for customer-facing apps vs employee-facing apps. Hydra's scope model encodes the boundary.

Pros: simple; one upgrade.
Cons: Same fundamental problem as Option A. The OAuth2 client boundary doesn't protect the identity database.

Option C, Two complete Kratos + Hydra stacks (CIAM and IAM), separate databases ✓

Run two completely independent identity stacks. Different Kratos containers, different Hydra containers, different Postgres databases. Sharing only the host VPS and the Caddy reverse proxy.

Pros: Clean isolation. A breach of CIAM does not touch IAM. Different policies (password rules, MFA, session lifetimes) configured naturally. Independent scaling. Independent upgrades. Clean GDPR data boundaries.
Cons: ~2× operational footprint. Two Postgres databases (well, four, CIAM/IAM Kratos and CIAM/IAM Hydra). Two of every container. More to monitor.

Eight identity-related containers in prod (CIAM and IAM × Kratos public + Kratos admin + Hydra public + Hydra admin … actually four Ory services × two domains = 8). Plus 2 Heras, 2 Athenas. The total Compose service count is high, see Reference, Compose Services for the inventory.
Every runbook applies twice. Cert rotation rotates four DB certs. Secrets audit covers two sets of secrets.

Performance

Slightly higher memory baseline (each Ory binary uses ~50MB resident).
No cross-contention between customer and employee traffic.

Security

The dual-domain isolation is the single biggest security feature of Olympus. Most identity products require careful policy engineering to achieve it; Olympus achieves it by construction.

Developer ergonomics

Initial confusion about "Athena CIAM" vs "Athena IAM" is common. We document this prominently in CIAM vs IAM.
The "CIAM" in "Athena CIAM" describes the data the dashboard manages, not the audience using the dashboard. Athena CIAM is operated by employees, but it manages the CIAM Kratos and Hydra.

Cost

~$10-20/month additional cloud cost on a single-VPS deployment (mostly Postgres storage).
Negligible on a managed Postgres (Neon), they price per database storage, not per database instance.

Security, CIAM/IAM Isolation, the enforcement details.
Operate, Network Topology, which ports each domain occupies.
Architecture, visual top-level layout.

Revisit triggers

We would revisit this decision if:

The operational footprint becomes a serious cost issue (unlikely below ~10k MAU).
Ory ships a first-class multi-tenant feature that gives equivalent isolation with shared infrastructure.
We discover a substantial customer/employee identity-sharing requirement (unlikely).