Behemoth may be a bit of a stretch, but the container is 20x the size of authelia, it's minimum recommendations are 512mb ram, and 1g of disk space. Compared to Authelia, which is using 30mb of ram and 500k disk space, yeah it's big.

Not to mention, only the admin user being configurable via environment variables isn't enough. With Authelia, I can share my homelab setup and with a couple of environment variable changes, people can have SSO integrated. There's no need to write guides or grab screenshots to help them get set up.

have you looked at the codebase? it's been a while but I was implementing Keycloak a few years ago and it was shocking how big the codebase is and how difficult it is to change things to add what felt like basic functionality. making plugins didn't seem like a viable option either.

oh not to mention the statefulnes of it, it was almost impossible to destroy and re create an instance from scratch without a bunch of manual point and click via the UI.

Keycloak solves a complex problem.

It is built on a plugin architecture, so plugins are certainly a viable option and this is documented in more detail here[0]. In general I have found the Keycloak docs thorough and well-written. When I operated Keycloak I built a few plugins to solve specific needs/assumptions we had around IdP when migrating to Keycloak from a bespoke solution.

Re: your second point, the docs also describe this in detail[1]. Having the realm data exist in a simple form that can be exported/imported was very useful. However, I would have liked if they thought more about how to do live backup/restore; perhaps that is easier now than it was at the time.

[0]: https://www.keycloak.org/docs/latest/server_development/inde... [1]: https://www.keycloak.org/server/importExport#_importing_a_re...

> Keycloak solves a complex problem.

A lot of problems, actually, and most people don't have many of them. If you just want an OIDC server in front of your self-hosted apps you can solve that with a much simpler and faster tool.

The docs can say whatever it wants, there were large parts of our configuration that wasn't included in an export, so we couldn't automate provisioning.

Had a similar experience and even filed a couple of bugs back then. I don't know the current state but back then it felt like having something that looked like halfway modern Java but still carried around large amounts of old school JEE cruft. Probably was the migration to quarkus though. So it probably got better?

Interesting... I had the exact opposite impression. The codebase is big but very easy to understand and their SPIs[1] enable to customise Keycloak's behaviour quite easily.

For the statefulness using terraform[2] solves the problem for me.

[1] - https://www.keycloak.org/docs/latest/server_development/#_pr... [2] - https://github.com/mrparkers/terraform-provider-keycloak

It would be great to know how you start Keycloak. In our CI it takes 40s-1m to start and consumes 500Mb. We use default docker image.

  > 2024-02-11 17:15:35,764 INFO  [io.quarkus] (Shutdown thread) Keycloak stopped in 0.064s
  > 2024-02-11 17:15:37,754 INFO  [org.keycloak.common.Profile] (main) Preview feature enabled: token_exchange
   ...
  > 2024-02-11 17:15:44,694 INFO  [org.infinispan.CLUSTER] (jgroups-8,a4c127cdee40-48683) ISPN100000: Node 72d48695e84c-46513 joined the cluster

so 7 seconds altogether on that restart, though a lot of that time is spend waiting for other nodes before it bootstraps the cluster. (its single node as its a toy server, as i said before)

this is the dockerfile: https://pastebin.com/rVdXjUkP

which is basically just the officially documented way to make the image, albeit set to use a reverse proxy for https

https://www.keycloak.org/server/containers

your CI pipeline probably downloads the runtime dependencies each time from the internet, as building this image does indeed take around ~40s.

the resulting image is ~620MB.

As I said earlier, making this image has become basically mandatory with their switch to Quarkus. You should really address that ;)