Profile-specific property loading not working in native images

[bbortt]

So I think I found a bug in the way Spring native handles profile-specific property files. Or if it isn't a bug, at least it is very confusing to me and probably would need clarification in documentation.

I am building a simple spring-boot application containing only: spring-boot-starter-actuator, spring-boot-starter-web. Version is defined: <spring-boot.version>4.0.0</spring-boot.version>.

I then build a native image, with "prod" profile enabled.

[INFO] --- spring-boot:4.0.0:process-aot (process-aot) @ spring-native-bug-reproducer ---
[...]
2025-12-05T12:38:22.639+01:00  INFO 17844 --- [           main] io.github.bbortt.spring.bug.App          : The following 1 profile is active: "prod

And I also passed a <buildArg>--spring.profiles.active=prod</buildArg> to the <artifactId>native-maven-plugin</artifactId>. It looks to me like this is being respected, because the resulting image says so:

$ docker run --rm docker.io/bbortt/spring-native-bug-reproducer:latest
[...]
2025-12-05T11:42:05.776Z  INFO 1 --- [           main] io.github.bbortt.spring.bug.App          : The following 1 profile is active: "prod"

However, the file resources/application-prod.yaml is not being loaded. Properties defined in profile-related property sources are not present in the native image. I even explicitly tried printing them out:

2025-12-05T11:53:25.835Z  INFO 1 --- [           main] io.github.bbortt.spring.bug.App          : normalProperty=defined, prodProperty=undefined

Despite having an impact on the build process, but not during runtime. Why "impact during build process"? Well, if you specify a different management.server.port compared to server.port in resources/application-prod.yaml actuator will expect management.server.port to be defined during runtime. But it is not! The results in an exception being thrown:

Caused by: java.lang.IllegalStateException: 'port' must not be null
        at org.springframework.util.Assert.state(Assert.java:80)
        at org.springframework.boot.actuate.autoconfigure.web.server.ManagementWebServerFactoryCustomizer.customize(ManagementWebServerFactoryCustomizer.java:108)

So, it clearly expects the management.server.port to be different, but somehow it is not present during runtime. Funny thing is, if you specify MANAGEMENT_SERVER_PORT via environment variable, everything works just fine.

Two more things: The file itself is present on the classpath. And explicitly loading it does not help!

I would argue that whatever impacts the build lifecycle of native images should also be present or working during runtime. Thoughts, anyone? 😉

[mhalbritter]

You have to specify the profile when running the AOT step (see this documentation, the way you did this differs) and you have to specify the same profile when you run the native image (e.g. --spring.profiles.active=prod). Then the property should be there in the native image. Can you try that?

[mhalbritter]

When not using --spring.profiles.active=prod when running the native image, the output

The following 1 profile is active: "prod"

is somewhat confusing. It means that the beans from the "prod" profile are respected (because the AOT phase has been run with the prod profile), but the properties aren't loaded from the prod configuration file. Passing --spring.profiles.active=prod when running the native image fixes that.

[bbortt]

so this would be the change, right?

that doesn't help. I would also argue that AOT processing has been done in prod profile previously, looking at the log. vs the current log. I do not see any difference.

[snicoll]

Good catch Moritz. That's likely a bug. The profile is set in generated code, but is applied after the environment has been prepared.

[snicoll]

@bbortt we need to stop with the back and forth. If you want support, please create a small sample starting from start.spring.io that reproduces the problem you've described with instructions to run the native image. You can share a zip here or push the code to a GitHub repository. Once we're on the same page, it'll be quicker to figure out what's missing and/or if there is another issue.

[bbortt]

@snicoll but that's exactly what I've done?? 😉 just follow the links. they all link to a reproducer, including a pipeline showing the exact logs and errors...

[snicoll]

Not really no. Your sample is not a minimal sample and does not start from start.spring.io (does not use our parent). It does not provide a version for the native maven plugin that throws a warning. It contains a number of things that are unrelated to what's discussed here and it still contains the build arg option we've established as being incorrect.

If you want support, please provide the sample as instructed. It may happen that this project may not expose the issue as long as you provide the profile when starting the native image: there is indeed a valid issue that we should investigate, but doesn't match your initial report.