Keycloak vs Red Hat Build of Keycloak

Keycloak is the open-source identity and access management project. Red Hat build of Keycloak (RHBK) is Red Hat’s commercially supported distribution of Keycloak, built from selected versions of the same upstream project.

The basic IAM features are therefore very similar. The main difference is how the software is released, tested, supported, and maintained. With upstream Keycloak, your team chooses versions and owns platform validation and upgrades. With RHBK, Red Hat provides tested builds, supported configuration combinations, a published lifecycle, and subscription support.

Keycloak vs Red Hat Build of Keycloak: Quick Answer

RHBK should not be thought of as a separate “premium Keycloak” with an entirely different IAM feature set. The commercial value is primarily the supported build, tested configuration matrix, lifecycle, qualified fixes, product documentation, and Red Hat support relationship.

Use upstream Keycloak when you want the community project and will own upgrades yourself. Use RHBK when you want Red Hat’s tested builds, product docs, and subscription support on a published lifecycle.

Is Red Hat Build of Keycloak the Same as Keycloak?

RHBK is based on upstream Keycloak, but it is a Red Hat product distribution rather than just another community image. Red Hat selects upstream releases, productizes and tests them, publishes supported configurations and lifecycle policies, and provides subscription support.

The core IAM concepts remain Keycloak concepts. The main differences are release timing, support status, packaging, supported platforms, documentation, and lifecycle.

What Upstream Keycloak Provides

Upstream Keycloak is the open-source identity and access management project many teams mean when they say “Keycloak.” It provides realms, clients, users, roles, OIDC and SAML, user federation, identity brokering, and the Admin Console. What is Keycloak? walks through those building blocks.

The usual lab image path is quay.io/keycloak/keycloak:<tag> on Quay. Community install guides such as Install Keycloak with Podman use that public registry. You choose the database, reverse proxy, JVM, and host OS. With upstream Keycloak, your team owns the upgrade cadence when fixes are released. Unlike RHBK, upstream Keycloak does not give you a Red Hat product lifecycle committing to maintenance of an older product stream.

From Keycloak 26 onward, the project described a slower major cadence with more frequent minors and a stronger push for backwards-compatible minors. That helps operators, but it is still a community project, not a Red Hat subscription product.

What Red Hat Build of Keycloak Adds

Red Hat build of Keycloak is Red Hat’s commercial IAM offering based on the Keycloak community project. Red Hat tests and supports it on published platforms. You get:

• Product documentation on docs.redhat.com for each RHBK stream
• A published life cycle (full support and maintenance) with at least two major.minor streams supported at a time
• Access to Red Hat support under your subscription agreement
• Container images under registry.redhat.io/rhbk/… (login required)
• Alignment with even-numbered upstream Keycloak minors under the current release policy for RHBK 26.x and later (for example 26.0, 26.2, 26.4, 26.6), while odd-numbered upstream minors are skipped as RHBK baselines

RHBK is not a separate IAM product with unrelated code. It is Red Hat’s build, packaging, testing, documentation, and support model around selected upstream Keycloak releases. That is why versions do not always line up one-for-one, why Red Hat skips odd-numbered upstream minors, and why Red Hat can maintain fixes on its product stream under a published lifecycle.

Does RHBK have different Keycloak features?

The core IAM model and major capabilities are inherited from upstream Keycloak, including realms, OIDC, SAML, authentication flows, user federation, identity brokering, roles, and clients. However, feature availability and support status depend on the exact upstream and RHBK versions being compared.

A feature may arrive in an upstream minor that RHBK skips, or it may be Preview or Experimental upstream and not be supported by Red Hat. Compare the exact Keycloak and RHBK versions rather than assuming every upstream feature is supported in every RHBK stream. Red Hat’s component-details pages for each release separately call out Technology Preview, deprecated, and unsupported items.

Release Cadence and Version Alignment

After Keycloak 26, upstream aims for about four minor releases per year and less frequent majors. RHBK, from the 26.x stream, publishes minors roughly every six months and bases those minors on even-numbered upstream Keycloak minors.

  Upstream:
  26.0 ─ 26.1 ─ 26.2 ─ 26.3 ─ 26.4 ─ 26.5 ─ 26.6 ─ 26.7
   │             │             │             │
   ▼             ▼             ▼             ▼
  RHBK:
  26.0 ───────── 26.2 ───────── 26.4 ───────── 26.6

          RHBK tracks even-numbered upstream minors

Under the current policy, odd-numbered upstream minors such as 26.1, 26.3, and 26.7 are not used as RHBK minor baselines. In practice:

• An RHBK 26.2 or 26.6 stream tracks a selected even upstream line, not every quarterly community tag.
• You may see a community 26.3 or 26.7 on Quay that has no matching RHBK product tag.
• Choosing RHBK means planning upgrades on Red Hat’s even-minor schedule and lifecycle phases, not chasing every community micro tag.

For example, Red Hat’s RHBK 26.6.2 component table lists Keycloak 26.6.2 as its Keycloak base. Upstream can subsequently publish 26.7.x, while RHBK remains on its maintained 26.6 product stream rather than producing an RHBK 26.7 release.

Exact calendar dates belong on Red Hat’s release and maintenance schedule articles. Refresh those pages when you plan an upgrade window.

Support Lifecycle and Security Fixes

For RHBK 26.x and later, full support for a major stream ends when the next major becomes generally available. The previous major then enters maintenance for at least six months so customers can upgrade. RHBK 24 had a shorter major lifecycle; do not copy 24.x expectations onto 26.x.

If you need a named support window and someone to call, that is the usual reason teams buy RHBK instead of running Quay tags alone.

Supported Platforms, Images and Deployment Scope

Upstream Keycloak documents how to run the server. It does not publish a Red Hat–style matrix of tested OpenShift, JVM, and database combinations with subscription coverage.

RHBK does. Red Hat’s Supported Configurations article lists tested OpenShift, operating system, JVM, and database combinations for each release. Production and development support for those combinations follow your subscription.

Container image paths you will see in docs:

Pull the community image from Quay when you follow upstream docs (no registry login):

podman pull quay.io/keycloak/keycloak:26.7.3

For RHBK, authenticate to the Red Hat registry first (Customer Portal, Developer, or a registry service account), then pull the product image:

podman login registry.redhat.io

After a successful login, pull the RHBK tag your stream documents. The example below matches Red Hat’s 26.6 container guide:

podman pull registry.redhat.io/rhbk/keycloak-rhel9:26.6

Day-2 operations such as start versus start-dev still apply on both; see Keycloak start vs start-dev for the mode difference. This page stops at image paths. It does not walk a full install.

Feature Status and Documentation Differences

Core IAM capabilities (OIDC, SAML, realms, clients, federation, brokering) exist in both lines because RHBK tracks Keycloak. Differences usually come from:

• Which minor you are on (even RHBK stream versus a newer odd community minor)
• Preview features that may appear upstream first
• How Red Hat labels supported versus deprecated items for a given major stream
• Where you read release notes: keycloak.org versus the RHBK docs for that version

When a feature matters for compliance or production, check its status in the exact stream you will run. Do not assume bit-for-bit parity between quay.io/keycloak/keycloak:26.3 and registry.redhat.io/rhbk/keycloak-rhel9:26.2.

Community how-tos often assume Quay tags. RHBK operators should prefer Red Hat’s Server Guide, Release Notes, and Migration Guide for the subscribed stream, then use community material as background.

Red Hat SSO Naming and History

Older docs still say “Red Hat SSO” or “RH-SSO.” That was Red Hat’s previous single sign-on line (commonly RH-SSO 7.x on JBoss EAP). Red Hat build of Keycloak is the current commercial product based on modern Keycloak (Quarkus distribution). Red Hat’s RHBK documentation treats RHBK as the path forward instead of an RH-SSO 8.0 line.

Do not confuse RHBK with Red Hat Directory Server or other Red Hat identity directory products. Those solve different problems.

Migrating from RH-SSO or Upstream Keycloak to RHBK

Common paths:

• RH-SSO 7.6 → RHBK is a significant platform and configuration transition because RH-SSO was EAP-based and RHBK is Quarkus-based.
• Upstream Keycloak → RHBK should be validated against the target RHBK version, Red Hat’s tested and supported configuration matrix, and extension compatibility.
• Older RHBK major → newer RHBK major follows that stream’s Migration Guide.

Follow the Migration Guide for the exact target RHBK version on docs.redhat.com. This page does not walk the full RH-SSO or Operator procedure.

Which Edition Should You Choose?

Upstream Keycloak is usually a better fit when:

• You are learning, testing, or prototyping
• Your team can own upgrade timing and platform validation
• You want the newest community minor as soon as it ships
• You do not need a Red Hat support ticket path for the IAM layer

RHBK is usually a better fit when:

• You need a published product lifecycle and subscription support
• You need your deployment to fall within Red Hat’s published tested and supported configuration matrix
• You want RHBK product documentation and even-minor streams as your upgrade track

Many enterprises run upstream Keycloak successfully. The trade-off is operational ownership, not a missing IAM feature set.

Summary

Upstream Keycloak and Red Hat build of Keycloak share the same IAM foundation because RHBK is a downstream product built from selected upstream releases. Upstream gives you the community project, public Quay images, and a fast release train you operate yourself. RHBK gives you Red Hat’s tested builds, authenticated registry images, product documentation, and a published support lifecycle that, from 26.x onward, aligns with even-numbered upstream minors.

Pick upstream when you want speed and self-support. Pick RHBK when you need vendor lifecycle, tested and supported configurations, and subscription support. Confirm current dates and matrices on Red Hat’s lifecycle and Supported Configurations pages before you lock a production stream, and use the target stream’s Migration Guide when moving from RH-SSO or an older Keycloak deployment. Pulling or customizing the RHBK image with Podman is not by itself the same as choosing a Red Hat–supported production platform for that stream.

References

• Keycloak documentation
• Backwards compatibility in Keycloak releases (Keycloak blog, Oct 2024)
• Red Hat build of Keycloak Life Cycle and Support Policies
• Red Hat build of Keycloak Supported Configurations
• Red Hat build of Keycloak support on 3rd-party Kubernetes environments
• Red Hat build of Keycloak documentation
• Migrating Red Hat Single Sign-On 7.6 to Red Hat build of Keycloak
• Running Red Hat build of Keycloak in a container