Keycloak.X: General feedback

[stianst]

We would love general feedback on our plans around Keycloak.X.

[heidelmeier-weclapp]

Thank you all for this update! We definitely belong to use-case "SaaS" and are very interested in the storage changes, which will hopefully remove the limit on number of realms.

[stianst]

The limitations on number of realms will for sure go away, we're also looking at some form of multi-tenancy/customers within a realm. Details on that is still to be worked out though, so stay tuned.

[mxab]

multi-tenancy/customers within a realm

This would be a really nice feature

[mandree95]

Thank you for the news regarding Keycloak.X. One problem with the current Keycloak distribution is that zero downtime upgrades are not possible. Is there any information yet if and how zero-downtime upgrades are possible in Keycloak.X? In the blog post, this item appeared under Storage re-architecture.

[stianst]

Zero-downtime upgrades will be available in the new storage as mentioned in the blog post, which also mentions the roadmap for that.

[adamzr]

We're very excited about Keycloak X! We're running Keycloak in Kubernetes now, and we've run into a few problems.

I have a wishlist of Keycloak features around running in Kubernetes:

• Good handling of "startup order". Right now if Keycloak starts up before my database, Keycloak gets stuck in a bad state. Keycloak X should use cloud-native and follow 12 factor principles.
• Good handling of "dependency failures". If the database goes down or changes IP address, Keycloak should either handle it, or it should report its liveness check as a failure, so that Kubernetes restarts it.
• Liveness and readiness endpoints should be provided
• We should be able to supply a theme without extending the Docker image.
• We should be able to define all of our configuration: realms, clients, roles, etc. with Kubernetes CRDs
• A Kubernetes Operator - it could manage those CRDs and handle things like upgrades
• Frequent updates of the Docker image when there are issues with dependencies. The Keycloak image should always pass scans from tools like trivy.
• The Keycloak docker image should be signed
• Keycloak should work with CockroachDB (right now it mostly works with minor modifications to the migration scripts, but I'd like support for retryable transactions).
• Support for Prometheus metrics should be built-in. Including configurations for alerting.

I don't want these to sound like complaints. We're happy with Keycloak in general. And it sounds to me like Keycloak X will help with most of these issues.

Thanks so much!

[elmarx]

Hi,

Providing a theme without extending the Image is possible. Basically you mount an empty volume into keycloak's theme-folder and fill it via init-container. See the Codecentric Keycloak Helm-Chart for an explanation.

[fidgi]

Hi,

We're very keen to move to Keycloak.X distribution but IMHO there is a lake of a comprehensive documentation on how to migrate (e.g. how to convert custom startup cli that manipulate Wildfly xml-based configuration files) ?

Regards,

[stianst]

Could you provide some more details on what you're thinking about? In general it will be very hard to provide any direct migration as everything is configured very differently. In addition Keycloak.X aims to be significantly easier to configure and have much better and opinionated defaults.

[fidgi]

Hi,
Today we have the following kind of cli to configure keycloak:

• A cli to disable theme caching in dev mode
• A cli to setup http client to enable connection through a corporate proxy
• A cli to configure logging subsystem (level, pattern ...)
• A cli to tune infinispan subsystem
• A cli to setup custom event listeners
• A cli to disable offline session preloading
• A cli to change web context

All these cli were built based on keycloak documentation or examples from the community. We'd like to found the same kind of guidance for Keycloak.X. For instance, how to configure logging, cache , event listeners ...

Regards,

[pedroigor]

Hi, Today we have the following kind of cli to configure keycloak:

• A cli to disable theme caching in dev mode

We are also doing that when running the server in dev mode.

• A cli to setup http client to enable connection through a corporate proxy

We have options only for server proxy settings. We lack http client proxy settings ... Can you tell us what you are using so we can try to make them more explicit in our CLI?

• A cli to configure logging subsystem (level, pattern ...)

We are still figuring out how that should look like. Could you please share your experiences at #8870?

• A cli to tune infinispan subsystem

We have now basic options to choose a config file + set the transport stack. We can do much more here such as allow setting the number of owners, etc. But I'm not sure whether this should be just a matter of updating/creating your clustering config files or if it makes sense to provide specific options.

Can you share what you are using?

• A cli to setup custom event listeners

Do you mean deploy a provider?

• A cli to disable offline session preloading

Shall we make this disabled by default?

• A cli to change web context

it should be possible to do that now by using a specific option.

[fidgi]

Regarding :

• A cli to setup http client to enable connection through a corporate proxy
  May be you're right it's about the server setting :
  `

see https://www.keycloak.org/docs/latest/server_installation/#_proxymappings for configuration

/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:write-attribute(name=properties.proxy-mappings,value=${env.PROXY_MAPPING})
`

• A cli to configure logging subsystem (level, pattern ...)

here is the cli we're using:
`
/subsystem=logging/json-formatter=json:add(exception-output-type=detailed-and-formatted, key-overrides=[timestamp="app_datetime", level="severity_label", message="app_message"], print-details=false)
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=json)

Add date to timestamp field in colored logs

/subsystem=logging/pattern-formatter=COLOR-PATTERN:write-attribute(name=pattern, value="%K{level}%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n")

Configure log level

/subsystem=logging/logger=com.example.myidp:add
/subsystem=logging/logger=com.example.myidp:write-attribute(name=level,value=${env.MY_IDP_LOGLEVEL:INFO})
`
(I'll also add my contribution to #8870)

• A cli to tune infinispan subsystem

Mainly to workaround a bug in KC 14.0.0 and to enable cache metrics

`

Avoid Memory leak from KC (https://github.com/keycloak/keycloak/pull/8215/files)

Add expiration lifespan configuration to every distributed and replicated cache.

echo Setting expiration lifespan for 'work' replicated-cache
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'sessions' replicated-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'clientSessions' distributed-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'offlineSessions' distributed-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'offlineClientSessions' distributed-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'authenticationSessions' distributed-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'loginFailures' distributed-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)
echo Setting expiration lifespan for 'actionTokens' distributed-cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/component=expiration/:write-attribute(name=lifespan,value=900000000000000000)

echo Enable cache metrics
/subsystem=infinispan/cache-container=keycloak/: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens: write-attribute(name=statistics-enabled, value=true)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions: write-attribute(name=statistics-enabled, value=true)
`

• A cli to setup custom event listeners
  Yes this is to deploy a custom provider but also to enable event logging

`

Configure events listeners

/subsystem=keycloak-server/spi=eventsListener:add

Enable event logging

/subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:add(enabled=true)

Propagate success events to INFO instead of DEBUG

This allows to track successful logins in log analysis

/subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:write-attribute(name=properties.success-level,value=info)
/subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:write-attribute(name=properties.error-level,value=warn)

Configure my-event-listener event listener

/subsystem=keycloak-server/spi=eventsListener/provider=my-event-listener:add(enabled=true)

Configure key cache

/subsystem=infinispan/cache-container=keycloak/local-cache=keys/component=expiration:write-attribute(name=lifespan, value=${env.KEY_CACHE_LIFESPAN:86400000})
/subsystem=infinispan/cache-container=keycloak/local-cache=keys/component=expiration:write-attribute(name=interval, value=${env.KEY_CACHE_INTERVAL:86400000})

`

• A cli to disable offline session preloading

IMHO , yes , this should be the default configuration since restarting keycloak w/ millions offline sessions in the DB takes too much time.

[pedroigor]

@fidgi #9135

[dasniko]

While I appreciate the move to Quarkus and all the related stuff, even is some hard work is coming to some of us in heavily customized environments, I want to emphasize, that there are also a lot of users/customers who are using Keycloak deployed in a "legacy" standard way of doing this like "bare metal" and also running in container but not on K8s.
So, while I understand that K8s is a major issue for some, for others it's completely useless. Please keep this in mind!

[stianst]

We are, and Keycloak.X is by no means K8s specific

[dasniko]

What exactly should "headless" mean?
Just to develop your own frontends for Keycloak, so that the current themeing-approach isn't needed anymore?
Or is is, that customers would be able to integrate/embed Keycloak in their apps and using their application as frontend to login and stuff and not using Keycloak as a centralized AS?

I'd welcome the former.
The latter approach would only encourage customers to do authentication in a bad way of ROPC style, which is currently marked as "MUST NOT be used" and is considered insecure. Additionally I don't see how SSO should be enabled between various applications.

[LuciferSam86]

Really interested about Keycloak.X . I have installed KeyCloak in a couple of VMs without k8 or docker, since I'm not interested, so I hope the next versions of KC will be still supported in a "legacy" environment.

[stianst]

https://github.com/LuciferSam86

Really interested about Keycloak.X . I have installed KeyCloak in a couple of VMs without k8 or docker, since I'm not interested, so I hope the next versions of KC will be still supported in a "legacy" environment.

Seems you hijacked a thread on "headless" - but yes it will not be K8 only for sure

[stianst]

"Headless" is still to be defined, but yes the use-case is to customize the central IdPs UI, not to embed into applications.

[bjolivot]

My personnal wishlist for Keycloak future :

• split between managing endpoint (webui, config API) and business endpoints
• multi-datacenter cluster or failover, when SQL DB replication can't be established.
• step-UP auth (2FA only on some endpoints)
• parent-children realms

[summersab]

Where is the source for Keycloak.X? I've looked everywhere I can think, but I don't see it. I have a number of rather specific extensions, and I wanted to see if they would work. If I have to debug them, I'd need the source of the server.

Thanks!

[stianst]

github.com/keycloak/keyloak 😉

[summersab]

Ah, the main branch is Keycloak.X? I'd have thought you would have opened a new repo to keep the projects separate. Perhaps you could add a tag or do something to make it more clear? Just looking at the README for the main repo doesn't say anything about Keycloak.X, so I figured it would only contain code for the legacy project.

[rweintraub-cycleon]

how does the Keycloak -> Keycloak.X migration path look like?
Is it as simple as just pointing to the new image or are extra steps necessary?
Can existing Users & Clients be simply migrated/upgraded or are there also extra steps required?

I'm asking because we were about to go live with the old Keycloak distribution because the Keycloak.X distribution didn't look production ready at all(seeing no updates in about 1 year) and now we're essentially told that the old version is being deprecated in 3/6 Months.

Other than that I Like the improvements that keycloak.x is promising!

[stianst]

The Quarkus distribution is the first thing that is coming, which is in December/January it will be final. The database will be unchanged at this point, so you only need to change how you install and configure it to switch to the Quarkus distribution. You have 6 months to do that, or Red Hat Single Sign-On will allow you to continue without any changes until June 2024.

[rowe42]

We are using Red Hat Single Sign-On (RH-SSO), but always keeping an eye on what happens to Keycloak, as we're expecting that new features are also always coming to RH-SSO in a few months time.

Therefore it is worrying me that you are saying RH-SSO stays without changes until June 2024, @stianst

There are features already in Keycloak, which didn't make it to 15.0.2 and therefore not to RH-SSO 7.5 (for example the EncryptedID in SAML Responses) and we are waiting for a bigger contribution around the SAML Parser in the Identity Brokering. But will these features reach RH-SSO 7.x soon or only RH-SSO 8 or do we even have to wait until June 2024? That would be a catastrophy and we would have to consider switching from RH-SSO to Keycloak...

[stianst]

@rowe42 RH-SSO 7.y stays as it is with regard to WildFly and the old store. Other features will be included in RH-SSO 7.6. Quarkus and the new store will come in RH-SSO 8 (dates tbd).

[FlxPeters]

Hi and thanks for blog post about Keycloak.X. I really love the idea of a modern Keycloak distribution.
At my current company we are starting to implement Keycloak as the new IAM solution and our roadmap overlaps with the roadmap of Keycloak.X. This is fine but i have some question what we have to expect for customizing Keycloak.

So can you please clarify some questions about extensions in the future?

One example use case we have is an approval workflow to add users to groups. My current approach is to build an extension with custom rest endpoints, entities and so on in Keycloak. Reading the blog post if sounds like this is not the way in the future. Should we even follow this path anymore or is it better to have some kind of external sidecar application using the REST API without integration with Keycloak directly?

One other issue is the new storage layer. Does this refer to the underlying database or are changes to the model also possible here?
It would be great to have some kind of meta data on the relation from groups to users or roles to users. With the current model I'm not able to store meta data on relations like the time it was created, who was responsible or attributes like the the id of the request to join a group.
Are there any plans to adjust the mode here?

Other than that, thank you very much for your work. I look forward to the next releases.

[marziman]

First of all thanks guys, Keycloak rocks!
We are really happy you recognized this and move to Quarkus and make Keycloak more Cloud-Native.
As we are using it in our SaaS startup, I will try to give some different perspectives as all of our microservices are developed with Quarkus. One problem is we are in the works to make a GoLive with Wildfly Keycloak soon in December 2021. This overlaps with KeycloakX Quarkus release and it would be great to get a rough planned date for December 2021 version? Of course we want to use that for the GoLive, and would like to know if this is too "startup-style-risky" or good to do.

Here some points which can be improved:

• KeycloakX documentation: Beside your blogposts, it was like this chnage is stuck or not happening. We propose to make KeycloakX more prominent, similiar as JenkinsX did back than. It will help much to better understand these planned changes and where to checkit out
• Multitenancy/Subrealms: Currently Realms are the seperation, but there is a need for Hierarchical Realms/Namespaces (where one Realm can be parent, and other subrealms can inherit or configured to not inherit)
• Default support of configuring everything by Operator & Helm for k8s
• Scalability: We scaled Keycloak to Millions of users. This info was so hard to find, and this shall be improved and gonna boost adoption rate. KeycloakX shall be easily scalable and support HPA, and DB scaling. Maybe a reference example would help.
• Istio Service Mesh: We are using Keycloak with Istio. It would be really good if KeycloakX supports the wellknwon ServiceMesh stacks
• Vault Integration: We also think some infos of Keycloak could be stored in Vault
• K8s external Secrets: Could be used in combination with Vault
• CRDs: Usage of CRDs to modify any ressource in KeycloakX
• Distro Profiles: Minimal, Base, Full etc. - so some users can go with a base version, according their requirements
• SaaS and B2B scenarous shall be thought about, where KeycloakX can be easily included
• Theming: Deprecate the old FreeMaker theming and switch to modern Frameworks like e.g. React, Flutter etc. - Making this easier by building theming and customization into the admin console would be awesome
• Dashboard: Built in Dashboard with overview of basic data like e.g. Logins, Failed Logins and active Users - everybody wants this :-)
• Monitoring Support: Prometheus Metrics and seamless integration into Cloud Native Monitoing Stacks.

This are just some ideas we wanted to share and thank you for this awesome project.

BR Mehmet

[trixpan]

@marziman regarding this:

K8s external Secrets: Could be used in combination with Vault

couldn't you use vault sidecar (ie pseudo mount) + file based secrets?

Note. I am not a big fan of the sidecar approach but just suggesting

[pedroigor]

@trixpan Thank you for the feedback!

• KeycloakX documentation: Beside your blogposts, it was like this chnage is stuck or not happening. We propose to make KeycloakX more prominent, similiar as JenkinsX did back than. It will help much to better understand these planned changes and where to checkit out

@stianst is preparing a "framework" for building our docs and we should have something better for sure. It sucks today, yeah.

We are also trying to make CLI and default configuration as helpful as possible to configure/deploy the server.

• Scalability: We scaled Keycloak to Millions of users. This info was so hard to find, and this shall be improved and gonna boost adoption rate. KeycloakX shall be easily scalable and support HPA, and DB scaling. Maybe a reference example would help.

Would you be able to share your experience scaling Keycloak so that we can think about including/changing our defaults in terms of: clustering, database connections, HTTP settings (timeout, io/worker threads), security (vault, etc)?

• Vault Integration: We also think some infos of Keycloak could be stored in Vault

We are now enabling mounted secrets (similarly to Wildfly distribution) and also Hashicorp integration by leveraging the quarkus-vault extension.

• Distro Profiles: Minimal, Base, Full etc. - so some users can go with a base version, according their requirements

That is what we are trying to achieve. Right now we have dev and prod profiles. But we would like to add more whenever it makes sense so that you can easily configure/deploy the server to a specific environment or type of deployment.

The same goes for clustering. For instance, clustering now is by default based on Infinispan default stacks for ec2, azure, google, k8s, etc. It is a matter of picking one and setting its properties. We still have to improve here in terms of UX.

• Monitoring Support: Prometheus Metrics and seamless integration into Cloud Native Monitoing Stacks.

We have @thomasdarimont working on that.

[marziman]

@pedroigor actually those been our feedbacks :-)
Many thanks for answering.
Sure we can share our scaling settings or even can contribute to the documentation what we have done.
For our scenario it had to be more than 1. Mio users and ca. 1500 qps.

We are more than happy to contribute.
BR Mehmet

[pedroigor]

@marziman Could you please look at what we are planning in terms of documentation. See #9034.

For instance, looks like you can help a lot with feedback about deploying to production and some other topics.

[trixpan]

@stianst

I have been testing keycloak-x (using 15.0.2 but also observing changes in master) and noticed a few distinctive changes in behaviour between X and legacy.

• Multi-SPI EAR deployments seem to be incompatible with Quarkus. (We had to export the JARs within the EAR file in order for the deployments to work)

• vertx (http endpoint) seems to behave slightly differently from undertow in handling the certificates. We use a custom java.security.Provider implementation (required to use a HSM) and we noticed that quarkus seems to assume keys will not change during runtime. This is not always the case. in certain scenarios (e.g. HSMs, LetsEncrypt, key lifecycle, etc) keys may change during runtime and the endpoint should be able to handle the updated TLS context. (workaround is to restart the service, which in quarkus/keycloak.x tends to take far less than wildfly).

Not a change in behaviour but worth of note:

• kc.sh config will persist the db configuration (i.e. h2-file) and setting KC_DB=new_vendor before running kc.sh start seems to be ignored.
  This is a pain when CI/CD creates a docker container that is expected to be vendor agnostic (workaround is to re-run config as part of docker-entrypoint but this seems like a time waste).

Bugs:

• kc.sh struggles with password. i.e. kc.sh config --db-password='password123=' results in password123 being persisted.

[stianst]

The EAR deployments is not something we can support with Quarkus for sure, so will have to be single JARs. However, each JAR can of course contain multiple providers.

Not sure it is possible to support keys changing at runtime. At the very least I would think the http listeners would need to be restarted, and by then you're quite close to having to restart Keycloak anyways. We're optimising more and more the startup time for Keycloak, so perhaps this is good enough. <- @pedroigor @DGuhr FIY.

With Keycloak 16 kc.sh will behave quite differently and there are loads of improvements being made, and there is now a more clear definition between "build" and "runtime" configuration, where things like changing the DB vendor is a build time option, which to be able to get the best startup you should extend the image with build time config. There's also a "--auto-build" option though, and this is how the base image we deliver will behave, so it will take into account the updated DB vendor.

[pedroigor]

@trixpan First of all, thanks for the helpful feedback. We really need this to make sure we are moving to the right path.

I second @stianst comments. I would just add:

• TLS: We should definitely investigate this and see what we can improve in this area. We have this issue https://issues.redhat.com/browse/KEYCLOAK-16017 with some ideas around supporting different integrations/approaches for setting up TLS. In any case, we should also look more what Quarkus has to offer and see what we can do in our side or propose to Quarkus to make this less painful.

• Using env vars: It should be fixed in upstream.

• Vendor agnostic image: As Stian mentioned, we introduced the --auto-build option to allow people to dynamically re-configure the server in case certain properties change (e.g.: db). It is a tradeoff between startup time and UX. Ideally, we recommend having opnionated and fully optmized server runtimes (e.g.: build then start).

• Password property bug: It should be fixed.

We really appreciate if you can try out the upstream version.

[pedroigor]

@trixpan W.r.t. the issue when using the = sign in option values, please see #9402.

[Mistic92]

I'm curious if it will be possible to easily run Keycloak.X on GCP Cloud Run. I was trying to run Keycloak on it but because of wildfly and some background job it was not possible at all.

[pedroigor]

@Mistic92 The same background jobs still exist. Perhaps it makes more sense to open an issue for this one.

[c-piyush]

Please confirm if defining security policy within a realm will also be more flexible in Keycloak.X e.g. defining different password expiry for users within a realm . thanks in advance.

[pedroigor]

@c-piyush Keycloak.X is basically the same distribution in terms of IAM functionality.

However, you should expect UX improvements from the new admin console.

[alexkreidler]

My primary wish would be for the team to focus on headless UI. I think customizing the UI is one of the first things most new Keycloak users do, because most of the other deployment and configuration for Keycloak has sensible defaults. But often they may be overwhelmed by the theme options or Keycloak themes may just not fit with their workflow (eg if they're using a library like React's Chakra UI or Tailwind CSS, and they have all their design tokens/components in that framework, and they would have to extract those styles from those tools and learn Keycloak-specific css classes like kcLoginClass, kcInputClass, etc). There's the project https://github.com/InseeFrLab/keycloakify which aims to allow users to build the Keycloak interfaces in React. Maybe it would be helpful to reach out to them and ask what changes the core project can make to improve theming.

I think eventually exposing all the internal Keycloak auth page APIs as REST with JSON, with good documentation, would allow users to use a totally different framework like React, Vue, etc, to render the auth pages. Then either the Keycloak binary could serve this custom auth UI Single Page App, or the user could deploy it with a normal server like NGINX or as a static site using a CDN.

Thanks for all the great work and the vision for Keycloak.X!

[garronej]

As the original author of Keycloakify I fully agree with this comment.

[pedroigor]

I remember discussions and ideas (nothing concrete yet though) around adopting a micro-frontend architecture.

@ssilvert @stianst Can give more details about it.

[pedroigor]

Hi All, we appreciate if you can look at what we are planning in terms of documentation so that you can help us to cover the main aspects of the new distribution and how to use it to configure and start Keycloak.

Please, leave your comments here #9034.

[preston]

Hi, We have multiple Wildfly-bsaed instances on Postgres that have been running for years that are now on the quay.io/keycloak/keycloak:17.0.1-legacy tag. We are really confused about migrating to the regular 17.0.1 release for moving forward, as we aren't wanting to compile our own instances right now. Ideally I'd just like to run pre-built images with a Postgres driver baked in, as opposed to having to rebuild our own image for every release.

The "Migrating to Quarkus" page (https://www.keycloak.org/migration/migrating-to-quarkus) says "..there is also an auto build mode that makes Keycloak behave more or less the same as the WildFly distribution in this regard", but doesn't explain how to do that.

How do we do that? :) Thanks!

[pedroigor]

@preston The auto-build mode is enabled by passing the --auto-build option when starting the server:

kc.sh start --auto-build --db postgres <options>

It will trigger a build whenever the configuration change.