What drives the cost of running Keycloak yourself
A cost of ownership study for a self-managed Keycloak deployment answers one question: what will it cost to run the identity service for its full life, not just what the software costs. Keycloak is licensed under Apache 2.0 and the community project carries no license fee. The alternative to weigh is the Red Hat build of Keycloak, Red Hat's supported distribution that replaces Red Hat Single Sign-On, which is sold as a subscription. Confirm the subscription price, support terms and the product versions covered directly with Red Hat or in a written quote. Either way, the software choice is one line in the budget.
Most cost studies start when a specific event forces the decision: a new identity platform for several applications, an exit from a hosted identity service, renewal of an existing Red Hat Single Sign-On subscription, or a board or audit request for a documented cost case. In each case the study has to cover infrastructure for the cluster, a supported production database, high availability design, monitoring, backups, upgrade effort and the internal team time to operate it. Build the model from your own figures, not from a generic estimate. The short answer is that most teams build the cost model with a partner or an internal architect, then run the platform in-house.
The recurring items are where the model usually goes wrong. Each Keycloak minor release arrives roughly four times a year, so upgrade testing, reading upgrade notes and applying database migrations is a standing workload. Database choice drives both licensing and staffing: Keycloak supports several production databases, and an enterprise database may carry its own license. High availability needs a synchronously replicated database, which adds cost to the data tier. Ask each cost to be shown as one-time or recurring, and ask what each line assumes about environments, staff hours and support coverage.
What the cost work includes
A cost of ownership engagement produces five written deliverables. The cost model they feed is an input to a fixed-scope proposal, not a substitute for a quote from Red Hat or from a service provider.
Realm, client and directory inventory
We count and classify the realms, OIDC and SAML clients, user populations and federated directories (LDAP, Active Directory, brokered identity providers) that the platform must carry. Counts drive database size, cache load, support scope and the effort to migrate or upgrade. Confirm which realms are production, which are retired, and which users are service accounts.
Community versus Red Hat build comparison
We compare community Keycloak, licensed under Apache 2.0, with the Red Hat build of Keycloak, which Red Hat supports and which replaces Red Hat Single Sign-On. The comparison covers release cadence, support terms, patch delivery, and who answers for defects. Ask Red Hat to confirm the subscription terms, supported platforms and version currency in writing.
Sized reference architecture
We draw a reference design covering the production database, the Keycloak cluster, load balancing, metrics and log collection, and backups. Each component is sized from the inventory and the availability target. The design states which database engines Keycloak supports for production, and which HA pattern and synchronously replicated database the chosen model requires.
One-time versus recurring cost register
We list every cost by owner and by timing. One-time costs include design, build, realm migration, theming and testing. Recurring costs include infrastructure, database licensing or support, subscriptions, monitoring, backups, upgrades and on-call time. For each line, we note the factors that raise or lower it, such as cluster size, environments and upgrade frequency.
Quote request checklist
We produce a written list of items to request from Red Hat and from any service provider, so quotes can be compared on the same basis. Typical items include supported versions, subscription term and tiers, response times, upgrade and patch support, operator and database support, and what is excluded. Each quote should also state its assumptions about environments and cluster topology.
What drives cost and duration
This table lists the main Keycloak cost and effort drivers, why each one moves cost or time, how to reduce it, and the documentation point behind it.
| Driver | Why it changes cost | How to keep it down | Documentation point |
|---|---|---|---|
| Edition and support level | The community build has no license fee. The Red Hat build adds a subscription and vendor support terms. | Confirm support scope and version coverage in the written quote before choosing an edition. | Apache 2.0 license; Red Hat build of Keycloak product page |
| Number of realms and clients | Each realm and client adds configuration, testing, and upgrade review work. | Keep realms to true isolation boundaries and reuse client templates across applications. | Organizations feature in the server administration guide |
| User count and directory federation | Larger user stores increase database and cache sizing. LDAP or Active Directory federation adds mapper and sync work. | Federate read-only where possible and keep the directory as the source of truth. | LDAP and Active Directory user federation in the server administration guide |
| Database platform and licensing | Production needs a supported database. Commercial engines add license fees and DBA time. | Use a database your organization already licenses and operates, such as PostgreSQL 14 to 18. | Supported production databases list in the Keycloak database guide |
| High availability design | Both supported designs need a synchronously replicated database, and multi-cluster adds operational effort. | Start with one cluster across availability zones unless a separate site requirement exists. | Three high availability architectures in the high availability overview |
| Number of environments | Each environment repeats installation, realm configuration, and test cycles. | Manage realms and clients as code and promote the same definitions through each environment. | KeycloakRealmImport and KeycloakOIDCClient resources in the Keycloak Operator docs |
| Monitoring and log retention | Metrics and log storage add monitoring setup, alert tuning, and retention cost. | Reuse your existing Prometheus and log platform and set retention by written policy. | Metrics at /metrics in the Keycloak observability guide |
| Customization such as themes and SPIs | Custom themes and SPI extensions must be retested at each release and can need rework. | Prefer built-in flows and configuration, and limit custom SPIs to documented needs. | Upgrading guide; minor releases can carry opt-in breaking changes |
| Internal identity and application skills | Without in-house Keycloak skills, partner time or training absorbs the build and run work. | Name owners for realms, upgrades, and on-call before go-live, and confirm skills in the quote. | Server administration guide and upgrading guide |
How a cost model is built
The cost of ownership work moves from what you run today to a costed, reviewed register and a quote request you can send to vendors and partners.
Inventory applications, realms and identity sources
We list the applications that will sign in through Keycloak, planned and current, and map each to a realm, client type and identity source such as LDAP, Active Directory, social providers or an existing identity service. You keep a dated inventory that shows which realms exist, which are planned, and which directories must stay the source of truth. The step closes when your application owners have confirmed each row.
Choose the database and high availability design
We compare the supported production databases in the Keycloak database guide against your existing database standards, then select a high availability architecture from the options Keycloak documents. Both supported designs require a synchronously replicated database, so this choice drives licensing, hosting and operations cost. You keep a written architecture decision record listing each component, its hosting location and who operates it.
Decide on edition and support
We set out the trade-off between the community Keycloak project, which is open source under Apache 2.0, and the Red Hat build of Keycloak subscription, which is Red Hat's supported distribution. We record what support terms you need, how quickly you must receive security fixes, and who will carry upgrade testing. You keep an edition decision memo that states the support assumptions behind every recurring line.
Build the cost register
We enter every cost line in a register with one-time items such as design, initial build, testing, data migration and integration, and recurring items such as infrastructure, database, monitoring, subscriptions, support and the internal team time to run and upgrade Keycloak. Each line names the cost driver, such as application count, realm count or number of environments. You keep a spreadsheet or model that finance can change without rebuilding it.
Review with finance, security and platform owners
We walk each owner through the register and the assumptions behind it. Finance checks the recurring lines and the timing of one-time spend, security checks hardening, audit logging and upgrade cadence, and platform owners check hosting, monitoring and on-call load. Timing depends on the size of the estate and on how many owners must review it. You keep a signed-off register with each owner's open questions logged and resolved.
Assemble the quote request pack
We turn the reviewed register into a quote request pack: scope, assumptions, environments, applications and realms, database and high availability choice, edition, and the questions each vendor or partner must answer in writing. The pack asks for line-item pricing, the terms that apply to recurring support, and any upgrade or update effort included. You keep one document that lets each respondent quote against the same baseline.
One-time and recurring costs
This table splits the cost of a self-managed Keycloak deployment into one-time and recurring lines, shows who pays for each under a self-managed model, and lists what to request in a quote.
| Cost line | Who pays under self-managed | One-time or recurring, and what drives it |
|---|---|---|
| Discovery and architecture | Your organization, or a partner you contract under a written scope | One-time. Driven by the number of realms, applications, user sources and availability targets. |
| Initial build and import | Your organization, or a partner you contract under a written scope | One-time. Driven by custom themes, authentication flows, client count and whether users are migrated or re-registered. |
| Load and failover testing | Your organization, or a partner you contract under a written scope | One-time for the first design, then recurring at each significant change. Driven by the HA design and the target session volume. |
| Operator or Helm setup and runbooks | Your platform team, plus any partner time for initial setup | One-time build, with recurring upkeep for each operator or chart update. Driven by your cluster model and approval process. |
| Infrastructure for production and non-production | Your cloud account, data center or hardware budget | Recurring. Driven by node count across availability zones and by how many non-production environments you keep. |
| Database licensing or hosting | Your database team or cloud account, unless a managed service is chosen | Recurring. Ask whether the quote or your plan covers the database license, and who operates it. |
| Red Hat build of Keycloak subscription | Your organization, paid to Red Hat if you choose that edition | Recurring where chosen. Ask what support hours, response scope and upgrade assistance the subscription includes. |
| Backups, monitoring tooling and security patching | Your platform and security teams, plus any tooling licenses | Recurring. Driven by retention rules, metrics volume and how often security releases must be applied. |
| Upgrade testing and internal staff time | Your identity and application teams, plus any retainer you agree in writing | Recurring. Keycloak plans four minor releases a year, so driven by test realm coverage and the upgrade notes you must review. |
Where cost models usually go wrong
These errors show up repeatedly in Keycloak cost estimates. Each card names the mistake and the step that prevents it.
Assuming community Keycloak needs no support
Community Keycloak is licensed under Apache 2.0, so there is no license fee, but someone still owns patching, upgrades and incident response. Budget internal engineering time or an external support contract. If you need a vendor subscription, compare the Red Hat build of Keycloak against your own staffing, and ask each option what it covers and how fast it responds.
Leaving out the database and its replication
Keycloak keeps realms, users and sessions in an external database, which is often missing from the estimate. Include database licensing if you choose a commercial engine, hosting, backups and restore tests. Both supported high availability designs need a synchronously replicated database, so price the standby capacity and the low-latency links between sites or zones.
Sizing one cluster and skipping staging
A cost model that prices only the production cluster leaves no place to test realm changes, upgrades or operator updates. Price a staging environment with a production-like database, network paths and identity provider connections. Estimate its hosting cost and the effort to refresh it from production data while meeting your personal data rules.
Ignoring four minor releases a year
Since Keycloak 26.0, the project plans four minor releases a year, and breaking changes in a minor release are opt-in. Each release still needs upgrade notes read, a test run against your realms and clients, and a production change window. Budget that recurring testing effort as a standing cost, not as a one-time upgrade project.
Building on the deprecated multi-site feature
The multi-cluster v1 design uses a separate Infinispan cluster per site and is deprecated. The Keycloak 26.8 upgrade notes recommend moving to the stateless feature. Ask any design or quote to use the supported option, and if an existing deployment depends on multi-site, price its migration as a planned project with its own testing.
Not counting staff time for operations
Monitoring, backups, certificate renewals and periodic access reviews take ongoing staff time that many models omit. Map each task to a role, such as platform, security or identity administration, and estimate the hours per month. Compare those hours with what your team can absorb before you decide between internal operation and a retainer.
How the cost changes by starting point
Moving from a hosted identity service usually shifts spend from a recurring service fee to infrastructure, database, operations and migration effort. Keycloak itself is licensed under Apache 2.0, so the software line drops to zero, but you pay for everything the vendor previously ran.
- Falls: the hosted per-user or per-tenant subscription, which ends at cutover. Ask the vendor for the notice period and any overlap charges.
- Rises: hosting, a synchronously replicated database for high availability, monitoring and staff time for on-call.
- One-time: password hash handling. Confirm with the vendor whether password hashes can be exported and in what algorithm. If they cannot, plan for password reset or a staged migration.
- Recurring: upgrades. Keycloak plans four minor releases a year, so budget review time for each one.
- Bridge cost: identity brokering lets you run the old service and Keycloak side by side while applications cut over.
Moving from Red Hat Single Sign-On or an older WildFly-based Keycloak changes the licensing line and the upgrade path more than the hardware. Red Hat build of Keycloak replaces Red Hat Single Sign-On, and its product page showed version 26.6 as the latest.
- Falls: the Red Hat subscription if you move to community Keycloak. Support then comes from your team or a partner, so its cost moves to a different line.
- Rises: upgrade effort. Confirm with the upgrading guide which source versions can move directly to the current release, and how many steps are required.
- Database: Keycloak migrates the schema at startup by default. For large deployments the upgrading guide suggests manual migration, which adds DBA time.
- HA: if the old deployment used multi-site v1 with a separate Infinispan cluster, the 26.8 notes recommend moving to the stateless feature. Budget that redesign.
- Ask the vendor: the Red Hat subscription price and term, and whether the support scope matches your current contract.
A new deployment on virtual machines puts most of the cost in infrastructure you already run and in people who patch it. Costs depend on how many nodes you need for your availability target and on the database you choose.
- Infrastructure: VM count, load balancer and reverse proxy. The production guide calls for TLS on all communication and a reverse proxy with path restrictions, and it expects the admin console and Administration REST API on a separate hostname or path.
- Database: supported production databases include PostgreSQL 14 to 18 and several commercial options. The high availability designs need a synchronously replicated database, which usually raises the database line.
- Monitoring: enable metrics with --metrics-enabled=true and scrape /metrics on the management interface. Plan a Prometheus or equivalent stack.
- People: OS patching, Keycloak upgrades and certificate renewal recur every month or quarter.
- Confirm: VM sizing, licensing for the OS and hypervisor, and backup retention with your infrastructure team.
A new deployment on Kubernetes with the Keycloak Operator moves cost toward cluster capacity and platform skills. The operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources, which reduces some manual work but adds a dependency on the cluster.
- Falls: manual configuration of clients and realm imports, since these become custom resources in version control.
- Rises: cluster capacity if no cluster exists, and platform engineering time to run Operator Lifecycle Manager, the recommended install method.
- Recurring: operator updates. The operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades. Budget review time for each approved update, including a test realm run first.
- Install options: the Helm chart is experimental, so plan around OLM or kubectl.
- Confirm: cluster hosting fees, storage class costs and whether your platform team already runs the database that Keycloak will use.
An air-gapped or restricted network raises the cost of getting software, updates and evidence into the environment. Most of the increase is in build, transfer and testing work that a connected deployment does not need.
- Rises: an internal artifact pipeline for images, operator bundles and Maven or other dependencies, plus a process to move each release across the boundary.
- Recurring: four minor releases a year, each requiring an offline transfer, a test cycle and an approval record.
- Limits: social providers and some external identity providers may be unreachable, which removes some brokering options. Confirm the network paths your sign-in flows need.
- Mail: version 26.8 enforces StartTLS for SMTP with no plaintext fallback, so the internal relay must support it. Confirm this with your mail team.
- Subscriptions: confirm with Red Hat how an offline subscription and updates are delivered, if you choose the Red Hat build.
What you need to provide
Your inputs decide most of the cost model for a Keycloak deployment, so collect them before any quote is requested. Start with an inventory of applications, the realms you plan to run, and the clients each realm will hold, whether OpenID Connect or SAML 2.0. Each client adds configuration, testing and cutover effort, and each extra realm adds its own administration and upgrade testing.
Next, provide current user counts, the directory sources that hold identities today (for example Active Directory, LDAP, or a hosted identity service), and whether those sources remain the source of truth. User volume and federation mode determine database sizing, sync design and how much work a directory integration needs. Ask whether any users must be migrated rather than federated, since that changes both one-time effort and the password hash handling questions covered elsewhere on this page.
Give your target availability and recovery expectations in writing, including how long sign-in may be unavailable and how much session or configuration data you can afford to lose. These figures drive the high availability design, the number of nodes, the synchronously replicated database requirement and the failover testing you will pay for. Also name the database platform standard you already operate, since Keycloak supports several engines and an existing supported standard usually lowers the recurring cost of support and backups.
Confirm hosting constraints (data center, specific cloud accounts, or air-gapped networks), compliance and audit obligations, and any existing Red Hat or other vendor agreements. A subscription you already hold may change the Red Hat build of Keycloak comparison, and an audit obligation may add evidence and logging work. Name owners for identity, platform, database and security, and have the final register approved by the identity lead, the platform owner and the information security function, with procurement signing off on any vendor terms.
Common questions about Keycloak cost and editions
Is community Keycloak free to run in production?
The software is free to use under the Apache 2.0 license, which covers the Keycloak code itself. Running it in production still carries cost. You pay for the servers or cloud capacity, the production database, load balancing and high availability, monitoring, backups, and the staff who install, configure, patch and support it. These costs apply whether you use community Keycloak or a subscription build. A cost model should list each of them separately so the licence line does not hide the rest of the total.
How does the Red Hat build of Keycloak differ from community Keycloak?
The Red Hat build of Keycloak is Red Hat's supported distribution based on the open source Keycloak project, and it replaces Red Hat Single Sign-On. The main difference is that you buy a Red Hat subscription for vendor support and a supported build. Compare the subscription against the total cost of running community Keycloak, including your own support capacity, not against zero. Confirm the subscription tier, support hours, included versions and how it is priced for your environments with Red Hat, since prices are published by the vendor and not by DeployOpen.
How long does a Keycloak cost study take?
Timing depends on scope, so there is no fixed duration. The main variables are the number of realms, applications and directory sources to inventory, how many environments you run, whether you need a high availability design, and how quickly your team can answer questions and review drafts. The implementation plan and cost phases describe the work in order, and the written scope sets the timeline before work starts.
What do we need to provide for a Keycloak cost model?
A useful model starts with facts from your environment. Prepare a list of applications and their sign-in methods, the expected user count and growth, directory sources such as LDAP or Active Directory, target hosting and database platforms, required availability, environments such as development, test and production, and your current support and on-call arrangements. Also share any existing Red Hat or other vendor agreements. Missing inputs usually become assumptions in the model, so state them in writing.
Can an internal team build a Keycloak cost model alone?
Yes, if the team has someone who understands identity architecture, infrastructure pricing and the staffing reality of running the service. The harder parts are usually the recurring items: upgrade effort across four minor releases a year, operator or database maintenance, and on-call coverage. Many teams validate their draft with an outside reviewer who has seen similar rollouts, which helps catch missing cost lines.
Which recurring Keycloak costs grow with users or environments?
Costs that scale include compute for the Keycloak nodes and load balancers as sign-in volume rises, database capacity and backup storage, monitoring data retention, and the number of non-production environments you copy from production. Staff time also grows with the number of realms, clients, identity brokers and federated directories. Ask how each item changes at your expected user count, and model the largest and smallest cases.
What should we ask for in a Keycloak cost quote?
Ask for a written scope that lists applications, realms, environments, directory integrations and the high availability design. Request one-time costs separately from recurring costs, with each line naming who pays for what, such as infrastructure, database licensing, the Red Hat subscription or DeployOpen services. Also ask what assumptions the quote depends on, which items are excluded, how upgrades and support are billed, and what changes would reprice the work.
How DeployOpen scopes and supports Keycloak cost work
DeployOpen works out Keycloak cost of ownership from a written scope that names the editions, database, high availability design, monitoring and staff effort involved. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Each engagement starts with a written scope that lists the Keycloak edition, realms, clients and directory sources in use.
- We map the database choice, high availability design and monitoring stack so that infrastructure costs are listed line by line.
- The scope separates one-time work from recurring items such as upgrades, database operations and internal staff time.
How we build
- We deploy Keycloak in your own cloud accounts, data centers or air-gapped networks, using the database and high availability design agreed in scope.
- Each cost component, including Operator or container platform effort, is traced to a deliverable so the quote can be checked against it.
- We test the environment against the sizing assumptions, so the cost model reflects measured behavior rather than estimates alone.
How we hand over
- Handover includes documentation of the deployed architecture, the components that carry recurring cost, and the upgrade responsibilities.
- Your team receives a cost register that records licenses or subscriptions, infrastructure, database and monitoring items with their owners.
- We walk your operations staff through the runbooks for upgrades, database migrations and metrics alerting before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the written scope.
- Retainer scope can cover reviewing each Keycloak minor release and its upgrade notes before your production upgrade window.
- Ask in any quote whether support, subscription terms and upgrade testing are included, and how each is billed.
