Ping Identity cost vs self-hosted Keycloak: where the money actually goes
A renewal, an end-of-support version or a licensing change usually triggers this review, and the honest answer is that self-hosted Keycloak removes the Ping subscription and Extended Limited Support lines but adds infrastructure, migration, support and operations costs, so the outcome depends on your own numbers. Keycloak is licensed under Apache 2.0, so there is no license fee to pay for the software itself. The current release is 26.8.1, published October 13, 2026, and the project plans four minor releases a year, which means your operations budget must cover a steady upgrade cadence rather than an occasional major project. Ping's prices are not part of this analysis; take the figures from your own contract and quote.
Split the comparison into one-time and recurring items before comparing totals. One-time costs include discovery and inventory of applications and connections, migration of federation configuration and user stores, testing, cutover and any parallel running period. Recurring costs include infrastructure (compute, database, load balancing, backups, and for high availability a synchronously replicated database), staff time for patching and upgrades, monitoring, and any commercial support subscription you choose to buy from a distributor such as Red Hat. Ask each vendor and partner to price these lines separately so you can see what changes with user count, the number of environments and the skills your team already has.
Ask for quotes that name each component, state what is fixed scope and what is time and materials, and identify which items recur. Confirm your internal skills honestly: a team already running PostgreSQL clusters and Kubernetes will carry a different operations cost than one starting from scratch. Before you decide, check the Keycloak server administration guide and the upgrading guide to estimate upgrade effort against your customizations, and run the Ping cost lines and the Keycloak cost lines through the same three-year model.
Which cost components move when you replace Ping with Keycloak
This table lists each cost component on the Ping side and the Keycloak side, and whether it is paid once or recurs. Keycloak is free under Apache 2.0, so the Keycloak column shows the paid lines that remain: optional Red Hat build of Keycloak or third-party support, plus the internal and partner effort to run it. Ask Ping and your partner for written quotes before comparing totals.
| Cost component | Ping Identity (commercial side) | Keycloak (self-hosted side) | One-time or recurring |
|---|---|---|---|
| Product licensing or subscription | Ping subscription fees for PingFederate, PingOne or the former ForgeRock products, set by your contract | No license fee under Apache 2.0; optional Red Hat build of Keycloak or third-party support subscription | Recurring |
| Extended Limited Support for versions past end of support | Sold separately for versions past their support window, so confirm the fee and term with Ping in writing | Not applicable; Keycloak releases ship on a published cadence that you plan upgrades around | Recurring while the old version runs |
| Upgrade projects | Vendor upgrade or replacement project to a supported PingFederate version, with testing of connections and adapters | Keycloak minor upgrades, planned against release notes; major upgrades need a test cycle and schema migration review | Periodic, recurring over the life of the platform |
| Production infrastructure | Ping-supported deployment hosting, sized to your contract and environments | Servers or Kubernetes capacity, a supported database (such as PostgreSQL 14 to 18), and high availability design in your own cloud or data center | Recurring (hosting) plus one-time (initial build) |
| Migration of users and applications | Export of configuration and identity data, often limited by what the product lets you extract | Import of realms and users, recreation of clients and mappers, and LDAP or Active Directory federation where needed | One-time |
| Implementation | Vendor or reseller professional services, if purchased | Fixed-scope implementation by DeployOpen or another partner, or in-house build, priced from the written scope | One-time |
| Ongoing operations and upgrades | Largely covered by the subscription, plus your own administrators for configuration changes | Your team or a retainer for patching, monitoring, backups, upgrades and on-call support | Recurring |
| Internal skills and training | Vendor certification or training for Ping administrators, where your team needs it | Keycloak administration, Operator use and database operations skills for your staff | Mostly one-time, with refresh training recurring |
What moves the Ping versus Keycloak comparison
Five drivers decide whether a Ping renewal or a self-hosted Keycloak build costs more over time. Each one pushes both sides up or down, so the cost model should be built from the same inventory of applications, directories and availability needs.
Applications and federation connections
Every SAML and OIDC connection, OAuth client and relying party is work on both sides. On Ping, connection count can affect the scope of a subscription or support tier, so ask the vendor how licensing counts connections. On Keycloak, each client is configured, tested and monitored by your team, so a long tail of legacy apps raises operations effort even though the software itself carries no per-connection fee.
User store volume and directory dependencies
Keycloak's built-in user federation connects to existing LDAP and Active Directory servers, so you can often keep the directory you already run. Large user counts and heavy directory lookups raise database and cache sizing on the Keycloak side. Ping's directory dependencies depend on which products and user stores are in use, so confirm them in the current contract before comparing.
High availability and database replication
Keycloak's supported high availability designs both need a synchronously replicated database, which adds database licensing or hosting cost and an operations skill set your team must hold. Ask Ping how its clustering and failover are licensed and supported, and price the replicated database, load balancers and failover testing for your side as recurring infrastructure cost.
PostgreSQL version and database choice
Keycloak supports PostgreSQL 14 to 18 among its production databases, and the choice of database changes licensing and support cost. Check whether your current database platform sits inside that range and whether an enterprise database option is already licensed. Version support, not only the Keycloak release, sets when a database upgrade must be scheduled.
Ping editions and Extended Limited Support years
The number of Ping products in play and how many years a PingFederate version has been past end of support drive the recurring fees. Each extra year of Extended Limited Support or each unplanned upgrade project adds cost that Keycloak avoids only if the migration itself is planned. Ask Ping for the exact support windows and fees for your version, and compare them with a dated Keycloak upgrade plan that your own team can run.
How Extended Limited Support and upgrades change the math
Ping's support lifecycle is the first variable to pin down. Ping's end of life policy gives Long-Term Support and Short-Term Support versions different maintenance windows, and Extended Limited Support is sold separately for versions that have passed their standard window. A buyer still running an aging PingFederate version therefore pays twice in a sense: once in subscription or maintenance terms for the time the version remains in service, and again in upgrade work to reach a supported line. Before comparing totals, ask Ping in writing which version you run, the exact end of its standard window, the Extended Limited Support price and term for that version, and whether the fee applies per instance, per environment or per contract. Ping's current terms should be confirmed directly with Ping, since they can change.
A Keycloak move changes the shape of that cost rather than removing upgrade work altogether. Keycloak publishes four minor releases a year and a major release every two to three years, and its project states that breaking changes in a minor release are opt-in. That makes upgrades a recurring, plannable activity instead of a periodic rescue project. The part that still needs a human decision is the operator. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so you control when a new version reaches production. Plan a staging upgrade, a review of the release notes for any opt-in changes you have enabled, and a rollback path that covers the database schema. Schema migration runs automatically at startup by default, while the upgrading guide suggests manual migration for large deployments, which is a decision to record in your runbook.
For the comparison, cost each upgrade cycle on both sides. On the Ping side, include the Extended Limited Support fee if it applies, the upgrade project effort and any test cycles for connections. On the Keycloak side, include your team's time for the staging upgrade, the support subscription if you buy one from a Keycloak distributor, and the ongoing testing of your own realm configuration. Upgrade effort on Keycloak still drives cost up when you have many custom authenticators, extensions or non-standard client configurations, so inventory those before you build the model. A reasonable exercise is to state the upgrade calendar you would commit to for three years and price both options against it.
How to build the cost comparison with your own numbers
This sequence turns a general comparison into a side-by-side model built from your own application count, federation footprint, user base and written quotes, so both options are priced over the same period. The output is one table that separates one-time costs from recurring costs for each option.
Inventory applications, federation connections and users
Start by listing every application that signs in through Ping, including the protocol each one uses (SAML, OIDC, OAuth 2.0 or WS-Federation), its owner, and whether it is production, staging or development. Add the user populations behind each application, separating workforce users from customers, and note any external partners federated into the platform. Ask the identity team to export the connection list from the current environment, and have application owners confirm it. The step is done when every connection has an owner, a protocol and a user count, and the list reconciles with the Ping configuration.
Collect written quotes for the Ping contract
Request a written quote for the current Ping subscription, covering the product, the licensed scope, the renewal term and the price for the next renewal period. If your version is past its standard support window, ask separately for any Extended Limited Support fees, the period they cover and the conditions attached to them. Record who issued each quote and its validity date. The step is done when every Ping cost line has a document behind it, and any figure you cannot source from a quote is marked as unconfirmed.
Estimate Keycloak infrastructure for each environment
Size the self-hosted platform for each environment, including production, disaster recovery and non-production. Keycloak needs a supported production database; the vendor's database guide lists PostgreSQL 14 to 18 among the options, so price a managed or self-run PostgreSQL service and its backups. Add the nodes for high availability, which depend on the architecture you choose, and note that both supported high availability designs require a synchronously replicated database. Record compute, storage, network, load balancing, and monitoring as separate recurring lines. The step is done when each environment has a costed infrastructure list you can defend.
Cost the migration application by application
Assign effort to each connection from step one, based on its protocol, the number of attribute mappings, custom authentication logic and the testing it needs. Count the cutover work separately, including running Ping and Keycloak in parallel and user data movement from existing directories. Price internal staff time and any external implementation work as one-time costs, and show who is paid for each line. Where you use an implementation partner, request a written, fixed scope before comparing figures. The step is done when every application has an effort estimate and the one-time migration total is shown on its own line.
Decide on the Keycloak support subscription
Decide whether your organization will run Keycloak on community support, buy a vendor-supported distribution, or buy a support contract from a third party. Red Hat's build of Keycloak is one supported distribution based on the open source project, so request its current subscription terms in writing if you consider it. Mark the subscription as a recurring line and show the community-support option at zero licensing cost with the internal support effort it implies. The step is done when the support choice is recorded with its annual cost or its documented assumption.
Model yearly operations and upgrade effort
Estimate the recurring staff effort to operate Keycloak: monitoring, certificate and secret rotation, backups, restore tests, and access reviews of the admin console. Add upgrade effort for each planned release. Keycloak ships four minor releases a year, so plan the test and approval cycle for those, and note that the Operator documentation recommends manual approval for operator updates. Record the same operations effort for the Ping side, including its upgrade projects. The step is done when both options have an annual operations and upgrade line with stated assumptions.
Compare both options over one time horizon
Place both models on the same time horizon, year by year, with one-time migration costs in the first period and recurring costs repeated in each year. Show Ping's contract, any Extended Limited Support fees, and Keycloak's infrastructure, subscription and operations side by side, and check that inflation and renewal assumptions are the same on both sides. Review the result with finance and the identity team, and mark every figure that rests on an unconfirmed quote. The step is done when a single table shows total cost by year for each option and the open questions are listed for the vendor or partner.
What running Keycloak costs in your own infrastructure
The main cost of self-hosting Keycloak is the infrastructure and people that run it, and most of it recurs. Plan for at least two Keycloak nodes behind a load balancer, a production database and a monitoring stack. Keycloak's supported production databases include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL, so the database cost depends on what your organization already licenses and operates. The high availability designs documented by the project require a synchronously replicated database, which makes the database tier one of the larger line items. Confirm your chosen topology with your own architects and price the database, compute and load balancing in your own cloud account or data center, since those costs are yours regardless of who operates the software.
Operations are the second cost. Keycloak exposes metrics for monitoring, and your team needs alerting on them, log retention and a patching routine. If you run the Keycloak Operator on Kubernetes, the Operator documentation strongly recommends manual approval mode for operator updates, which means someone must review and approve each upgrade. Keycloak migrates its database schema automatically at startup by default, but the upgrading guide suggests manual schema migration for large deployments, so your change process needs to decide which approach you use. Backup planning deserves specific attention. Realm export and import with kc.sh export and kc.sh import has documented limitations as a backup mechanism, and the process requires all nodes to be stopped. Plan database-level backups and restore tests as the primary recovery path, and confirm the outage window your business can tolerate.
Support is optional but changes the risk profile. Keycloak is free under the Apache 2.0 license and community support is available through the project. Red Hat build of Keycloak is Red Hat's supported distribution based on the open source project and replaces Red Hat Single Sign-On. Its support is a separate purchase from Red Hat, so ask Red Hat for the subscription terms, support hours, lifecycle commitments and what they cover before you budget for it. Whether you buy that support, a partner's operations retainer or staff in-house, ask every quote to split one-time migration work from recurring operations, patching and on-call coverage.
Questions buyers ask before comparing Ping and Keycloak costs
How much does Keycloak cost compared with Ping Identity?
Keycloak's software is free under the Apache License 2.0, so the comparison comes down to components rather than a license fee. On the Keycloak side you pay for the infrastructure that runs it (servers or cloud capacity, a production database, load balancing across availability zones), the people who operate it, any optional support subscription from a vendor such as Red Hat, and the one-time migration project. On the Ping side you pay the Ping subscription, any Extended Limited Support fees for versions past end of support, and upgrade projects. Ask Ping for a written quote that lists each component, and build your own estimate from the same components so the two sides line up.
How long does a migration from Ping to Keycloak take?
The duration depends mostly on how many applications, SAML and OIDC connections, and user stores you have, and on how many use custom adapters or attribute logic. Start by inventorying those connections and the certificates and clients tied to them, then group applications by risk and by owner. Running old and new identity providers side by side during cutover usually adds time, because each application needs testing before it moves. No general duration applies to every estate, so ask for a timeline only after the scope is written down, and confirm which items are in and out of the agreed work.
Can our internal team run a Keycloak migration without outside help?
Often yes for a small, well-documented estate, but the work needs several skills at once: identity protocols (OIDC, OAuth 2.0 and SAML 2.0), directory and LDAP or Active Directory federation, database administration, container or Kubernetes operations, and security review of certificates and client settings. Check whether your team has these skills in-house, who will own the platform after cutover, and how much time they can give during a live migration. If gaps exist, a fixed-scope engagement can cover the planning, implementation, hardening and documentation while your staff take over operations.
Do we need a Keycloak support subscription to run it in production?
No. Keycloak is free to use in production under Apache 2.0 without a subscription. A support subscription, such as the Red Hat build of Keycloak, changes the risk profile rather than the software: it adds a vendor's support commitments, security fix delivery for the distribution and a formal escalation path. Whether that is worth its cost depends on your internal expertise, your regulatory expectations and how quickly you need help during an incident. Ask any vendor exactly which versions, fixes and response terms the subscription covers before you assume it.
What does Ping's Extended Limited Support actually cover?
Extended Limited Support is a paid option for PingFederate versions that have passed their standard maintenance window, and its terms determine what you receive, such as which fixes and which severities. Because the terms are specific to your contract and the Ping lifecycle policy, confirm in writing with Ping what the extension includes, how long it runs, what it excludes and what it costs. Then compare that continued spend with the one-time cost of upgrading or moving to Keycloak, using the same time horizon for both options.
Does upgrading Keycloak create recurring costs?
Yes, but the work is predictable if you plan for it. Keycloak plans four minor releases a year and a major release every two to three years, and breaking changes in minor releases are opt-in. Recurring effort covers testing each target version in a non-production environment, applying updates, reviewing the upgrading guide and, for Kubernetes deployments, managing the Operator. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, so decide who approves each change and build that step into your change process.
Who pays for security testing of a self-hosted Keycloak deployment?
You do, whether the work is done internally or by an outside firm. Security testing of applications, APIs, infrastructure and the identity platform is a separate line item that Keycloak's license does not include. DeployOpen runs security testing as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts, and it can continue testing under a retainer. Ask any provider for the written scope, the systems covered and the deliverables. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do that work.
When staying on Ping still makes sense
Some organizations should keep Ping for now, and a cost comparison that ignores their constraints will point them the wrong way. The clearest case is a federation estate that depends on WS-Federation and WS-Trust. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, but it does not cover WS-Federation relying parties, so a PingFederate deployment that still serves Microsoft-style WS-Federation consumers carries a protocol requirement that a Keycloak move cannot satisfy on its own. Before estimating any saving, inventory every connection and record its protocol, because a single WS-Federation dependency changes the migration from a per-application cutover into a platform decision. The sibling page on PingFederate versus Keycloak sets out protocol coverage, connection management at scale and clustering, and the page on migrating from PingFederate to WSO2 Identity Server covers the path for organizations that need WS-Federation alongside SAML and OIDC.
Contract terms and timing can also make staying the sensible short-term decision. A subscription that runs past a planned cutover date, or an upgrade already funded for a supported version, changes the arithmetic of a migration. Ask Ping for the exact support window, the entitlements in the current agreement and any Extended Limited Support terms in writing, and confirm them against Ping's published end of life policy rather than relying on a summary. Ask whether the license file and configuration archive can be exported in a usable form before you commit to a parallel run. Where Ping is kept for a defined period, document an exit date, the owner of that decision and the controls that remain in force, so the retained platform is a planned position rather than an open-ended default.
Keeping Ping is still a deliberate choice that should be reviewed, not a permanent answer. Revisit it when the protocol inventory changes, when the contract approaches renewal, or when a supported Keycloak release covers the remaining applications. DeployOpen can help plan that review as a fixed-scope assessment of the connection inventory and cost components, and the outcome may be a recommendation to remain on Ping for specific applications while others move.
How DeployOpen scopes a fixed-price Keycloak implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Ping Identity to Keycloak, we start from a written scope that separates license spend, upgrade work and operating effort, so you can compare the options on the same terms.
How we scope
- Inventory the Ping subscription, support terms and any Extended Limited Support obligations before estimating anything.
- Agree in writing which applications, protocols and user stores the Keycloak implementation covers.
- Confirm high availability, database and backup requirements for your own data center or cloud account.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Deploy Keycloak in your environment on a supported production database such as PostgreSQL.
- Rebuild clients, identity brokering and user federation with existing LDAP or Active Directory servers.
- Test each application's login, logout and attribute flows against a parallel instance before cutover.
- Harden configuration for production and wire up metrics and logging for your monitoring stack.
How we hand over
- Document the realm design, client inventory, upgrade procedure and backup and restore steps for your team.
- Walk your administrators through the operator's manual approval process for Keycloak updates.
- Provide a migration record listing each Ping connection, its Keycloak equivalent and its cutover status.
- Prepare controls and evidence for compliance assessments; independent auditors issue any audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan Keycloak minor-release upgrades against the project's published release cadence and your change windows.
- Ask any provider, including us, to confirm support scope, response terms and who is paid for each activity.
- Request a quote that follows directly from the written scope; DeployOpen does not publish a price list.
