[throwaway894345]

> One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh

I'm pretty frightened of running Java services, not because of the JVM, but because every Java app I've had to operate is infinitely configurable via some poorly documented XML file, and trying to reverse engineer the XML file is often difficult because you have to route through a bunch of Spring Boot magic (preventing an easy grep for configuration options). And on top of that the defaults are rarely system defaults, so even figuring out _where_ the application expects to find its configuration file is nontrivial and logging by default is separated into some unknown number of log streams which each go to a completely different path on disk by default and each one has its own configuration option for telling it to log to stderr.

By contrast, Go services are pretty explicit about where they expect their configuration, they usually log to stderr by default, you can pretty much drop them into any Docker image and run them without issue (no need to custom tune the JVM or bundle up dependencies and ensure the right runtime version). I'm told that the Java world is changing, but in the mean time I will put up with _a lot_ in the way of missing features in order to avoid running a Java application.

Sorry for the rant. :)

[nja]

The nice thing about the Java base here was that instead of trying to solve problems with a mess of configuration, we could just write our own code plugging directly into / replacing parts of Keycloak. Definitely don't disagree with you about the pain of XML, but that wasn't an issue for us here at all

[throwaway894345]

Yeah, I fully believe that there are advantages for your team, and even that Keycloak is much better than the Java apps I have had to operate. I'm just traumatized. :)

[vbezhenar]

I've used environment variables to configure keycloak. Worked for me.