What we run today — not a roadmap

Platform Architecture

Managed Keycloak on AWS — Fargate cells, a serverless control plane, an Aurora PostgreSQL source of truth, and availability that scales with your architecture tier.

Read the full docs → Talk to an engineer

The Default Deployment

A stateful data plane on AWS Fargate fronted by CloudFront and an ALB, with everything around Keycloak running serverless in the control plane.

Default Architecture — Single Region, Multi-AZData plane (Fargate)Control plane (Lambda)DatabaseUsers / SPAs / APIsCloudFront (edge)TLS · WAF / Shield · cache /resources/*DATA PLANE — AWS us-east-1 · Fargate (JVM Keycloak / Quarkus, autoscaled on CPU)Regional ALB (L7)Availability Zone 1Availability Zone 2KC task 1KC task 2KC task 3KC task n◄── clustered via JDBC_PING · embedded Infinispan (in-region) ──►Aurora PostgreSQL — Multi-AZprimary + synchronous replica · source of truthCONTROL PLANE — serverless (Lambda)Provisioning APIBilling / metering (Stripe)AI-config serviceAnalytics pipeline → ClickHouseNotifications (SES / SNS)STS token-brokerTenant Registry + Placement EngineAdmin REST APINot Lambda for Keycloak (stateful/clustered) · not GraalVM native (SPIs power analytics, adaptive auth, STS)Scales two ways · Availability by tierMany tenants → add cells(cell = Fargate + DB + cache, N realms)One huge realm → dedicated Fargatesized by login rate (~1 vCPU / 15 logins/s)99.9% single-region · 99.95% multi-region active-passive · 99.99% active-active multi-cloudSLA tiers backed after production maturity

Data plane — Fargate (JVM)

Long-running, clustered Keycloak (Quarkus) across AZs via JDBC_PING, autoscaled on CPU. Not Lambda, not native — both break the SPIs and clustering the product depends on.

Control plane — serverless

Provisioning, billing, AI-config, analytics, notifications, and the STS token-broker run on Lambda and drive Keycloak through its Admin REST API.

Aurora PostgreSQL

Multi-AZ primary + synchronous replica is the source of truth. Sessions persist to the DB (persistent-user-sessions); Infinispan is an in-region near-cache.

Multi-Tenancy That Scales in Cells

A cell is a self-contained Keycloak unit (Fargate + its DB + its cache) bounded to a set number of realms. You scale by adding cells; a placement engine routes each tenant to one.

Cell-Based Multi-TenancyCloudFront + Edge Routerresolve tenant → cell (host / path / custom domain)Tenant Registrytenant → model · cell · realm · regionPlacement Enginecapacity + capability awarePooled Cell A — up to N realmsKeycloak cluster (Fargate, multi-AZ)Aurora (default)cell databaseInfinispanin-region cachePooled Cell B — up to N realmsKeycloak cluster (Fargate, multi-AZ)Aurora (default)cell databaseInfinispanin-region cacheDedicated Silo (Enterprise)Tenant's own Keycloak + own DBstrongest isolation · own keys / upgradesoptional multi-cloud (Yugabyte) cellThree isolation tiers — used together, not either/orOrganizations• Org inside a shared realm• Highest density• Many small B2B tenantsdensity ▲ isolation ▽Realm-per-tenant (pooled)• A realm on a shared cluster• Strong isolation, own keys• The standard tierbalancedInstance-per-tenant (silo)• Dedicated KC + DB• Strongest isolation• Enterprise / regulateddensity ▽ isolation ▲

Multi-Cloud, Done Honestly

Two premium options, depending on whether you need disaster recovery across clouds or true active-active. Standard deployments stay single-cloud, multi-region.

Multi-Cloud — Premium OptionsOption A — Cross-Cloud Warm Standby (active-passive)Route 53 — health-check failoverlatency routing · 60s TTL · promote standby on region lossAWS — us-east-1 (ACTIVE)Keycloak (Fargate) — serving trafficAurora PostgreSQL — PRIMARYlogical-replication PUBLICATIONAzure — East US (WARM STANDBY)Keycloak (standby, promoted on failover)Azure DB for PostgreSQL — SUBSCRIBERwarm standbylogical replicationover VPN / interconnect (or AWS DMS)Native physical log shipping is impossible — Aurora's log-structured storage doesn't expose WAL.Active-passive: RTO = standby promotion + replication catch-up · RPO = replication lagOption B — YugabyteDB geo-distributed (active-active)Keycloak — AWSKeycloak — AzureKeycloak — GCPone YugabyteDB cluster (Raft) spans clouds · no failover gap → the tier that backs 99.99%tradeoffs: gated DB migrations · cross-cloud egress cost · heavier ops · cell tagged capabilities:["multi-cloud"]

Option A — Cross-cloud warm standby

Aurora (AWS) replicates to Azure Database for PostgreSQL via logical replication — physical log shipping isn't possible on Aurora. Active-passive with DNS failover; great for DR and data sovereignty.

Option B — YugabyteDB active-active

One distributed-SQL cluster spans clouds with no failover gap — the tier that credibly backs 99.99%. Trades that for gated DB migrations, cross-cloud egress cost, and heavier ops.

Availability, Tiered by Architecture

Tier Architecture Target SLA
Single region Aurora Multi-AZ 99.9%
Multi-region Aurora Global active-passive + DNS failover 99.95%
Active-active multi-cloud YugabyteDB (no failover gap) 99.99%

SLA tiers are backed after production maturity.

Standard vs. Premium Opt-In

Standard (included) Premium (opt-in)
Single AWS region, Multi-AZMulti-region active-passive DR (Aurora Global)
Pooled cells, realm-per-tenantDedicated silo (own Keycloak + DB)
Aurora PostgreSQLCross-cloud warm standby (AWS→Azure)
99.9% target SLAYugabyteDB active-active (99.99% target)

Want the full detail?

Migration, rolling upgrades & patching, HA & resiliency, realm setup, analytics, and security — all in the documentation.

Browse the docs → Start free trial