Is Self-Hosting Keycloak Worth It in 2026? An Honest Reality Check

Last updated: May 2026

Self-hosting Keycloak is worth it when you have the IAM and operations expertise on staff and you need data control, deep customization, or freedom from per-user fees. It is not worth it when a small team would spend more on operational toil, upgrades, CVE patching, and high availability, than the underlying auth problem actually justifies. Managed Keycloak is the middle path: you keep the open-source engine and flat pricing, but someone else carries the operational weight.

This guide is not a sales pitch for one side. Keycloak is genuinely excellent software, and plenty of teams run it themselves for years without drama. The question is whether your team is one of them. Below, we walk through the real operational burden, the cases where self-hosting clearly wins, the trade-off hiding inside Keycloak’s flexibility, and a decision framework you can apply this week.

What does the operational burden actually look like?

The operational burden of self-hosting Keycloak is real, recurring, and underestimated by most teams before they start. Keycloak ships roughly four minor releases per year plus a major every two to three years (source: keycloak.org), and each one lands a stream of work on whoever owns the cluster. That work does not stop after launch.

Let’s break the burden into the pieces that actually consume engineering hours.

How often do you really have to upgrade?

More often than the headline cadence suggests. The official line is about four minor releases a year, but the real GitHub release stream is busier: 26.6.2 (May 19, 2026), 26.6.1 (April 15), 26.6.0 (April 8), 26.5.7 (April 2), and 26.5.6 (March 19) (source: GitHub releases). That’s a patch or minor roughly every two to four weeks.

You won’t apply every one. But you can’t ignore them either, because security fixes ride these same trains. Minor releases can include breaking changes, though they are opt-in and version-gated, and backwards compatibility explicitly does not cover preview features or APIs (source: keycloak.org). In our experience, the teams who get burned are the ones running on a preview feature they forgot was preview.

What changed when Keycloak moved to Quarkus?

A lot, and the migration was not automatic. Since v17 the default distribution is Quarkus, and from v20 the older WildFly distro is no longer published at all (source: keycloak.org). If you’re still anchored to old WildFly assumptions, that gap is your problem to close.

The Quarkus shift rewired several things teams depended on:

• XML configuration was replaced, with no auto-migration. You reapply settings manually.
• /auth was removed from the default context path. Existing client URLs break unless you adjust.
• add-user-keycloak.sh was removed.
• Custom providers now live in a providers/ directory with no hot-deploy. You rebuild and restart.
• Startup is now two phases: kc.sh build, then start.

None of this is insurmountable. But it is the kind of change that turns a “quick upgrade” into a planning exercise.

Who patches the CVEs?

You do. When you self-host, security advisories are your inbox, your triage, and your maintenance window. In 2025 alone, tracked Keycloak CVEs included CVE-2025-3501, a trust-store verification bypass rated CVSS 8.2, and CVE-2025-11419, a TLS-renegotiation denial-of-service rated CVSS 7.5, alongside others covering privilege escalation and 2FA bypass (source: GitHub advisories).

A trust-store bypass on your identity provider is not a “patch it next sprint” issue. It’s a same-week issue. Multiply that across a year, and CVE response becomes a standing commitment, not an occasional chore. Want a structured way to handle it? See our Keycloak security audit and hardening checklist.

Why is high availability the hardest part?

Because multi-site HA in Keycloak is a genuinely advanced topology with real constraints. The supported architecture requires a synchronously-replicated database across sites, an external Infinispan cluster with synchronous replication, and a load balancer that can detect failures (source: keycloak.org). It is tested and supported with only two sites.

There’s a subtler catch. After a cross-site failure, manual re-synchronization steps are required, and you need monitoring in place to even know it happened (source: keycloak.org). Synchronous replication across sites also assumes low-latency, single-region-class networking, so geographically spread “active-active” is not a free option.

Here’s the part most blog posts skip: HA isn’t a one-time setup you check off. It’s a thing you operate. The manual re-sync requirement means a failover event creates work for a human at 3 a.m., not just an automatic recovery. If your team can’t staff that, your “highly available” cluster is highly available only until the first real failure.

What about database tuning, backups, and monitoring?

These are the quiet line items that decide whether your cluster stays healthy. Keycloak’s own guidance is specific on connection pooling: set initial, minimum, and maximum pool sizes equal, and ensure total connections across all instances stay under the database’s max_connections (source: keycloak.org). Get this wrong and you discover it under load, which is the worst time.

Then there’s everything the docs assume you already do: database backups, disaster-recovery rehearsals, theme migration on every upgrade, and provider re-validation. Upgrades require migrating both the database and your themes, and custom themes and providers need per-version attention (source: keycloak.org). If you self-host, build a real Keycloak disaster recovery runbook before you need it, and walk a production-ready checklist before launch.

When does self-hosting genuinely win?

Self-hosting wins decisively in three situations, and they’re worth taking seriously because the trade-off is real value, not just cost cutting. Keycloak ships under the Apache License 2.0 with no per-user or per-MAU fees, which means costs stay roughly flat from 100 to 100,000 users since you’re paying for infrastructure, not seats (source: GitHub). That single fact reshapes the math for high-growth and high-volume products.

Do you need data residency or air-gapped control?

If yes, self-hosting may be the only honest answer. When regulation, contracts, or a security posture demand that identity data never leaves your infrastructure, a SaaS identity provider is off the table by definition. Self-hosted Keycloak lets you run inside your own VPC, your own region, or a fully air-gapped network. You own the data path end to end. No third party touches the token-signing keys or the user store.

Will per-user pricing punish your growth?

This is where the licensing model matters most. Commercial identity providers typically price by Monthly Active Users, so your bill scales directly with adoption (source: Auth0). Keycloak’s flat, infrastructure-only cost behaves very differently as you scale.

We’ve broken this trade-off down in detail elsewhere. For the full breakdown, see what is the cost of self-hosting Keycloak and our comparison of self-hosted vs managed authentication cost. The short version: below a certain user count, MAU pricing is often cheaper than running your own infrastructure. Above it, the flat model pulls ahead, sometimes dramatically.

Do you need deep customization?

Keycloak’s Service Provider Interfaces are a serious differentiator. You can extend authentication flows, plug in custom user storage, hook events, add REST endpoints, and reshape the UI through documented SPIs (source: keycloak.org). Few hosted identity products let you go this deep without leaving their walled garden. If your auth requirements are genuinely unusual, this flexibility is hard to replicate elsewhere.

Is Keycloak’s flexibility also its fragility?

Yes, and pretending otherwise does a disservice to the decision. Every custom SPI you write is both a capability and a liability, because each one becomes something you re-validate on every upgrade. The same documented extension points that make Keycloak powerful also expand the surface area you maintain (source: keycloak.org).

Think of it as a coin with two faces:

• The power face: A custom user-storage SPI lets you authenticate against a legacy directory no SaaS would ever support. A custom authenticator enforces a workflow unique to your business.
• The fragility face: That same SPI may break on a minor release, especially if it touches non-guaranteed internals. Remember, backwards compatibility excludes preview features and APIs (source: keycloak.org).

The teams who struggle most aren’t the ones who avoid customization. They’re the ones who customize heavily and also run lean ops. Deep SPIs plus a two-person team is the combination that turns a routine upgrade into a multi-day firefight. The customization isn’t the problem. The mismatch between customization depth and operational capacity is.

How should you decide? A practical framework

Decide based on the gap between what self-hosting demands and what your team can actually sustain, not on a feature checklist. The features rarely block teams. The recurring operational load does, because Keycloak releases land roughly every two to four weeks and HA failover requires manual re-sync steps (sources: GitHub releases, keycloak.org). Match the burden to your bench.

Use this table as a starting point.

Signal	Lean toward self-hosting	Lean toward managed
In-house IAM and ops expertise	You have dedicated platform/SRE staff	Auth is a side duty for a small team
Data residency / air-gap requirement	Strict, non-negotiable	Flexible or none
Customization depth	Heavy SPI usage required	Standard flows are enough
User scale and growth	Large or fast-growing user base	Modest, stable user count
Tolerance for upgrade/patch cadence	You can absorb work every few weeks	Maintenance windows are scarce
HA / failover staffing	You can handle manual re-sync at any hour	No on-call coverage for identity
Budget shape	Prefer flat infra cost	Prefer predictable, hands-off cost

Read it as a balance, not a scorecard. Two or three strong signals on one side usually settle it.

A quick self-test

Ask three honest questions. Who patches a CVSS 8.2 advisory the week it drops? Who runs the manual re-sync after a cross-site failover at 2 a.m.? Who migrates the themes and re-validates the custom providers on the next major upgrade?

If the answer to all three is “a capable person who has time,” self-hosting is a strong fit. If the answer is “we’d figure it out,” that’s the signal to consider managed. Either way, run the Keycloak production-ready checklist before you commit to a path.

What does managed Keycloak actually solve?

Managed Keycloak solves the operational-burden problem while preserving the two things that make Keycloak attractive in the first place: it’s open source and it has no per-user pricing. You keep the Apache-licensed engine and the flat cost model (source: GitHub), but the upgrades, CVE patching, HA topology, database tuning, and backups become someone else’s standing commitment.

That’s the honest pitch. It removes the toil documented above, the every-few-weeks release stream, the manual failover re-sync, the per-version theme and provider migration (sources: GitHub releases, keycloak.org).

Here’s the equally honest caveat. Managed Keycloak does not remove the need to understand Keycloak itself. You still have to model realms, configure clients, set up protocol mappers, and design your authentication flows correctly. Nobody outsources your identity architecture. A managed provider carries the operational weight; the conceptual work of building auth that fits your product stays with you. If your difficulty is running Keycloak, managed helps enormously. If your difficulty is designing your auth model, you still need to learn the platform.

Frequently asked questions

Is Keycloak really free to self-host?

The software is free under the Apache License 2.0, with no per-user or per-MAU fees (source: GitHub). But “free software” is not “free to operate.” You pay in infrastructure plus the engineering time for upgrades, CVE patching, HA, and backups. The license is free; the operations are not.

How often does Keycloak release updates?

Officially around four minor releases a year plus a major every two to three years (source: keycloak.org). In practice the GitHub release stream is busier, with a patch or minor roughly every two to four weeks, including 26.6.2, 26.6.1, and 26.6.0 across April and May 2026 (source: GitHub releases). You won’t apply all of them, but security fixes ride these trains.

Is self-hosted Keycloak hard to make highly available?

It’s one of the hardest parts. Multi-site HA needs a synchronously-replicated database, an external Infinispan cluster with sync replication, and a failure-detecting load balancer, and it’s tested with only two sites (source: keycloak.org). After a cross-site failure, manual re-synchronization steps are required, so HA is something you operate, not just configure.

Did the move to Quarkus break existing setups?

It required deliberate migration. Since v17 Quarkus is the default and from v20 the WildFly distro is no longer published (source: keycloak.org). XML config was replaced with no auto-migration, /auth left the default context path, and providers moved to a providers/ directory with no hot-deploy. Existing teams had to reapply config and adjust client URLs manually.

When is managed Keycloak better than self-hosting?

When your team is small, auth is a side responsibility, and the operational cadence, releases every few weeks, CVE patching, and manual HA failover, would cost more time than the auth problem justifies (sources: GitHub releases, keycloak.org). Managed keeps the open-source engine and flat pricing while removing the toil.

The honest bottom line

Self-hosting Keycloak is a legitimate, often excellent choice. If you have the IAM expertise, need data residency or deep SPI customization, and want to escape per-user pricing as you scale, owning your own cluster pays off. The software is genuinely good, and the flat cost model is a real advantage at scale.

The catch is the recurring operational weight, which the licensing being free does nothing to reduce. Releases land every few weeks, CVEs demand same-week patching, HA failover needs a human in the loop, and every upgrade touches your database, themes, and custom providers. If your team can sustain that, self-host with confidence. If it can’t, you don’t have to give up open source or flat pricing to get relief.

That’s exactly the gap managed Keycloak fills. If you want the open-source engine without the operational toil, see Skycloak’s managed Keycloak hosting or review pricing to compare it against the cost of running it yourself.