So far, the "cache" implementation is tied to Infinispan. It's hard for me to see support for other cache solutions.

Here, you have the Cassandra implementation [1] with some sort of custom cache - I haven't tried it.

[1] https://github.com/opdt/keycloak-cassandra-extension/

We are seeing quite the issues with Infinispan scaling, we saw it bring down the performance of keycloak up to levels that can be considered downtime. I wonder:

1. what advantage having an externalized infinispan cluster would bring
2. how many classes we would have to implement to replace infinispan with Redis? I see a load of them for Infinispan

It really isn't Infinispan that is the problem, so switching to Redis is not going to make any magical improvements. One of the issues is Keycloak requires sync replication of caches, which is why we can't support multi-region with bigger latency between the sites. Same applies to the database by the way.

It would be a considerable amount of work to make Keycloak work with Redis; at the end you'd get the same behaviour pretty much. Maybe even worse.

We are seeing quite the issues with Infinispan scaling, we saw it bring down the performance of keycloak up to levels that can be considered downtime.

@rLitto - Thank you for reaching out. We recently tested Keycloak with up 2k logins and 10k refreshes per second, and delivered good response time, see https://www.keycloak.org/2025/10/keycloak-benchmark.
Still your scenario might be different. As this is about "Redis Cache Support" which is trying to do technical changes, we could either hijack this discussion to dive deeper into the problems you are seeing including their context. Or we can start a new discussion.

Please start with describing your business needs, with numbers how you want it to scale, the behavior you want to see together with the version you are using, and the problematic behavior you see today.

Why scenarios matter: We've seen situations where users updated the realm a lot (which was a misuse), and this then cleared the caches, which slowed Keycloak down. And then another issue where the feature dynamic client registration cleared the caches (which was a bug, #42922). So even if we would have used something else for caching in those cases, it wouldn't have changed the results.

It really isn't Infinispan that is the problem, so switching to Redis is not going to make any magical improvements. One of the issues is Keycloak requires sync replication of caches, which is why we can't support multi-region with bigger latency between the sites. Same applies to the database by the way.

It would be a considerable amount of work to make Keycloak work with Redis; at the end you'd get the same behaviour pretty much. Maybe even worse.

Hi @stianst, thanks for the reply. Is anyone working on making Keycloak to be multi-region? Is that on the roadmap? If not, how can I help to make it multi-region?

We're not actively looking at supporting multi-region at this point; it's a pretty hard problem to solve and at the same time there's not a huge demand for it.

We've been thinking about two different general approaches though;

• Disconnected and synced clusters across regions - where there is some form of a cluster manager that coordinates the syncing between clusters - this approach provides the benefit that there is no need to deal with replication of the database across the regions - an another benefit here is that the clusters would be more independent of each other
• Support async replication both for Infinispan and DB layer

In general though there's a lot to consider when it comes to conflict resolution; for example what happens if a client is updated in both clusters at the same time? what if a user changes their password then falls over to the different region before the replication? Quite a lot of corner-cases to think through for it to fully work.

Just for the reference, here are the Multi Cluster docs: https://www.keycloak.org/high-availability/multi-cluster/introduction

I think the most problematic is the database. Assuming you can figure out a Multi Site DB deployment, the second step is to use Infinispan Cross Site replication.

Hey @Anoopgopi

I, personally, have no objections to a Redis implementation, but your suggestion seems the hardest path to follow. Creating a new SPI/Provider and changing all the internals to use it is very disruptive and time-consuming.

When I replaced the clustered Infinispan with an external Infinispan cluster, I only had to implement a handful of providers. The interface is already simple enough; get, store list... You can see the code below.

https://github.com/keycloak/keycloak/tree/e40c5de050a44a29dee3d9dc0e95ef543b874cd0/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/remote

https://github.com/keycloak/keycloak/tree/a2c1055f8df21b53b969f922fb9a044a76d22604/model/infinispan/src/main/java/org/keycloak/cluster/infinispan/remote

I would start here: create a new Maven module and start implementing those Providers. Infinispan supports RESP 3 protocols, so even the changes in the testsuite would be minimal, as a "redis" server is already available. This is my personal opinion on where I would start if/when asked to do it.

About consistency, eventually-consistent is not supported by Keycloak; if you have a one-time token to use, the storage has to ensure it is only used once, for example. Infinispan supports async replication between regions, but Keycloak logic cannot use it.

Looking forward to hearing everyone else's opinions.

@Anoopgopi - thank you for reaching out about asynchronous setups:

The "Disconnected and asynchronously synced clusters across regions" is something that IMHO first needs to be solved on the logical layer, and the answers might depend on the specific protocols that Keycloak supports.

Some examples:

• OpenID Connect Authorization Code flow: When there is a code-to-token exchange, what do we do if the token is not known to the cluster where it is received?

• OIDC token refresh: When the user session is not known in the cluster, what do we do?

• When we run an authentication session, is that bound to a single cluster, or do we replicate it?

• When you log out, do we wait until all cluster received the logout, so none of the clusters will refresh a token once the request completes?

• How do we resolve conflicts after a broken communication between the clusters is re-established?

Infinispan supports asynchronous replication, but due to those cases above we haven't worked on it.

On a another note: A multi-region deployment is no disaster recovery / business continuity plan. If you are as big enough for a multi-region deployment, you would want to have such a setup anyway in place.

It would be good if someone would describe and quantify the business value added by a multi-region deployment, beyond the technical ask of "I want Redis". From that business value added definition, we could then figure what is replicated between the regions.

If someone would state "I want to have a low latency for my users by being present in multiple regions", maybe we come to the conclusion that we only replicate users and their credentials, and user sessions including tokens only live in one region for each application in that region.