Every application you build eventually needs the same thing: a way to log users in, prove who they are, and decide what they can touch. Rolling that yourself — password hashing, MFA, session management, SSO across services — is how small teams accidentally ship a breach. Keycloak exists so you never have to. It is an open-source identity and access management (IAM) platform that puts a standards-compliant login, single sign-on, and authorization layer in front of your apps, and you run it on your own metal.
The headline is almost too good to be a caveat: Keycloak is Apache-2.0, with no per-user or per-seat licensing. Your identity bill does not climb as your user base grows. That is the rare open-source story where the licence is genuinely permissive and the free tier is the whole product, not a loss-leader. The catch is not in the licence; it is in the verb. You
operate an identity provider. That means a database, certificates, a reverse proxy, backups, patching, and — if you want resilience — a clustered deployment you understand. Free software is not free to run, and identity is the one layer you cannot afford to have an outage in.
This is a long, honest teardown. We cover what Keycloak delivers out of the box, the realm/client mental model that trips up newcomers, how SSO and federation actually work, the real cost of running it, the high-availability story (and its Infinispan dependency), and precisely where your users' credentials and sessions live. If you are evaluating Auth0, Clerk, or WorkOS and choking on per-monthly-active-user pricing, this is the article that tells you what "just self-host Keycloak" really costs.
1. What Keycloak Is
Keycloak is an open-source IAM server. It handles authentication (proving who a user is) and authorization (deciding what they can do) for the applications and services behind it. Instead of each app implementing its own login form, password storage, and session logic, your apps delegate to Keycloak. A user logs in once to Keycloak and is then authenticated to every application that trusts it — single sign-on. Log out once, logged out everywhere — single sign-out.
It is maintained by Red Hat and distributed under the Apache License 2.0. The 26.x series is current as of 2026, with releases shipping regularly; the project carries OpenSSF best-practice and scorecard badges and is positioned as a CNCF-aligned project. GitHub reports in the high-30-thousands of stars. This is not a hobbyist project — it is the default open-source answer to "we need Auth0 but we do not want the bill or the data residency."
2. The Licence: Apache-2.0, and Why That Matters
Apache-2.0 is the licence story you want for infrastructure. It is permissive: you can use Keycloak commercially, modify it, and embed it without an obligation to open your own code. There is no AGPL network-copyleft trap (unlike MinIO, covered in our
2026-09-13-github-minio piece) and no open-core gating of core features. SSO, social login, LDAP/Active Directory federation, OIDC, OAuth 2.0, SAML 2.0, fine-grained authorization, multi-tenancy via realms — all of it is in the free distribution.
The commercial angle is support, not features. Red Hat sells the "Red Hat build of Keycloak" (RHBK) with subscriptions and SLAs; third parties (Phase Two, Cloud-IAM) sell managed Keycloak. But you are never forced into those to use the software. Your growth in users translates into zero additional licence cost — only into more infrastructure and operational work, which you control. For a SaaS whose identity bill would be thousands per month at scale, that decoupling of cost from headcount is the entire business case.
3. The Mental Model: Realms, Clients, Users
Keycloak's vocabulary is the thing to learn first, because it is where newcomers stall.
- Realm: a fully isolated tenant. Users, clients, roles, and identity providers in one realm cannot see another. Create one realm per environment (dev, staging, prod) or per customer if you are multi-tenant. The
master realm is for Keycloak's own admin users — do not put your app users there.
- Client: an application that uses Keycloak for auth. A web app, a mobile app, a backend service — each is a client. A client has a protocol (OpenID Connect or SAML), redirect URIs, and a secret.
- User: a person who can log in. Can be stored in Keycloak's own database or federated from LDAP/AD.
- Role: a permission assigned to users or groups; maps to what they can do in your app.
- Identity Provider: an external login source — Google, GitHub, another OIDC/SAML IdP — that Keycloak can broker.
Once that model clicks, Keycloak stops feeling like a maze. The most common beginner mistake is dumping everything into the
master realm or misconfiguring redirect URIs, which is also the most common cause of "login redirects to a blank page."
4. Single Sign-On in Practice
SSO is the headline feature and it works the way the brochure says. A user authenticates to Keycloak; Keycloak issues tokens (an OIDC ID token and access token, plus a session cookie). When that user hits a second application that also trusts the realm, Keycloak recognizes the existing session and issues tokens without a second login. Logout in one app triggers single sign-out across the realm.
The mechanism is standard OIDC authorization-code flow with PKCE for public clients (SPAs and mobile), which is the current security best practice. Keycloak handles the token signing, rotation, and introspection. Your app validates tokens — typically by checking the signature against Keycloak's published JWKS endpoint — and trusts the claims. You write almost no crypto; Keycloak does. That is the value: you delegate the dangerous parts to software whose job is exactly those dangerous parts.
5. Protocols: OIDC, OAuth 2.0, SAML
Keycloak speaks the three protocols that matter.
- OpenID Connect (built on OAuth 2.0) is the default for modern web, SPA, and mobile apps. It is what you use 90% of the time.
- OAuth 2.0 covers delegated authorization — letting an app act on a user's behalf with a token.
- SAML 2.0 remains mandatory in enterprise and government contexts; Keycloak brokers and terminates SAML so your modern app can speak OIDC while Keycloak talks SAML to a legacy IdP.
This protocol breadth is why Keycloak slots into existing enterprise stacks instead of fighting them. If a customer demands SAML, Keycloak terminates it and your app never learns SAML existed. That translation layer is worth real money in integration effort.
6. Identity Brokering and Social Login
Enabling "log in with Google/GitHub/Microsoft" is a few clicks in the admin console — select the provider, paste client ID and secret, done. No code changes in your app; it just receives a federated identity. The same brokering works for external OIDC or SAML identity providers: you can let users from a partner's IdP log into your app via Keycloak without sharing a user directory.
A subtlety worth knowing: when you broker an external IdP, you decide whether to import the external user into your realm or treat them as linked. Imported users let you assign your own roles; linked users stay sourced externally. Get this wrong and you either duplicate accounts or fail to authorize federated users for anything. The console makes both paths possible; the design decision is yours.
7. User Federation: LDAP and Active Directory
For organizations with an existing directory, Keycloak's user federation is the feature that justifies the project. You point Keycloak at your LDAP or Active Directory, and it authenticates users against the directory without importing them. Passwords stay in AD; Keycloak validates against it. You can map directory groups to Keycloak roles, so "member of Domain Admins" becomes "realm role admin" automatically.
The caveat is sync direction and latency. Federation authenticates against the source of truth, but profile attributes you want in tokens (email, department) must be mapped and cached. A misconfigured mapper means tokens arrive missing the claim your app checks. Test the attribute mapping against a real directory account before you trust it in production — the "it logs in" demo and the "it logs in with the right claims" production state are different milestones.
8. Authorization Services: Beyond Roles
Role-based access control (RBAC) covers most needs: assign roles, check roles. Keycloak goes further with fine-grained authorization — attribute-based, policy-based, and UMA 2.0 (user-managed access). You can define policies in the admin console — JavaScript rules, time-based rules, aggregated logic — and have Keycloak evaluate them, returning permission grants inside a requesting-party token. This lets you centralize authorization logic that would otherwise be scattered across microservices.
Be realistic: most teams use RBAC and stop. The authorization-services layer is powerful but adds a learning curve and couples your authz logic to Keycloak. Use it when you genuinely have cross-service fine-grained policies; skip it when simple roles suffice. Over-engineering authorization in Keycloak is a common way to make the identity layer the bottleneck for every feature team.
9. MFA and Passkeys
Keycloak supports TOTP (authenticator apps) and WebAuthn/passkeys out of the box. You can require MFA per realm, per client, or per user via authentication flow bindings. Passkeys — phishing-resistant, passwordless — are supported and are the modern default you should aim for. Conditional MFA (require a second factor only for sensitive clients) is configurable through flow scripting.
The operational note: MFA increases support load. Users lose devices, get locked out, and need recovery codes. Have a recovery story (backup codes, admin reset) and document it, or your help desk becomes the MFA bottleneck. Identity is where "secure but unusable" quietly becomes "users bypass security."
10. Themes and White-Labeling
Keycloak login, account, and admin pages are FreeMarker-based themes. You can rebrand the login screen to match your product so users never see a "Powered by Keycloak" interstitial that breaks your brand promise. For a SaaS embedding auth in front of customers, this theming is not cosmetic — it is the difference between "our product" and "our product plus someone else's login page." The theming is free and well-supported; budget design and QA time for it, not licence cost.
11. Deployment: Quarkus, Containers, Operator
Keycloak runs as a Quarkus-based server — you start it from the packaged build, the official container image (
quay.io/keycloak/keycloak), or the Keycloak Operator on Kubernetes. The Operator automates common cluster tasks: basic deployments, realm import, rolling updates, custom images. For Kubernetes-native shops, the Operator is the smooth path.
It requires an external relational database — PostgreSQL or MySQL — to persist users, clients, and realm data. There is no embedded database for production; do not reach for one. The documentation walks through TLS, hostname configuration, and running behind a reverse proxy. Treat a production Keycloak install as an infrastructure project: database, network path, certificates, container platform, all stood up and kept healthy. That is the recurring theme of this article — the software is free, the assembly is not.
12. The Database Requirement
Keycloak persists everything to PostgreSQL/MySQL. That database is a single point of failure unless you make it one. For a small deployment, a managed Postgres instance (or a replicated self-hosted one) is the pragmatic choice. Back it up. Practice restoring. Because every login depends on this database, a lost realm database is a total identity outage — worse than a chat outage, because every app that trusts Keycloak stops authenticating.
Sizing is modest: idle RAM lands around 512 MB–1 GB for the server, plus whatever the database needs. A 2 vCPU / 2 GB host runs a small instance comfortably; larger user bases scale the database, not dramatically the app. The cost is in the database's HA and backups, not in Keycloak's own footprint.
13. Running Behind a Reverse Proxy
In production Keycloak sits behind a reverse proxy (Traefik, Nginx) that terminates TLS. You must set
KC_HOSTNAME and
KC_PROXY=edge (or
reencrypt) correctly or Keycloak will misconstruct redirect URLs and tokens will fail validation. This is the second-most-common misconfiguration after realm/redirect-URI mistakes. Our
2026-08-25-github-traefik guide covers the proxy layer these apps assume; wire Keycloak into it with a valid certificate and the correct forwarded-headers settings.
14. High Availability: The Infinispan Question
Here is where "free" meets "you operate it." Keycloak's session and cache layer uses Infinispan, an in-memory data grid. For a single node, Infinispan runs embedded and you do not think about it. For true multi-site high availability, the documented approaches include a single cluster with optional multi-zone distribution, a multi-cluster model backed by external Infinispan, and a newer multi-cluster approach that removes that external dependency. The point:
multi-site resilience is documented but demands real expertise to run.
If you only need intra-datacenter HA, run multiple Keycloak nodes sharing a replicated Infinispan cache and a replicated database; that is achievable. If you need cross-region active-active identity with no split-brain, you are operating a distributed systems problem and should staff it accordingly. Keycloak gives you the knobs; it does not give you the distributed-systems degree. Be honest about which resilience level you need before you design the topology.
15. Upgrades and Release Cadence
Keycloak ships frequently; the 26.x line moves with regular point releases. Upgrades can include database migration steps and config changes (the transition to Quarkus from the old WildFly base is long done, but profile and build changes still appear). Snapshot the database before upgrading. Read the migration notes. Stage on a copy.
The fast cadence is good for security — CVEs get fixed quickly — and bad for "set and forget." Identity is security-critical, so staying current matters more here than for, say, a wiki. Budget a recurring upgrade task; an unpatched identity provider is among the worst things to leave aging on the internet.
16. Observability
Keycloak exposes OpenTelemetry metrics, health-check endpoints, tracing, and sample Grafana dashboards. Wire it into your monitoring stack (our
2026-08-27-github-grafana piece covers the dashboard side) and alert on login failure spikes, token-issuance rates, and database latency. Because identity underpins everything, a Keycloak degradation shows up as "every app is slow or failing to log in" — you want to see it in Grafana before users tell you. Health endpoints let your orchestrator restart a bad pod automatically; metrics let you explain
why it was bad.
17. What It Costs: The Real TCO
Numbers:
- Software: $0. Apache-2.0, no per-user fee, ever.
- Infrastructure: a small instance runs on a $5–20/month VPS plus a managed or self-hosted Postgres; production HA is a multi-node app plus a replicated database, easily $50–200/month.
- Your time: the dominant cost — deploy, secure, federate, back up, upgrade, monitor. Identity is not a "deploy once" service.
- Managed alternative: Auth0 runs ~$23/month at 1,000 monthly active users and scales steeply ($240 at 7K MAU, $800+ at 50K). Clerk and WorkOS are similar per-MAU models. Keycloak's cost stays flat as users grow; theirs climbs.
The business case writes itself at scale: if you have 50,000 monthly active users, a hosted IdP is hundreds of dollars a month and Keycloak is the price of a database and your ops time. At 200 users, the hosted IdP might be cheaper than staffing a Keycloak admin. The crossover depends on your headcount and your existing platform team.
18. Where Your Data Goes
Data sovereignty is a primary reason to self-host identity, so be exact:
- User accounts, credentials (hashed), roles, clients, realm config: stored in your PostgreSQL/MySQL. Self-hosted, this is your infrastructure. Passwords are hashed (bcrypt/argon2-class) — Keycloak never stores plaintext.
- Sessions and tokens: live in Infinispan (in-memory) and are short-lived; refresh tokens persist per your config. A session does not leave your network unless you broker an external IdP, in which case that IdP sees the login.
- Federated directories (LDAP/AD): passwords stay in the directory; Keycloak validates against it and never stores the password locally.
- Telemetry: review and disable what you do not want.
- Managed tiers (RHBK, third parties): data lives with that vendor; self-hosting avoids that.
The honest summary: a self-hosted Keycloak keeps credential material on your database, hashed, and sessions in your cache. The only external party that sees a login is one you explicitly broker. That is about as sovereign as identity gets.
19. Honest Limitations
Direct about where Keycloak disappoints:
- It is an infrastructure project, not an appliance. Database, certs, proxy, backups, HA — all yours.
- The admin UI is powerful but complex. Realms, clients, flows, mappers — the learning curve is real. Newcomers misconfigure and stall.
- HA is expertise, not a checkbox. Multi-site resilience needs distributed-systems competence.
- Authorization services are easy to over-engineer, becoming a bottleneck for feature teams.
- You own uptime and incident response. No vendor SLA by default; RHBK or a managed provider adds one at a price.
- Federation mapping bugs are silent. "Logs in" ≠ "logs in with correct claims." Test both.
None are flaws in the software. They are the scope of operating identity yourself, which is the trade you accept to avoid the per-MAU bill and the data residency question.
20. Keycloak vs the Field
Against
Authentik (covered in our
2026-08-27-github-authentik deep dive): Authentik is also open-source and arguably friendlier for self-hosted-homepage use cases, with a slicker out-of-box UX for exposing apps. Keycloak is the heavier enterprise standard — broader protocol and federation depth, Red Hat backing, and a larger installed base in banks and governments. Choose Authentik for app-exposure and SSO at home/small business; Keycloak for standards-deep enterprise IAM.
Against
Zitadel (Apache-2.0, Go, ~8k stars): Zitadel is modern, cloud-native, multi-tenant by design, lower RAM (~100 MB). Keycloak is more feature-rich and battle-tested but heavier. For a greenfield Go shop wanting great DX, Zitadel is compelling; for maximum protocol breadth and enterprise credibility, Keycloak.
Against
Auth0/Clerk/WorkOS (proprietary SaaS): Keycloak wins on cost-at-scale and data residency; loses on "someone else runs it" and on onboarding speed for a tiny team.
21. When to Choose It — and When Not To
Choose Keycloak if: per-MAU SaaS pricing would be expensive at your scale; data residency or self-hosting is required; you need deep protocol/federation support (SAML termination, LDAP/AD); you have or can build a platform team to operate it.
Do not choose it if: you are a tiny team with no platform/security staff and need login working today; you want a managed SLA and someone else patching; your authz needs are simple enough that a hosted IdP's convenience is the feature you are buying. In those cases, pay the SaaS and treat the convenience as the product.
22. A Pragmatic Deployment Checklist
For a production self-hosted Keycloak:
1. Provision PostgreSQL/MySQL — replicated if you care about uptime. Back it up; test restore.
2. Deploy via container or Operator; set
KC_HOSTNAME,
KC_PROXY,
KC_DB correctly.
3. Terminate TLS at your reverse proxy; enforce HTTPS.
4. Create a realm per environment; never put app users in
master.
5. Register each app as a client with correct redirect URIs and PKCE for public clients.
6. Enable MFA (TOTP + WebAuthn); issue and document recovery codes.
7. Federate LDAP/AD if needed; test attribute mapping against a real account.
8. Theme the login page to your brand if customer-facing.
9. Wire OpenTelemetry metrics into Grafana; alert on failure spikes.
10. Disable unwanted telemetry; document the config for audits.
11. Schedule recurring upgrades; snapshot DB before each.
12. Plan HA topology honestly — embedded Infinispan single-node vs replicated vs multi-cluster — against your resilience requirement.
23. The Verdict
Keycloak is the leading open-source, self-hostable identity platform, and it earns that reputation with genuinely enterprise-grade capability under a permissive Apache-2.0 licence. SSO, federation, fine-grained authorization, and multi-tenancy all ship in the free distribution, with no licensing meter as your users grow. For teams that have evaluated hosted competitors and found the pricing, data-handling, or customization limits unacceptable, Keycloak answers nearly every functional requirement.
The counterweight is operational ownership, and it should not be underestimated. Deployment, database management, scaling, HA, monitoring, and a steady upgrade stream are yours. The learning curve around realms, clients, mappers, and authorization is real. For organizations with the platform capability to absorb that work — and with privacy, cost, or control high on the priority list — Keycloak is an excellent and durable choice. Teams that would rather offload identity entirely should weigh a managed alternative and treat that convenience as the feature they pay for.
24. Migrating From Auth0 (or Any Hosted IdP)
Teams move to Keycloak for cost or residency, so migration is a common project. The broad strokes: export your users from the hosted IdP (Auth0 gives a user-export job; you get password hashes only if you used a compatible scheme, otherwise you force a reset), model your applications as Keycloak clients, replicate your rules as authentication flows or authorization policies, and cut over per-application behind your reverse proxy.
The honest friction: social connections and enterprise SAML you had configured in the SaaS must be re-established as Keycloak identity providers and brokers — not hard, but per-app work. Token claim shapes differ, so every app that reads a custom claim must be checked against Keycloak's mapper output. Plan migration as a per-client project with a test realm, not a big-bang switch. The licence saves you money; the migration still costs engineering.
25. Security Hardening, Specifically
Because Keycloak is your trust root, hardening is not optional:
- Enforce HTTPS everywhere; reject plaintext. Set secure cookie flags (Keycloak does by default behind a correct proxy config).
- Require MFA for admin and for sensitive clients; prefer WebAuthn/passkeys.
- Use strong password policies in the realm; consider breach-detection if available.
- Restrict the admin console by network or bastion; do not expose it publicly.
- Rotate client secrets; treat them like API keys.
- Keep the database access locked to the internal network; encrypt at rest.
- Patch on the fast cadence; identity CVEs are high-value targets.
- Review broker trust: a loosely configured social IdP is a login bypass waiting to happen.
The pattern: Keycloak is secure by configuration, and an unhardened instance is a critical risk exactly because everything trusts it. The blast radius of a compromised IdP is your entire app estate.
26. Multi-Tenancy Patterns
If you are a SaaS, you have two multi-tenancy models in Keycloak:
- One realm per tenant: full isolation — each customer's users, clients, and IdPs are separate. Cleanest security boundary; more realms to manage as you scale.
- One realm, groups/roles per tenant: simpler to operate, but a misconfigured role or mapper can leak a tenant boundary. Requires discipline.
Keycloak supports both; the trade is operational overhead vs isolation strength. Most serious multi-tenant SaaS uses per-tenant realms, often automated via the admin API or Operator at signup. Decide this before you onboard customers, because migrating tenants between models later is painful.
27. Common Pitfalls and How to Debug Them
- Redirect loop / blank page: almost always wrong
redirect_uri on the client or wrong KC_HOSTNAME/KC_PROXY behind the proxy. Check the constructed auth URL.
- "Invalid token signature" in app: app validates against the wrong JWKS or clock skew. Confirm the app fetches Keycloak's JWKS and system clocks are synced.
- Login works, authz fails: mapper not emitting the claim your app checks. Inspect the token in the account console; fix the mapper.
- Federation login fails silently: AD bind account lacks read perms or TLS to LDAP is misconfigured. Test bind with
ldapsearch from the Keycloak host.
- Sessions drop randomly: Infinispan not replicated across nodes; sticky sessions missing at the proxy. Align cache config and affinity.
Most Keycloak problems are configuration, not bugs. The admin event log and the token inspector are your friends; read them before you blame the software.
28. The Security Posture and Governance
Keycloak carries OpenSSF best-practice and scorecard badges and a CNCF-aligned governance posture under Red Hat. That matters for risk-averse buyers: it signals disciplined release and security practice, not a stalled community. The 26.x line ships regularly with security fixes, and the project's contributor base is broad and active. For an identity layer you are betting your company on, that governance is part of the value — it is why banks and governments trust it. The flip side is that Red Hat steers the roadmap; features you want may wait on their priorities. Accept that as the cost of a backed, not forked, project.
29. Frequently Asked Questions
Is Keycloak really free? Yes — Apache-2.0, no per-user fee, all core features in the free build. You pay only for infrastructure and (optionally) RHBK support.
Does it need a database? Yes, PostgreSQL or MySQL. No embedded DB for production. Back it up.
Can it terminate SAML for my legacy app? Yes. Keycloak brokers SAML and issues OIDC to your app, hiding the SAML complexity.
Is HA hard? Intra-datacenter HA is achievable (replicated Infinispan + replicated DB). Cross-region active-active is a distributed-systems project requiring real expertise.
When should I just use Auth0? If you are a tiny team with no platform staff and need login today with an SLA, the hosted convenience is the product you are buying. Keycloak pays off at scale and where residency matters.
30. Sizing by User Count
- Under 1,000 users: a single Keycloak node on 2 vCPU / 2 GB plus a managed Postgres is comfortable. The database is your main stateful concern; the app is light.
- 1,000–10,000 users: run two app nodes behind the proxy with replicated Infinispan for resilience; size the database up. Still one person can operate it.
- 10,000–100,000 users: proper HA — replicated database, replicated cache, monitoring, scheduled upgrades. A platform team owns it.
- 100,000+ or regulated: multi-cluster or RHBK with a subscription for SLAs; treat identity as a tier-0 service with on-call.
Note the licence cost stays $0 at every tier. Only infrastructure and ops grow. That flat licence curve is the entire reason large SaaS and governments run Keycloak instead of a per-MAU IdP.
31. Why Keycloak Is Not an Open-Core Trap
It is worth stating plainly, because the previous article in this batch — Rocket.Chat — is open-core, and the distinction matters. Keycloak's valuable features are not gated behind a commercial edition. SSO, federation, authorization, MFA, passkeys, themes, HA-building-blocks: all free. Red Hat's commercial offering is
support and a certified build, not locked features. You are never forced to pay to get the thing you deployed. That makes Keycloak one of the cleaner open-source infrastructure stories in this series: the free software is the whole software. Budget for operations, not for licences — a rare and welcome position.
32. A 30-Day Evaluation Plan
- Week 1: Deploy Keycloak + Postgres behind a reverse proxy; create a
prod realm (not master); register one test app as an OIDC client; make login work with PKCE.
- Week 2: Add MFA (TOTP + WebAuthn); federate one external IdP (Google or GitHub) and one LDAP if you have a directory; verify token claims with the account-console inspector.
- Week 3: Load-test token issuance; wire OpenTelemetry metrics into Grafana; practice a database backup and restore.
- Week 4: Model your authz as roles or authorization policies; cut over one real app from its current auth to Keycloak; compare the TCO against your hosted IdP at your user count and decide.
A pilot this disciplined turns "self-host our auth" from a hope into a defensible decision — with numbers for finance and a tested restore for the security team.
33. The Bottom Line for Different Organizations
- Solo developer / tiny startup: if you have no platform staff and need login this week, a hosted IdP's free tier is less work. Keycloak's value appears once you grow.
- Scaling SaaS: this is Keycloak's home turf. Per-MAU pricing at 50k users is hundreds a month; Keycloak is a database and your ops time. The licence flatline pays for the platform team many times over.
- Enterprise / government / regulated: Keycloak's protocol depth, federation, and Red Hat-backed governance make it the default open choice. Staff the operations and you get sovereignty and control a SaaS cannot offer.
- Data-residency-required: self-hosted Keycloak keeps credential material hashed on your database and sessions in your cache, with no external party seeing a login unless you broker one. That is the residency story in one sentence.
Keycloak is free in licence and expensive in operation — and for the orgs it fits, that trade is exactly right. The teams it betrays are the ones that deploy it expecting an appliance and discover they bought a responsibility.
34. One Paragraph If You Read Nothing Else
Keycloak is the leading open-source identity platform, and unlike most things in this series it is not an open-core trap: SSO, federation, authorization, MFA, and HA-building-blocks all ship free under Apache-2.0, with no per-user fee ever. The cost is operational, not licensing — you run a database, a proxy, backups, upgrades, and, for real resilience, a clustered deployment you understand. At scale, that flat licence curve is why SaaS and governments choose it over per-monthly-active-user IdPs; for a tiny team with no platform staff, a hosted IdP's convenience may still win. Self-hosted, your users' credentials stay hashed on your database and their sessions in your cache, with no external party seeing a login unless you explicitly broker one. Sovereignty is real; the responsibility is real too. Deploy it with the respect an identity layer demands, and it will serve you for a decade.
Related
For the rest of a self-hosted, sovereign stack, these pieces from our series travel with Keycloak:
Comments (0)
No comments yet. Be the first to comment!