Keycloak, after the legacy SSO rename.

Red Hat build of Keycloak licensing meters by core on the host running the Keycloak server process. The product is the successor to the Red Hat Single Sign On product, retired as a name and replaced by the build of Keycloak in line with the upstream project's rebrand. The runtime base moved from WildFly to Quarkus, which produced a smaller memory footprint and faster startup but did not change the metered unit. The per core entitlement is the same. The federation reach against external identity providers and the realm structure within the server are also the same.1

The product is sold standalone and inside the Red Hat Runtimes family. On a standalone purchase, the entitlement covers only the Keycloak server. Inside the Runtimes bundle, the same entitlement carries the other runtimes, which lets the Keycloak deployment share the bundle with Quarkus applications that use Keycloak for authentication. The buyer side reading on the bundle is the same as on the standalone Quarkus subscription: the bundle pays at the second runtime, not on standalone Keycloak alone.

For the broader middleware practice context, see the JBoss and middleware practice hub. For the strategic shape under which Keycloak entitlement reshape work normally sits, see the advisory retainer service hub.

Three counting traps recur on Keycloak deployments. Each is correctable through reshape before audit or renewal but each can also produce a meaningful gap if the operator did not run the reconciliation in advance.

The first trap is counting the cores on every Keycloak replica in a high availability cluster. The Keycloak server normally runs in a clustered configuration for high availability, with two to four replicas behind a load balancer. All cores across all replicas are in scope under the standard rule because every replica is an active Keycloak server. The reshape sits in reducing the replica count where the cluster has been overscaled for headroom rather than for actual load, not in arguing that idle replicas should be excluded.

The second trap is treating the Keycloak server's external database host as out of scope only to find it in scope under another agreement. The Keycloak server requires an external database, normally PostgreSQL. The database host is out of scope under the Keycloak entitlement; it is in scope under the RHEL entitlement if the host runs RHEL and under any database support agreement that covers the database engine. The reshape is to confirm the database host's full licensing footprint sits inside the existing RHEL count rather than producing a parallel exposure.2

The third trap is licensing the same Keycloak deployment twice when it runs on OpenShift. Keycloak on OpenShift consumes both the Keycloak entitlement and the OpenShift entitlement on the worker nodes that host its pods. The reshape is to confirm that the worker node entitlement is sized for the actual Keycloak pod core consumption, not for the full worker capacity, and that the entitlement chain is documented. For the surrounding OpenShift node mechanics, see the cross product reading on container platforms generally.

The Red Hat Single Sign On contract often persists past the rename. Existing customers with the prior SSO entitlement carry it through the rebrand and the seller side normally honours the existing count at renewal under the Red Hat build of Keycloak SKU. The migration is operationally non trivial because the underlying runtime shifted from WildFly to Quarkus, which changes the configuration approach, the migration tooling, and the operational handbook. The licensing migration is automatic. The technical migration is not.

Three migration patterns work in operational practice. The first is in place upgrade with the Red Hat migration tooling, which preserves the entitlement structure and lets the operator move at the pace the team supports. The second is parallel build of a new Keycloak deployment alongside the existing SSO server, which produces a clean cutover at the cost of running both entitlements through the migration window. The third is migration to a hosted Keycloak alternative, which moves the operational burden but changes the entitlement model entirely. For estates considering the hosted route, the cross product reading against container security on OpenShift is treated in the Advanced Cluster Security pricing note.3

The seller side has used the migration window to position larger Runtimes commitments. The buyer side reading is to separate the technical migration from the commercial expansion; the rename is not a renewal trigger and the entitlement should carry through without commercial change unless the deployment shape itself changes.

Keycloak is an upstream open source project. The community distribution runs the same binaries as the Red Hat build, with the paid build providing support, certified compatibility within the Red Hat platform, and a long term maintenance commitment on selected versions. The boundary against community use is consequential because identity is normally a production critical function and the support value is real.

Three boundary patterns work in operational practice. The first is paid build on production identity infrastructure, community build on internal tools and development environments. This is the common pattern. The reshape requires technical separation, particularly on shared OpenShift clusters where the namespace boundary needs to enforce the entitlement boundary.

The second is paid build only on the realms that face external users. A Keycloak server normally hosts multiple realms, with some realms serving external authentication flows and others serving internal applications. Where the realm boundary aligns with the support criticality, the reshape is to split the realms across separate servers and entitle only the production realm servers under the paid build. This pattern works on mature estates with stable realm boundaries.

The third is paid build only on long term support versions. Where the paid build's maintenance commitment is the actual value, the reshape is to license only the servers that pin to a long term version and let the rest run the community release. This pattern is more common on internal identity infrastructure than on customer facing identity, where vendor support is normally non negotiable. For the sibling cluster note on the Apache Camel runtime that often pairs with Keycloak on integration estates, see the Apache Camel licensing note. For the surrounding Runtimes context, see the Quarkus licensing note.

The renewal posture on a Keycloak estate has three components worth preparing before the seller side prices the next term. The first is the core inventory across all Keycloak servers, with the high availability replica structure documented so that the count is defensible by reference to operational requirement rather than to history. The second is the adjacent entitlement chain, which should resolve every Keycloak host's RHEL or OpenShift entitlement so that the licensing footprint of the identity function is read as a whole. The third is the community boundary, with the technical enforcement documented for each environment where the paid build and the community build coexist.

The seller side at renewal often positions Keycloak as a strategic identity platform and pairs the renewal with a Runtimes bundle pitch. The buyer side reading is to treat the bundle on Keycloak the same as the bundle on Quarkus: the bundle pays at the second runtime, not before. Where the estate already runs Quarkus on entitled hosts, the bundle conversation has real economic basis. Where it does not, the standalone Keycloak entitlement is the cleaner posture.

One industry context shifts the conversation materially. Regulated industries face audit pressure on identity infrastructure that often forces production critical components onto vendor supported runtime. The reshape conversation in regulated estates is constrained by the documentation requirements the regulator imposes; the boundary against community Keycloak is normally drawn closer to the production critical side. For the surrounding audit dynamics in regulated industries, see the financial services audit considerations note.

For estates evaluating Keycloak licensing ahead of a renewal or audit, the engagement is normally a subscription assessment scoped to the Keycloak server inventory plus a community boundary review and an adjacent entitlement check. To begin, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.