Ok, I now see the deficiency of what I originally though: main...alkersan:keycloak:argument_files

The various paths values inside argfiles (like -cp, kc.home.dir) are static. And making them relative wouldn't work either, as the working directory is unknown upfront.

How about this. I see there is already a PRINT_ENV variable in kc.sh (added along with bugfix few years ago). To aid with an optimized image building, maybe something like this could be added:

if [ "$PRINT_ARGFILE" = "true" ]; then
  printf "%s\n" $JAVA_RUN_OPTS
  exit 0
fi

Then, during multi stage build one could generate argfile and use it in entrypoint.

FROM quay.io/keycloak/keycloak:26.6.1 AS builder
ENV KC_DB=dev-file
ENV KC_HEALTH_ENABLED=true
ENV KC_METRICS_ENABLED=true

WORKDIR /opt/keycloak
RUN /opt/keycloak/bin/kc.sh build
RUN PRINT_ARGFILE=true /opt/keycloak/bin/kc.sh > /opt/keycloak/bin/jvm.args

FROM dhi.io/eclipse-temurin:25
COPY --from=builder --chown=nonroot /opt/keycloak /opt/keycloak

ENV LANG=en_US.UTF-8
ENV KC_RUN_IN_CONTAINER=true

WORKDIR /opt/keycloak
ENTRYPOINT ["java", "@bin/jvm.args"]

Or are you thinking that the Keycloak project should provide both shell and shell-free base image?

I don’t think it’s possible, given the current keycloak bootstrap design (i.e. build, then start), so “should” is not the expectation. It’s more about the ability to build an optimized shell-free kc.

Tried the suggestion from #48235 (reply in thread):

if [ -n "$PRINT_ARGFILE" ]; then
  echo "${JAVA_RUN_OPTS% ${CONFIG_ARGS#?}}" > "$PRINT_ARGFILE"
fi

That sort of worked

...
RUN PRINT_ARGFILE=/opt/keycloak/bin/jvm.args /opt/keycloak/bin/kc.sh build 

FROM dhi.io/eclipse-temurin:25
...
ENTRYPOINT ["java", "@bin/jvm.args"]
CMD ["start", "--optimized"]

But the more I think about this - the more it looks like a useless thing, not worth the hassle. It's now impossible to override any of the JVM memory/heap/runtime options, that were baked in during build. For example, if -XX:MetaspaceSize for some reason needs to change:

• appending after args file would break things, as this is JVM option, and not QuarkusEntryPoint option
• prepending it before args file will do nothing, because inside the arg file there would be -XX:MetaspaceSize=96M set during build
• java launcher does respect few "JAVA_OPTIONS" env vars, but it also has lower precedence than CLI args

I could probably strip even more of the JAVA_RUN_OPTS before saving it @argfile, e.g. the main class name io.quarkus.bootstrap.runner.QuarkusEntryPoint, and put in CMD or Entrypoint, but I already have mixed feelings about this.

It's now impossible to override any of the JVM memory/heap/runtime options, that were baked in during build

I expressed a similar concern over the java options in #48235 (reply in thread)

The only ways to workaround are probably:

• changing a java option means creating a custom image that modifies the jvm.args file, which seems cumbersome
• allow for a secondary arg file ENTRYPOINT ["java", "@bin/jvm.args", "@mount/jvm.args"] that can be overriden by a well known mount location

But the more I think about this - the more it looks like a useless thing, not worth the hassle.

Feel free to close the discussion if it seems like this won't be fruitful.

These will be passed as CMD options, appended to the entrypoint, no? I think it would work as expected.

java @bin/jvm.args start-dev —http-enabled=false …

Wouldn't this make it impossible to then provide CLI args to the KC instance? So I could not do something like:

If you are using a shell free image yes, but - I missed the response from @alkersan that presumably this could work - as long as they are just our options. Anything that is or maps to a java option (such as --debug) won't work.

presumably environment variables (for our options, not those that would influence kc.sh) should work as expected.~

It was omitted in what is shown above in default.args, but it would also contain start --optimized

The proposal here isn't to only offer a shell free image - I did ask if there was implication here that the project should offer both forms of the base image #48235 (comment)

@alkersan @shawkins Thank you for the clarification.

Publishing both versions of the image sound like too much overhead and might also cause some confusion with the users if they don't fully understand the trade offs here. My biggest concern is that you can't SSH to a shell-free container. In case you need to debug or troubleshoot something, that might be a deal breaker. And sometimes you might not even know that beforehand. You can have a long-running Keycloak instance, you choose the shell-free image back then, and now you run into issues and can't even SSH there. There might be some workarounds like K8s ephemeral containers but that's not ideal.

-1 from me.

Thank you for the feedback @ASzc. That feedback and this comment #48235 (reply in thread) mean this is scoped as just something optional for the building of optimized images. And if we were to document anything, it would show an example around ubi-micro.

#48235 (reply in thread)

I'd be fine with either the command being run separately as you have shown, or as a side-effect of the build command (RUN PRINT_ARGFILE=/opt/keycloak/bin/jvm.args /opt/keycloak/bin/kc.sh build).

as a side-effect of the build command (RUN PRINT_ARGFILE=/opt/keycloak/bin/jvm.args /opt/keycloak/bin/kc.sh build)

Nice, I like such format more.

And to clarify the original intent - I'm not proposing keycloak to use a different base. Let's say, as a platform/ops employee of an enterprise - I have to follow internal mandates, such as "anything touching prod, must use our own bespoke, vetted, rubber stamped set of hardened/forged/tempered images". And if I can make the app run on the smallest variant of registry.acme.net/hardened-jre:25 - that's one less of a security exception I'll need to file.

Neat trick