Keycloak is one of the best open-source projects in identity. It speaks every protocol that matters — OIDC, OAuth2, SAML, LDAP, Kerberos — and it scales from a side-project to a multi-region authentication backbone. We love it. We’ve shipped it for a decade.
But the second you put it behind a real product — one with paying customers, compliance audits, and a four-year-old SSO integration that someone forgot to document — you find a gap that the upstream project does not, and should not, try to fill.
That gap is operational lifecycle. And it’s the reason we built Aerobase LTS.
The treadmill nobody warned you about
Keycloak ships fast. New minor releases land roughly every six to twelve weeks, and majors land more often than most enterprise teams can absorb. Each release lands fixes, but it also lands deprecations, configuration changes, theme-API churn, and the occasional database migration that runs in the background while your auth service is supposed to be answering requests.
The upstream community is explicit about this: there is no formal LTS line. Once a version is two or three minors behind, it is unsupported. CVEs are fixed forward, not back-ported. Tomorrow’s container image is the only place security fixes live.
For a team running a self-hosted IdP, that means one of three uncomfortable choices:
- Upgrade every quarter. Re-test every flow, every theme, every extension, every federation, every IDP-initiated SAML response, every custom authenticator. In production. Forever.
- Stay behind and pray. Run an EOL version, hope your VPN and WAF buy you time, and explain to your auditor why the CVE dashboard is mostly red.
- Pay someone to do option (1) for you on a supported release line.
Most teams pick (2) for longer than they should. We’ve watched it happen at three-person startups and at five-thousand-person banks. The upstream project hasn’t done anything wrong; it’s just not designed to be a vendor.
What “production” actually demands
When we talk to teams running Keycloak in earnest, the same five things keep coming up:
- A version line that lives for years, not months. Internal change-management cycles, audit cadences, and integration partners do not move on Keycloak’s schedule.
- CVEs back-ported to that line. Not a “fixed in 26.5, please plan an upgrade” — an actual patch on the release the team is already running.
- Predictable upgrades, with a real path off the LTS when it sunsets. Database migrations rehearsed. Breaking changes called out. Theme/SPI compatibility documented.
- Production-grade packaging. Linux packages with init integration, log rotation, recovery tooling, configurable backends, drop-in TLS — not “here is a JAR, good luck.”
- Someone who picks up the phone at 02:00. SLA-backed support, with the ability to ship a hotfix without waiting for the next upstream cycle.
Upstream Keycloak intentionally provides exactly zero of those things. It is a project, not a product. That’s a feature, not a bug — but it leaves a real shape of work to be done, and that work is what we’ve been doing for years anyway. Aerobase is what happens when we stop pretending it isn’t a product.
What Aerobase LTS actually is
Concretely:
| Upstream Keycloak | Aerobase LTS | |
|---|---|---|
| Release cadence | New minor every 6–12 weeks | One LTS line at a time |
| Support window | ~3 minors back | 2 years per LTS line |
| CVE policy | Fixed forward only | Back-ported to the LTS line |
| Packaging | Container images, ZIP | Linux packages (deb/rpm), Windows installer (Enterprise) |
| Operational tooling | None | aerobase-ctl (start/stop/recover/tail), runit supervision, recovery flows |
| Upgrade testing | Community | Tested upgrade paths between LTS releases |
| Extensions | DIY | Curated, supported extensions (SMS 2FA, REST federation, server-log admin, etc.) |
| Themes | DIY | Aerobase login/admin/account/email themes maintained against the LTS |
| Custom workflows | Hire someone | Included consulting hours per plan |
| Production support | Community forums | SLA-backed (12h Basic / 6h Enterprise / 24x7 critical) |
Underneath, every Aerobase build is the upstream Keycloak release we’ve targeted, plus the integration code we’d otherwise be writing for our customers individually: packaging, supervision, recovery, themes, extensions, and a tested upgrade path off the LTS when its window ends.
A concrete example: the CVE gap
Here is what life looks like during a high-severity Keycloak CVE on plain upstream:
- Disclosure lands at 14:00 UTC, fixed on
mainand a minor or two back. - Your version is four minors behind. Patch is not back-ported.
- You spend three days running the upgrade through QA. Two themes break. One custom authenticator no longer compiles against the new SPI. A SAML attribute mapper changed shape.
- You ship the upgrade six days later. Your security team logs it as an incident.
On Aerobase LTS:
- Disclosure lands.
- We back-port the fix to every LTS line under support, run the regression suite, and cut a patch release.
- You apply the patch. The version number doesn’t move. Your themes, extensions, federations, and SAML mappers don’t move. Your auditor smiles.
That is essentially the entire pitch. Everything else — the packaging, the consulting hours, the dynamic-branding extension, the dedicated Slack channel — is downstream of that one promise: the version your team runs on a Tuesday will still exist on a Friday, and it will be patched.
Where upstream is still the right answer
We’re not interested in pretending Aerobase is for everyone. If you’re:
- Building a side project, a homelab, or a non-production internal tool
- Comfortable upgrading on the upstream cadence
- Not running anything that needs an SLA, an audit trail, or an answer at 02:00
…upstream Keycloak is the right answer. It’s the same engine that’s inside Aerobase. Use it directly, contribute back, and skip the support contract. We’re cheering for you.
If, on the other hand, your auth platform is load-bearing for revenue, compliance, or trust — the kind of system where you find out you have a problem because someone in another department gets paged — you almost certainly want a supported lifecycle around it. Build it yourself or buy it from us; either way, do it before the next CVE forces the conversation.
Try it
- Open source build (free, forever): aerobase.io/downloads
- LTS plans & SLAs: aerobase.io/plans
- Docs: aerobase.io/docs/gsg
- Talk to us: support@aerobase.io
If you’re already running upstream Keycloak in production and you’re tired of the upgrade treadmill, drop us a line with your version. We’ll tell you, honestly, whether moving to an LTS line is worth it for you — even if the answer is “stay where you are.”