Open Source CIAM: When and How to Go Self-Hosted

The Case for Code You Can See

There's a moment in every engineering leader's journey where the monthly invoice from a managed CIAM vendor triggers a serious conversation. Maybe you've hit 500,000 monthly active users and the per-MAU pricing has turned identity into one of your top three infrastructure costs. Maybe your legal team just flagged a data sovereignty issue because your vendor processes user data in a jurisdiction you can't control. Or maybe your security team simply wants to audit the actual authentication code running in production, not just read a SOC 2 report about it.

Whatever the catalyst, you're now considering open source CIAM. And the landscape has matured enough that this is no longer a fringe decision. It's a legitimate architectural choice, made by companies from startups to large enterprises.

I founded LoginRadius in 2013 and scaled its identity infrastructure to serve more than 1 billion users. Over that time, I watched open source identity evolve from rough-edged LDAP wrappers into production-grade platforms that rival commercial offerings in feature depth. The gap has closed significantly, but the tradeoffs haven't disappeared.

Let's walk through what's actually out there, when open source makes sense, and what it really costs to run it.

Why Open Source CIAM Matters Now

Three forces are converging to make open source CIAM more viable than ever.

Code transparency and security auditability. In an era of supply chain attacks and zero-day exploits, being able to read, audit, and patch the authentication code protecting your users isn't a luxury. It's a risk management strategy. Open source doesn't guarantee security, but it does guarantee visibility. When a vulnerability drops, you can assess your exposure immediately rather than waiting for a vendor advisory.

Data sovereignty and regulatory pressure. GDPR, CCPA, LGPD, and sector-specific regulations increasingly demand that organizations demonstrate control over where and how user data is processed. Self-hosting your identity infrastructure gives you physical and logical control over user data residency. For companies in regulated industries (healthcare, financial services, government), this can be a hard requirement, not a preference.

Cost predictability at scale. Published per-MAU rates above free tiers run from under a cent to a few cents per MAU per month. Amazon Cognito Essentials, for example, lists $0.015 per MAU, about $15,000 a month at 1 million MAU. Open source eliminates per-MAU license costs entirely. Your costs become infrastructure (compute, storage, networking) and people (engineering time to operate). For high-MAU applications, the economics often favor self-hosting by a wide margin.

The Top Open Source CIAM Platforms

Five platforms come up most often when teams evaluate self-hosted CIAM. Each has a distinct philosophy, architecture, and sweet spot. Here's what you need to know about each.

Keycloak (CNCF, originally Red Hat)

Keycloak is the most established open source identity platform. Originally developed by Red Hat and now a Cloud Native Computing Foundation (CNCF) incubating project, it's the closest thing to a "default choice" in open source CIAM. Red Hat sells commercial support as the Red Hat build of Keycloak.

What it does well: Keycloak offers enterprise-grade SSO out of the box with support for SAML 2.0, OpenID Connect, and OAuth 2.0. It handles social login, multi-factor authentication, user federation via LDAP and Active Directory, fine-grained authorization, and identity brokering. Its admin console is comprehensive, and its clustering support (via Infinispan) allows horizontal scaling across multiple nodes.

Where it fits: Organizations that need a full-featured identity server with broad protocol support and don't mind a Java-based stack. Keycloak is particularly strong for enterprises migrating from legacy LDAP/AD environments and needing to federate multiple identity sources.

Watch out for: Keycloak's Java heritage means higher memory consumption compared to Go-based alternatives. The default themes require significant customization for consumer-facing UX. And while clustering works, tuning it for very high throughput requires expertise.

Ory (Kratos + Hydra + Keto + Oathkeeper)

Ory takes a fundamentally different approach. Instead of a monolithic identity server, it provides a suite of services, each handling a specific identity concern. Kratos manages identity and self-service flows, Hydra handles OAuth2 and OIDC, Keto provides fine-grained authorization (inspired by Google's Zanzibar), and Oathkeeper serves as an identity-aware reverse proxy.

What it does well: Ory is cloud-native to its core. Every component is designed for Kubernetes deployment, communicates via APIs, and stores state in standard databases (PostgreSQL, MySQL, CockroachDB). The "bring your own UI" philosophy means you have complete control over every user-facing screen. There's no theme to fight with.

Where it fits: Engineering teams building modern, API-first applications that want to compose their identity stack from modular components. Ory is ideal for organizations already running Kubernetes and comfortable with microservices architecture.

Watch out for: The modular architecture means you're operating multiple services, not one. The learning curve is steeper than monolithic alternatives. And the "bring your own UI" approach means you're building every login, registration, and account management screen yourself.

Authentik

Authentik has carved out a niche as the most user-friendly open source identity platform. Written in Python (Django) with a modern web UI, it balances feature depth with operational simplicity.

What it does well: Authentik supports a broad set of protocols (SAML, OAuth2/OIDC, LDAP, SCIM, and RADIUS), making it versatile for environments with mixed protocol requirements. Its standout feature is the proxy provider, which can add SSO to legacy applications that don't natively support modern authentication protocols. The flow-based authentication engine lets you build custom login workflows visually.

Where it fits: Teams that need to add SSO across a mix of modern and legacy applications without deep protocol expertise. Authentik is popular in homelab and SMB environments and increasingly used by mid-market companies.

Watch out for: Python-based architecture may present scaling challenges at very high user volumes compared to Go or Java alternatives. The project is newer than Keycloak and has a smaller enterprise deployment footprint.

FusionAuth Community Edition

FusionAuth deserves mention with a caveat: it's free, but not open source in the OSI-approved sense. Community is free to download and run, including commercially, under FusionAuth's own license, which is not an open source license. For practical purposes, it delivers the self-hosted, no-per-MAU benefits that drive most open source evaluations.

What it does well: FusionAuth is built for developers. It offers advanced registration forms, tenant-based multi-tenancy, breached password detection, and comprehensive webhook support out of the box. Its single-application deployment (Java-based) is simpler to operate than multi-component systems.

Where it fits: Developer-focused organizations that want a polished, well-documented identity server with commercial-grade features at zero cost. FusionAuth is strong for B2C applications where registration flow customization matters.

Watch out for: The license means you can't fork and modify the platform the way you can with Keycloak or Ory. Some advanced features (advanced threat detection, some MFA options, enterprise connectors) are only in paid editions.

ZITADEL

ZITADEL is the newest serious contender. It raised a $9 million Series A in November 2024. Written in Go, it was designed from the ground up for multi-tenancy and cloud deployment. With version 3 in 2025, its core moved from Apache 2.0 to AGPL-3.0; APIs and SDKs stay Apache 2.0.

What it does well: ZITADEL's Go-based architecture delivers low memory footprint and fast startup times. Multi-tenancy is built into the core data model, not bolted on, which makes it natural for SaaS platforms that isolate identity per customer. It supports OIDC, SAML, JWT, and offers built-in action scripting for custom logic during authentication flows.

Where it fits: SaaS companies building multi-tenant platforms that need per-tenant identity isolation without running separate infrastructure per tenant. Also strong for organizations that want a modern, resource-efficient alternative to Keycloak.

Watch out for: Smaller community and ecosystem than Keycloak. As a newer project, long-term sustainability depends on the company's commercial success. If you modify ZITADEL and offer it as a service to others, AGPL obligations apply; a commercial license is available.

Feature Comparison

Capability	Keycloak	Ory Stack	Authentik	FusionAuth CE	ZITADEL
License	Apache 2.0	Apache 2.0	MIT (core)	Proprietary, free to use	AGPL-3.0 (core, since v3)
Language	Java	Go	Python	Java	Go
OIDC / OAuth2	Yes	Yes (Hydra)	Yes	Yes	Yes
SAML 2.0	Yes	Via Ory Polis	Yes	Yes	Yes
Social login	20+ providers	Configurable	20+ providers	30+ providers	15+ providers
MFA/Passkeys	TOTP, WebAuthn	TOTP, WebAuthn	TOTP, WebAuthn, Duo	TOTP, plus WebAuthn/passkeys with a free license key (SMS and email MFA need a paid plan)	TOTP, WebAuthn
LDAP/AD integration	Native	Via Kratos	Native + provider	Yes	LDAP provider
User self-service	Full	Full (BYO UI)	Full	Full	Full
Fine-grained authz	Yes	Yes (Keto)	Policy engine	RBAC; fine-grained via FusionAuth FGA by Permify (acquired November 2025)	RBAC + projects
Multi-tenancy	Realms	Per-deployment	Tenants	Native tenants	Native, deep
Horizontal scaling	Infinispan cluster	Kubernetes-native	Limited	Clustered	Kubernetes-native
Admin UI	Comprehensive	Minimal	Excellent	Comprehensive	Good
Community size	Very large	Large	Growing	Medium	Growing
Deployment model	Docker, K8s, bare metal	Docker, K8s	Docker, K8s	Docker, bare metal	Docker, K8s

When to Choose Open Source vs. Commercial

The decision isn't purely technical. It's a resource allocation question. Here's my framework for thinking it through; the MAU thresholds are my rules of thumb.

Choose open source when:

• Your MAU count exceeds 500K and per-MAU costs are becoming a significant line item
• Data sovereignty requirements mandate that user data stays in specific jurisdictions or on your own infrastructure
• Your security posture requires source-code-level auditability of authentication logic
• You have engineering capacity to operate identity infrastructure (more on the real cost below)
• Your authentication flows require deep customization that vendor platforms constrain

Choose commercial CIAM when:

• Time-to-market is your top priority and you need to ship auth in days, not weeks
• Your team lacks Kubernetes or infrastructure operations expertise
• You need a contractual SLA with defined uptime guarantees and incident response
• Compliance certifications (SOC 2, ISO 27001, HIPAA BAA) from the vendor reduce your audit burden
• Your MAU count is under 100K, where per-MAU costs are often cheaper than the engineering time to self-host

The gray zone (100K-500K MAUs): At this scale, the math is ambiguous. You'll want to do a total cost of ownership analysis that includes infrastructure costs, engineering time, and the opportunity cost of diverting engineers from product development to identity operations.

The Real Cost of Self-Hosting

Let's be honest about what self-hosting identity infrastructure actually requires. The ranges below are my planning estimates. The software cost is zero, but the operational cost is real and ongoing.

Infrastructure costs: Expect to run at minimum a 3-node cluster for high availability (identity is a Tier 0 service: if auth goes down, your entire application is down). With database replication, monitoring, and backup infrastructure, budget $2,000-8,000 per month in cloud compute depending on scale and redundancy requirements.

Engineering time: Plan for 0.5-1 FTE dedicated to identity operations. This includes:

• Monitoring authentication flows and investigating anomalies
• Applying security patches (identity systems are high-value targets, so patch urgency is high)
• Managing version upgrades (major version upgrades often require migration scripts and testing)
• Scaling infrastructure during traffic spikes
• On-call rotation for identity-related incidents
• Maintaining custom integrations and authentication flows

Security responsibility: When you self-host, you own the full security stack. That means penetration testing, vulnerability scanning, key rotation, certificate management, and incident response are all on your team. Commercial vendors absorb this responsibility and spread the cost across their customer base.

Compliance overhead: If you need SOC 2 or ISO 27001, you'll need to include your self-hosted identity infrastructure in your audit scope. With a commercial vendor, their certification partially offsets your audit requirements.

The Hybrid Model: Best of Both Worlds

For many organizations, the best approach isn't purely self-hosted or purely managed. It's a hybrid model.

Self-host for development and testing. Run Keycloak, Ory, or ZITADEL in your CI/CD pipeline and development environments. This gives your engineering team full control over identity configuration during development, eliminates sandbox cost from your vendor bill, and lets you test authentication flows without network dependencies.

Use managed services for production. For your production environment, use the managed offering for your chosen platform (Ory Network, ZITADEL Cloud, FusionAuth Cloud) or a commercial CIAM vendor. This gives you SLA-backed uptime, managed security patching, and reduced operational burden for your most critical environment.

Why this works: Development and testing environments don't need 99.99% uptime SLAs or 24/7 security monitoring. They do need fast iteration and configuration flexibility. Production needs the opposite: reliability and security above everything. The hybrid model allocates resources where they matter most.

Some organizations also use a geographic split: self-hosted in regions with strict data sovereignty requirements (EU, China, India) and managed services in less regulated markets. This reduces operational scope while meeting compliance mandates where they're strictest.

What's Coming Next

The open source CIAM space is evolving fast. Several trends will reshape the landscape over the next 2-3 years.

Passwordless as the default. Passkeys (FIDO2/WebAuthn) are moving from "supported" to "default" across major platforms. In the FIDO Alliance's October 2026 Passkey Index, 36% of successful sign-ins at participating services used a passkey. I expect open source CIAM projects to make passwordless the primary flow, with passwords as a fallback.

Decentralized identity integration. As verifiable credentials and digital identity wallets mature (driven by eIDAS 2.0 in the EU), open source CIAM platforms will need to support credential verification alongside traditional authentication. Keycloak's OpenID for Verifiable Credential Issuance support moved from experimental to preview in Keycloak 26.8. I expect credential verification to become a standard feature.

AI-enhanced security. Machine learning models for anomaly detection, risk-based authentication, and bot mitigation are moving from commercial-only features to open source implementations. Expect to see community-driven ML models for detecting credential stuffing, account takeover attempts, and suspicious registration patterns integrated directly into open source CIAM platforms.

Consolidation and sustainability. Not all five platforms will thrive equally. Projects backed by sustainable funding (commercial cloud offerings like Ory and ZITADEL, foundation support like Keycloak's CNCF home, or venture capital) will keep investing in features and security. Evaluate long-term project health, not just current feature sets.

Making Your Decision

Open source CIAM is no longer a compromise. The top platforms offer feature parity with commercial alternatives for core authentication and authorization use cases. The decision comes down to operational readiness and total cost of ownership, not feature gaps.

Before committing, run a 30-day proof of concept with your top two choices. Deploy them in a staging environment that mirrors your production topology. Test your critical authentication flows (social login, MFA enrollment, password reset, session management) under realistic load. Measure not just whether it works, but how much engineering time it takes to get there and keep it running.

The identity layer you choose will serve your product for years. Whether you go open source, commercial, or hybrid, make sure data drives the decision. Not sticker shock from a vendor invoice, and not the allure of "free" software that quietly costs more than the alternative.

For more technical comparison and implementation guidance, see my analysis of open source CIAM for the modern enterprise. For head-to-heads, see Keycloak vs ZITADEL, Keycloak vs Ory, and Keycloak vs FusionAuth on CIAM Compass.