When upstream Keycloak is enough and when Red Hat's build is worth paying for
Upstream Keycloak is enough when your team can carry the support load itself, and a Red Hat subscription is worth paying for when a contract, a support window or an existing Red Hat estate requires a vendor to answer for the product. The two distributions are close in code. Red Hat's migration guide says that starting with version 22, only minimal differences exist between Red Hat build of Keycloak and upstream Keycloak, so the decision is about who operates it, who you can call and what your procurement rules demand, not about features. Upstream artifacts come from keycloak.org, while Red Hat build artifacts come from the Red Hat customer portal, which is a practical difference for your software intake process.
Upstream is usually enough when your engineers already run Keycloak in production and can own upgrades, incident response and security patching. Check the packaging differences before you commit. The Oracle and Microsoft SQL Server database drivers are bundled with upstream Keycloak but not with the Red Hat build, so if your database is one of those, the Red Hat build needs the driver added through your own process. The GELF log handler is also absent from the Red Hat build, so if your logging pipeline depends on it, plan an alternative such as the handler your SIEM already accepts. Confirm both points against the migration guide for the version you plan to run, because the list of differences can change between releases.
A subscription matters when you need contractual support with a defined response path, when your audit or procurement rules require a named vendor for each identity component, or when you already run Red Hat Enterprise Linux or OpenShift and want one support relationship across the stack. Ask Red Hat which support windows apply to the version you select, since its product page showed version 26.6 as the latest at the time of the source, and confirm the current subscription terms directly with Red Hat. Also plan the version path: an upstream deployment on an older version must first be upgraded to the matching Red Hat build, and a deployment newer than the current Red Hat build cannot migrate to it. Test that path in a non-production environment before you pick the distribution.
Which differences are documented between the two distributions
This table sets the documented differences between upstream Keycloak and Red Hat build of Keycloak side by side, so you can see which gaps are concrete and which are minimal. Read each row as a checklist item to verify against the Red Hat documentation for the exact version you run or plan to run. The main takeaway is that the documented gaps are narrow, but artifact source, bundled drivers and logging handlers can still decide whether a given deployment works unchanged.
| Area | Upstream Keycloak | Red Hat build of Keycloak |
|---|---|---|
| Basis and product | Open source project under Apache-2.0, a CNCF incubating project | Red Hat's supported distribution based on the open source project, replacing Red Hat Single Sign-On |
| Artifact source | Distributed from keycloak.org | Distributed from the Red Hat customer portal, which requires a Red Hat account and entitlement |
| Oracle and SQL Server drivers | Database drivers for Oracle Database and Microsoft SQL Server are bundled | Those drivers are not bundled, so you must supply them if your database needs them |
| GELF log handler | Available for structured log shipping | Not available, so log pipelines must use another supported handler |
| Differences from version 22 onward | Reference baseline for the project | Red Hat documents only minimal differences from version 22 onward |
| Latest version shown | 26.8.1, released October 13, 2026 | Red Hat's product page showed 26.6 as the latest release |
| Feature parity check | Confirm against the upstream release notes for your version | Confirm current feature parity in the Red Hat documentation for your exact version before you migrate |
How licensing, support and update terms differ
Upstream Keycloak and Red Hat build of Keycloak share most of their code, so the practical difference is the terms around it: who licenses the software, how often releases arrive, and what a subscription promises. Each card below is a point to settle before you choose a distribution.
Apache-2.0 upstream license
Upstream Keycloak is licensed under Apache-2.0, and its LICENSE file governs use, modification and redistribution without a license fee. Red Hat's build is based on the same open source project, so the code itself is not where the license terms diverge. Check with your legal team which terms apply to the artifacts you actually deploy, and whether your subscription changes how you may redistribute or host them.
Community release cadence
Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years. Breaking changes in a minor release are opt-in, which lets you adopt new versions in steps. Plan your own upgrade rhythm around that cadence, and test each minor release against your realms, custom providers and database before rolling it out.
Subscription-backed support
A Red Hat subscription adds vendor support for the Red Hat build of Keycloak distribution, which replaces Red Hat Single Sign-On. The support window, severity levels, response targets and which product versions are covered are set in the subscription terms, not in the open source project. Ask Red Hat for the exact support lifecycle of the version you plan to run, and confirm whether it matches your change windows.
Customer portal artifacts
Upstream artifacts come from keycloak.org, while Red Hat build artifacts come from the Red Hat customer portal. That means your supply chain, mirror process and access control for downloads depend on a Red Hat account and entitlement. Confirm who in your organization holds portal access, how updates reach air-gapped or restricted networks, and how signed artifacts are verified before deployment.
What the subscription contract adds
Beyond support, a subscription may cover patch delivery, indemnification, certified container images or configurations, and access to specific product versions. None of these are guaranteed by the open source license, so do not assume them. Request the written subscription terms and list every entitlement you need, including backports of security fixes to older lines, before you compare prices.
Version matching and update limits
To move an upstream deployment onto Red Hat build of Keycloak, the upstream version must first be upgraded to the matching version. A deployment newer than the current Red Hat build cannot migrate to it and needs either a new deployment or a later Red Hat release. Confirm the matching version and the supported upgrade path with Red Hat before you schedule the move, since this constraint drives your timeline.
Why the code is nearly identical and where the gaps show up
From version 22 onward, Red Hat documents only minimal differences between Red Hat build of Keycloak and upstream Keycloak, so the identity features (OpenID Connect, SAML, federation, brokering and the admin console) are not where a migration usually stalls. The operational gaps sit in three places: how the artifacts are packaged and where they come from, which database drivers ship inside the distribution, and which log handlers are available. Upstream artifacts come from keycloak.org, while Red Hat build artifacts come from the Red Hat customer portal, so your build pipeline, mirror and access rights may need changes even when the code is the same.
The Keycloak Operator and the server distribution fail in different ways. The Operator is installed through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl, and it leaves the database to you. The server distribution on virtual machines puts the driver and logging configuration directly on the host. Oracle and Microsoft SQL Server drivers are bundled with upstream Keycloak but not with Red Hat build of Keycloak, and the GELF log handler is not available in the Red Hat build. A driver or handler that your configuration depends on can therefore block startup on the Red Hat build even though the identity logic is identical. In a pilot, confirm your exact database engine and its driver source, check whether your SIEM or log shipper consumes GELF, and test a cold start against a restored copy of your database. The Red Hat build of Keycloak 26.4 migration guide lists these differences and should be read against the version you intend to run.
Moving an upstream deployment to Red Hat build of Keycloak
This sequence takes an existing upstream Keycloak deployment to Red Hat build of Keycloak without surprises in drivers, logging or the database schema. Each step ends with a check you can record before moving on to the next.
Confirm the version match before anything else
Identify the exact upstream Keycloak version your deployment runs today and compare it with the Red Hat build of Keycloak release you plan to use. The documented rule is that an upstream deployment on an older version must first be upgraded to the matching version. A deployment newer than the current Red Hat build cannot migrate to it and needs either a new deployment or a later Red Hat release. Your platform owner or architect should make this call and record the version pair in the change request. Done means you have a written version pair that the vendor documentation supports.
Upgrade the upstream deployment to the matching version
Where the current upstream version is older than the matching release, upgrade the upstream deployment to that version first, using the Keycloak upgrading guide in a non-production copy. Keep the upstream artifact and configuration under version control so the upgrade is reproducible. Do not skip intermediate versions unless the upgrading guide permits it for your path. Done means the upstream deployment runs the matching version, logs in cleanly, and passes your smoke tests for every realm and client.
Check database drivers against the Red Hat artifact
The documented differences show that Oracle and Microsoft SQL Server drivers are bundled with upstream Keycloak but not with Red Hat build of Keycloak. If your database is Oracle or Microsoft SQL Server, the database platform owner must obtain and place a supported driver in the Red Hat build before startup, following the Red Hat migration guide. Confirm the driver source and licensing with your database team. Done means the database connection test succeeds on the Red Hat build in the non-production environment, with the driver version recorded.
Replace GELF logging with a supported handler
The GELF log handler is available in upstream Keycloak but not in Red Hat build of Keycloak. Inventory every logging configuration key in your upstream configuration and any log shipper that expects GELF messages. Replace the handler with a log output that your Red Hat build supports and that your SIEM or log platform can ingest, and confirm the field mapping with the team that owns log ingestion. Done means a test login produces events in your log platform in the expected format, and no GELF setting remains in the configuration.
Plan the database schema migration
Keycloak migrates its database schema automatically at startup by default. For smaller deployments that default is usually acceptable, but the upgrading guide suggests manual migration for large deployments, where administrators apply the SQL themselves. Decide which mode fits your environment, take a verified database backup, and have the database owner review the generated SQL if you choose manual migration. Done means you have a tested backup, a recorded migration mode, and a rollback plan agreed with the operations team.
Rehearse the full move in a non-production environment
Build a non-production copy with production-like data, realm exports, and the same database engine. Run the version-matched upgrade, the driver and logging changes, and the schema migration in the order above, then test federation, brokered logins, client sign-ins, and admin console access. Measure the cutover steps your team actually performed so the production runbook reflects real timings. Done means the rehearsal passes every test case in the runbook and the team signs off the findings.
Cut over to production and verify
Schedule the production change under your normal change process, apply the tested runbook, and verify logins for each realm and client, plus log delivery and metrics. Keep the upstream backup and the database rollback point available until the team confirms stability. Done means production passes the verification checklist and the change record captures the final version, driver, logging and migration mode.
Plan the reverse move back to upstream
If you later move back to upstream Keycloak, treat it as a separate change that follows the same version discipline: the upstream release you return to must match or be newer than the Red Hat build you are leaving, and you should confirm the downgrade path in the upgrading guide before starting. Re-check the artifact source, which moves from the Red Hat customer portal back to keycloak.org, and restore any drivers or handlers you removed. Done means a rehearsed rollback runbook exists and has been tested in non-production.
When a Red Hat subscription is worth paying for
Regulated enterprises often need a named vendor that answers for the software in production, through a support contract their risk, procurement and audit teams can point to. An upstream deployment can be fully supportable by an internal team or a partner, but some third-party risk programs and vendor due diligence files expect a supplier with a formal support lifecycle. The subscription matters most when that expectation is written into policy or into a regulator's or customer's requirement, and less when your own change-control process already covers the risk.
- Written support scope: Ask Red Hat which Keycloak versions, platforms and configurations fall under support, and whether custom providers or extensions are covered.
- Lifecycle commitments: Ask for the support end date of the exact release you plan to run, not the latest release shown on a product page.
- Response terms: Ask for severity definitions and the response targets attached to each, in the subscription document rather than a marketing page.
- Migration coverage: Ask whether upgrades between minor releases, and the move from upstream Keycloak, are included in the subscription.
- Evidence for auditors: Ask for a copy of the support agreement and the lifecycle statement you can file with your third-party risk records.
Confirm all of these with Red Hat's contract team, since the subscription terms, not the open source project, define what is supported.
Teams already standardized on Red Hat Enterprise Linux or OpenShift often find that Keycloak fits into existing support, patching and change processes. The Keycloak Operator is installed through Operator Lifecycle Manager, which is the recommended route, so an OpenShift platform team may already run similar operators under one support boundary. The subscription is most worth weighing when the Red Hat platform support and the identity service would otherwise be handled by different vendors during the same incident.
- Single support boundary: Ask whether a ticket involving OpenShift, RHEL and Keycloak can be routed without the customer proving which layer failed.
- Operator lifecycle: Confirm which Keycloak Operator versions Red Hat supports on your OpenShift release, and how updates are delivered.
- Certified packaging: Ask which container images and artifacts are the supported ones, and whether they come from the Red Hat customer portal.
- Database support: Ask which databases are covered in your configuration, because the supported list must match the database you actually run.
- Patch cadence: Ask how security fixes are delivered between minor releases and what your team must do to receive them.
If your platform team already has a Red Hat contract, ask whether Keycloak can be added to it rather than purchased separately.
Teams with strong internal Keycloak skills and no support mandate can often run the upstream distribution with lower licensing cost, since Keycloak is licensed under Apache-2.0 and the release artifacts are published by the project. The trade-off is that your own engineers carry upgrade planning, security response and incident work. The subscription is less likely to be worth it when you have tested upgrade runbooks, a monitored staging environment and staff who can read the release notes and migration guide for each minor release.
- Upgrade ownership: Keycloak plans four minor releases a year, so budget engineer time for regular upgrades rather than occasional ones.
- Breaking-change review: Breaking changes in a minor release are opt-in, but you still need someone who reads them before enabling them.
- Database and HA testing: Your team must test the database and high availability design it runs, since the project documents supported options but does not test your environment.
- Patch response: Decide who monitors security advisories and how quickly a fix reaches production.
- Vendor option later: Ask Red Hat whether a subscription can be bought mid-life, and whether it supports a migration from upstream at that point.
Write down the internal support hours you expect, and compare them with the subscription terms in writing before deciding.
What each route costs to run and what drives the difference
This table separates the cost components of running upstream Keycloak from those of a Red Hat build of Keycloak subscription, and marks which costs are one-time and which recur. Use it to see where the subscription fee sits next to the installation, database, high availability, upgrade and testing effort that both routes share.
| Cost component | Upstream Keycloak | Red Hat build of Keycloak |
|---|---|---|
| Software license fee | None. Keycloak is licensed under Apache-2.0 and the artifacts come from keycloak.org. | Red Hat subscription fee, provided through the Red Hat customer portal. No published price in our sources; request a quote. |
| Who is paid for the software | No one for the server itself. Costs fall on your staff or a services partner for work done. | Red Hat for the supported distribution, plus your staff or a services partner for the work done. |
| Installation and configuration | One-time. Internal staff or DeployOpen effort under a written, fixed scope. | One-time. Same effort as upstream, plus any migration work if moving from an existing upstream deployment. |
| Database operation | Recurring. You run PostgreSQL 14 to 18, MariaDB, MySQL, Oracle, SQL Server or Aurora, including backups and patching. | Recurring. Same database duties. Confirm which drivers are bundled, since Oracle and SQL Server drivers are not shipped with the Red Hat build. |
| Driver and logging changes | None beyond standard setup. The GELF log handler and bundled Oracle and SQL Server drivers are available. | Possible one-time rework. The GELF log handler is not available, and Oracle and SQL Server drivers must be supplied separately. |
| Upgrades and version matching | Recurring. Minor releases arrive four times a year per the project plan, and each upgrade needs testing. | Recurring. Upgrades track Red Hat release timing, which can differ from upstream. Confirm the support window in the subscription terms. |
| Migration between routes | One-time when moving to Red Hat. Upstream must first be brought to the matching version, or a new deployment is needed. | One-time when moving from upstream. A deployment newer than the current Red Hat build cannot migrate in place. |
| Testing and high availability | Recurring. Multi-cluster or single-cluster designs need a synchronously replicated database and load testing on each release. | Recurring. The same HA and test duties apply, with the added need to confirm supported configurations with Red Hat. |
| What to request in a quote | A written scope covering installation, database, HA design, upgrade cadence, testing and handover. DeployOpen does not publish prices; quotes follow the written scope. | Subscription price per the chosen term and cores or nodes, support level, included versions, and any services for migration and upgrades. Ask Red Hat for the quote. |
Questions buyers ask before choosing Keycloak or Red Hat build of Keycloak
Is upstream Keycloak production-ready for enterprise identity?
Yes, upstream Keycloak is designed for production use, but it is production-ready only when you run a supported database, a tested high availability design and a patching routine. Keycloak documents a relational database as required for production, and its default dev-file database is for development only. The project ships four minor releases a year, and since Keycloak 26.0 it states that breaking changes in a minor release will be opt-in. The practical question is not whether the software is mature but whether your team can own upgrades, monitoring and incident response. Upstream support comes from the community and the project's documentation, so confirm your internal support model before you go live. Review the Keycloak server administration guide and the production configuration guide with your platform team.
Is migrating from upstream Keycloak to Red Hat build of Keycloak reversible?
Treat the migration as one-way unless you have tested a rollback on a copy of your data. Red Hat's migration guide says an upstream deployment on an older version must first be upgraded to the matching version before it moves over. A deployment newer than the current Red Hat build cannot migrate to it and needs either a new deployment or a later Red Hat release. Keycloak also migrates its database schema automatically at startup by default, so a version change can alter the database before you notice a problem. Ask for a written rollback plan, take a full database backup before the cutover, and rehearse the move in a non-production environment that mirrors your realms, clients and federation settings.
Can I add Oracle or SQL Server drivers to Red Hat build of Keycloak?
Red Hat's migration guide says the Oracle and Microsoft SQL Server database drivers are bundled with upstream Keycloak but not with Red Hat build of Keycloak. If your estate runs on either database, confirm with Red Hat whether a supported driver can be added to your Red Hat build and under which support terms. Do not add a third-party driver to a supported distribution without that confirmation, because a change outside the supported configuration can affect your support position. Also check which database versions your Keycloak release supports, since the supported list in the Keycloak database guide differs from what your database team currently runs. Put this question in writing with your Red Hat account team before you choose the distribution.
What replaces the GELF log handler in Red Hat build of Keycloak?
The GELF log handler is not available in Red Hat build of Keycloak, according to Red Hat's migration guide. If your logging pipeline depends on GELF, plan a different route before migration. Common options are to keep Keycloak's standard log output and forward it with an agent your log platform already supports, or to adjust the log stack to accept the format Red Hat provides. Confirm the supported logging options with Red Hat and test that security events reach your SIEM with the fields your detection rules expect. Keep this change in the same test plan as the database and driver checks so that audit visibility does not drop during cutover.
How long does a migration take and what does it need from staff?
The duration depends on your Keycloak version, the number of realms and clients, your database and how many custom extensions you run, so no fixed timeline applies. The work needs staff who can read the migration guide, operate the database, manage the Kubernetes or virtual machine layer and test login flows for each application. Ask the implementer for a written plan that lists the version steps, the test cases and the rollback point. Identify who owns the database backup, who signs off on login testing and who handles the cutover window. Budget internal time for these roles even if an outside partner runs the technical steps.
Can DeployOpen run a Keycloak migration on a fixed scope?
DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A migration scope would typically cover the version path, database checks, driver and logging gaps, realm and client verification, rollback steps and documentation. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the deliverables, the environments involved and the test evidence you will receive. DeployOpen does not issue audit reports or certifications, so any compliance evidence still comes from your independent auditor.
What does a Red Hat subscription not cover?
A subscription covers the supported distribution and Red Hat's support channel for that product, but it does not replace your own operations, testing or change control. It does not change your architecture, choose your database, write your realm design or validate your client integrations. Confirm the exact terms, including which artifacts, database drivers and logging features are in scope, with Red Hat before you sign. Also confirm what happens to your support position if you add components that Red Hat does not ship. Your team still owns backups, monitoring, access reviews and the schedule for applying each release.
When is a Red Hat subscription worth paying for?
A subscription is worth evaluating when your organization needs a vendor-backed support path, a supported build for regulated workloads, or a platform standard that your procurement and risk teams require. It matters less when your team already has strong Keycloak operations skills, a tested upgrade routine and a database and logging stack that the upstream artifacts support. Compare the subscription cost with the internal hours you would otherwise spend on patch testing, incident escalation and driver or logging workarounds. Ask Red Hat for a current price and support terms in writing, since the figures for your region and contract size are not set by this page.
Official sources to check before you decide
Start with the Red Hat build of Keycloak 26.4 migration guide, which is the document that sets out the differences between Red Hat's distribution and upstream Keycloak. Read its section on migrating upstream Keycloak before you plan any move. The guide is where you confirm the matching-version rule: an upstream deployment on an older version must be upgraded to the matching Red Hat version first, and a deployment newer than the current Red Hat build cannot migrate to it. Check the migration guide for migrating upstream Keycloak against the exact version your environment runs, since the guide is versioned and the Red Hat product page lists a newer line.
Next, verify the components your deployment actually depends on. The Keycloak database guide lists supported production databases and confirms that the dev-file database is for development only. Compare that list with the drivers in your build, because the migration guide states that the Oracle and Microsoft SQL Server drivers are bundled with upstream Keycloak but not with Red Hat build of Keycloak. The Keycloak upgrading guide covers schema migration at startup and manual migration for large deployments, so confirm which mode your change process needs. If you rely on GELF logging, the migration guide says that handler is not available in Red Hat build of Keycloak, so test your log pipeline on the supported build.
Use the Red Hat build of Keycloak product page to confirm the current supported version, artifact access and how the distribution is offered. Then check the subscription terms, support scope and renewal conditions directly with Red Hat or your Red Hat account team, because this page does not set out those terms and they can change. Ask in writing which artifacts, support windows and environments a subscription covers, and whether it applies to the containers or operator images you plan to run. Treat the answers as the basis for any decision on paying for a subscription.
How DeployOpen scopes and supports either distribution
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the distribution choice is settled during scoping rather than assumed. Whether you run upstream Keycloak or Red Hat build of Keycloak, the written scope fixes the version, artifacts, database and operating model before any work starts.
How we scope
- Confirm which distribution your organization has chosen, and whether a Red Hat subscription is already in place or under consideration.
- Record the current Keycloak version, target version and the database engine that will hold realm data.
- Check whether your deployment relies on Oracle, Microsoft SQL Server or GELF logging, which affects the distribution decision.
- Agree the scope in writing as a fixed-scope engagement, with deliverables and timelines confirmed before work starts.
How we build
- Match the target distribution version to the existing deployment before any upgrade, following the migration guide for the chosen line.
- Set up artifacts from the source your policy allows, either keycloak.org or the Red Hat customer portal, and record provenance.
- Test realm configuration, identity brokering, LDAP or Active Directory federation and SAML clients in a staging environment.
- Apply database and high availability settings that match the supported architecture, and document any unsupported gaps.
How we hand over
- Deliver configuration, deployment steps and upgrade runbooks written for your own operations team to run.
- Document the distribution-specific differences that affect your deployment, including bundled drivers and logging handlers.
- Record how to confirm supported versions and subscription entitlements with Red Hat and your own change process.
- Provide compliance evidence and control mappings prepared for your independent auditor, without issuing any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial handover is complete.
- Retainers can cover moving between Keycloak minor releases, with manual approval for operator updates where you use the Operator.
- Ask your quote to separate one-time implementation work from recurring support, so subscription and retainer costs stay distinct.
- Confirm with Red Hat which subscription terms apply to your distribution, since DeployOpen is not a Red Hat partner or reseller.
