Some dust has settled. The Keycloak team has already managed to release the first version of their new creation with fixes. We even have version 18! Keycloak.X has become a fact.
We implement IAM solutions based on Keycloak at our customers’ sites every day. For our implementation and development teams, this change was eagerly anticipated. Why? The configuration of Keycloak based on WildFly is highly complex. The resource requirements are also disproportionately high relative to the functionality offered. And the lack of native cloud support complicates some deployments.
So let’s take a look at the key changes.
Quarkus – the new heart of Keycloak.X
The most important, most often mentioned, but also most awaited by many changes was replacing WildFly with Quarkus. Why does this change arouse so many emotions? Because Quarkus natively supports the cloud (to be precise, it supports Kubernetes, but every public cloud has it). It’s a key change that will obviously make it easier to implement Keycloak-based IAM.
👇 Call us for a free consultation! Choose a convenient date!👇
What else will the new version of the framework give us? It will obviously make configuration easier. Configuration of many features on WildFly was very demanding and thus time-consuming.
Quarkus makes it more flexible, uses fewer resources, and significantly speeds up compilation time, which makes the deployment process much faster.
Changing to Quarkus also means a number of optimizations of Keycloak, including its startup, which takes a few seconds. And as we know from our previous experience with our various customers, some major instances take much longer than a few seconds to start. The time increment was also examined by the Keycloak developers themselves:
Also note the significantly lower memory consumption. This translates into lower operating costs.
Offline session lazy load
Until now, all offline sessions were loaded into Keycloak at startup time. We then had to deal with high RAM usage right from the start. The management of offline sessions has been rebuilt so that they are currently fetched from the database on the fly. That is a very important change in terms of maintaining Keycloak clusters.
Keycloak’s engineers have been refreshing both the administration panel and the user account panel at every opportunity for some time now. Version 18 brought a lot of changes, especially to the latter, got for example a very nice looking view of devices:
Keycloak based on WildFly is inherent standalone and standalone-ha files. The plethora of configurations, reading WildFly documentation – this is what passes. With the arrival of Keycloak.X, we no longer find the above files, we have a more modern and clear keycloak.properties file. Currently, it looks like this:
It definitely looks more readable than the standalone files! 🙂
We have Keycloak on WildFly – what to do? How to live?
Firstly, do not panic.
Secondly, think about whether your organization has human resources capable of migrating Keycloak to Quarkus. If not – contact us. During a free consultation, we will suggest what to do and in what order. We will also estimate the migration work.
Is it worth migrating to X? It is definitely worth it. Not only for the reasons I have already mentioned above. Keep in mind that not migrating to a higher Keycloak version will result in a lack of updates over time, which is definitely not recommended for IAM class systems.
👉 If you would like to schedule a free consultation on Keycloak-based solutions, then follow this link and select a convenient date 🙂