Jakub Jaruszewski

@juan131 Yes, that's correct! If you wish, I may try to implement backwards compatibility by introducing KEYCLOAK_LEGACY_PROXY which defaulta to the value of KEYCLOAK_PROXY (and is only a helper variable)...

I will make counterpart PR for helm chart and link it here

> According to the [docs](https://www.keycloak.org/docs/latest/upgrading/index.html#deprecated-proxy-option), the `edge` mode (`kc.sh --proxy edge`) is equivalent to `kc.sh --proxy-headers forwarded|xforwarded --http-enabled true`. Don't we need to add another variable to also support the...

@juan131 Please see: https://github.com/bitnami/charts/pull/27890

Payload is correct in **both** examples (it is different since it uses different api ednpoints). But endpoint `/robots` works, but `/projects/{project_name_or_id}/robots` does not. It should succeed in both examples.

To reproduce just try to create a robot via `/projects/{project_name_or_id}/robots` (a one which haves some permissions) - it's not possible from my testing

I can replicate this on a system with 8GB VRAM + 64GB RAM, so ollama is not running out of memory, here is some more info. I'm using ollama 0.3.12...

I would be willing to provide a relevant PR, however currently custom PostgreSQL user must be known during templating (chart determines whether to use custom user password or admin user...

@joancafom Any progress on this? Agan, I can provide a PR, but this change will require some changes in the chart logic - as mentioned above and I would like...

I assume, that this comes from assumption, that if a robot account has `read` permissions on Project `A`, then it should not be able to determine the existence of other...