Understand config precedence and profiles in Spring Boot for Kotlin and Java

If your configuration feels like a conspiracy theory you are not alone. Spring Boot reads and merges properties from several places to decide how your app behaves at runtime. Getting the order right stops mysterious overrides, saves hair and prevents late night pings from Ops.

Where Spring Boot looks for configuration

Here is the practical priority you need to know, roughly from highest to lowest. Think of this as the referee who decides which setting wins.

• Command line arguments These have the final say when things tie. Useful in quick fixes and CI jobs.
• Environment variables and Java system properties This is where containerized apps and runtime overrides live, including SPRING_PROFILES_ACTIVE.
• External config files Files placed in a config folder next to the jar or supplied via spring.config.location or spring.config.additional-location. Good for secrets and team specific settings.
• Profile specific files Files like application-dev.properties or application-dev.yml override the main application file when the profile is active.
• Main files inside the jar application.properties or application.yml packaged in the jar provide defaults.
• Default properties Fall back values baked into the application jar.

Notes about YAML and merging behavior

YAML is supported and great for nested configuration and readability. Spring Boot merges configuration in most cases rather than replacing whole objects. That means you can override a single property without reworking the entire section, which is handy for sharing defaults across environments and tweaking a few values per profile.

How profile activation works

Activate a profile with spring.profiles.active=dev or set the environment variable SPRING_PROFILES_ACTIVE when running in containers or CI. Profile specific files with the right suffix will override the main configuration for that profile. Yes this is obvious when it works and infuriating when it does not.

GraalVM native image and resource caveats

When compiling to a native binary with GraalVM resource scanning can behave differently. Property files may not be picked up unless they are explicitly included in the native image resource list. Test profile activation and your configuration as part of the native build pipeline so you do not discover problems at midnight in production.

When you need to change the lookup order

Use spring.config.location and spring.config.additional-location to point Spring Boot at config files outside the jar. This is the right move when teams require externalized configuration, or when secrets must never be baked into artifacts.

DevOps friendly tips

• Supply profile via environment variable or command line in CI and production for predictable behavior.
• Use the Actuator environment endpoint at /actuator/env during development to inspect the final merged property set and avoid surprise overrides.
• Remember Kotlin and Java use the same configuration model so rules apply equally to both runtimes.

In short, know the precedence, prefer environment variables or command line for CI, include property files in native image resources when using GraalVM and use Actuator to peek at the merged settings. Do that and your configuration will stop plotting against you.