Best practice for deploying themes on production?

Getting advice
1

Hi there!

Im running KC 24 and having trouble when deploying new versions of custom themes. Im deploying my themes as jar-Files in the providers folder.

When I deploy a new version of an existing theme to my Keycloak instance all user sessions are gone. I´ve read, KC 25 might help with that.

But also, the deployment itself is really messy: The only way for me to ensure all changes in the theme are really shown, is to change the ID for the current KC version in the MIGRATION_MODEL database table, before restarting Keycloak.

I´m assuming this approach is also the reason for the lost user sessions, because without this hack the user sessions are still there after restart.

Also I noticed, that not all parts of my theme need this special approach to ensure changes are visible after restart. For the theme files itself a restart is sufficient. But within my login theme I´m using java script which reads txt-files and displays them in some special popups. For changes in those txt-files or in the css-files used there, the approach described above unfortunately is necessary.

This all seems really messy to me and I think there has to be a better way too deploy a new theme version.

Any suggestions?

Regards
Lars

2

You are running into http caching. One option commonly used is adding a version to those filenames to ensure browsers do download a fresh copy if needed.

(so instead of theme.css theme-v12.34556.css)

3

Thank you for giving my problem a name :slight_smile:

For reference: HTTP caching - HTTP | MDN

I deep dived into this one but that seems really difficult task within an automated build process.

The other option - using version numbers or hashes as query parameter - also seems not easy.

4

It‘s not only about HTTP caching. You can also control caching in the Keycloak server and the header for http caching. See Server Developer Guide for details.

5

I know I can disable theme caching in the Keycloak server. But that seems to be no option for a production environment.

The Cache-Control HTTP header is already set to max-age=0, no-cache, no-store, must-revalidate.