Master Spring Boot Configuration Priority: Avoid Costly Mistakes

In Spring Boot, configuration sources are applied in a defined order: external files override those packaged inside the jar, and command‑line arguments have the highest precedence.

Configuration file location priority

Spring Boot loads configuration files based on their physical location. Files placed later in the search path override earlier ones.

classpath:/application.properties
server.port=8080
app.name=MyApp

file:./application.properties
server.port=9090

file:./config/application.properties
app.name=ProdApp

The effective values are: server.port=9090 (external overrides internal) app.name=ProdApp (higher‑priority file overrides)

Configuration source type priority

Spring Boot also reads properties from several sources, each with its own precedence (low to high):

SpringApplication.setDefaultProperties

@PropertySource(...)

configuration files ( .properties / .yml)

environment variables (e.g. export SERVER_PORT=9090)

JVM system properties (e.g. -Dserver.port=9090) SPRING_APPLICATION_JSON environment variable

command‑line arguments (highest priority)

Example: java -jar app.jar --server.port=9999 Even if server.port=8080 is set in a .properties file, the command‑line value wins.

Profile‑specific configuration

Spring Boot supports multiple profiles (dev, test, prod). Profile‑specific files ( application‑{profile}.properties) are loaded after the default file, and later‑specified profiles override earlier ones.

Activation can be done in three ways:

In a configuration file: spring.profiles.active=prod As a command‑line argument: --spring.profiles.active=prod Via an environment variable: export SPRING_PROFILES_ACTIVE=prod When both dev and test profiles are active, test overrides dev, so log.level=INFO takes effect.

Configuration validation

To determine which value is actually used, you can:

Call the Actuator /env endpoint.

Check the startup logs for “Config data locations”.

Print property sources programmatically:

@Autowired
Environment environment;

@PostConstruct
public void printPropertySources() {
    for (PropertySource<?> ps : ((AbstractEnvironment) environment).getPropertySources()) {
        System.out.println("Source: " + ps.getName());
        System.out.println("server.port = " + ps.getProperty("server.port"));
    }
}

Typical scenarios

Separate development and production configurations: keep dev files inside the jar and place prod files in ./config/, activating with --spring.profiles.active=prod.

Containerized deployments: command‑line arguments > environment variables > mounted files.

Secure sensitive data by injecting passwords via environment variables and keeping non‑sensitive settings in property files.

Key takeaways

“External > internal, command‑line > env, dynamic > static.”

External configuration overrides internal.

Command‑line arguments outrank environment variables, which outrank file‑based settings.

Dynamic sources win over static files.

Avoid placing sensitive data in @PropertySource, duplicate property definitions, and be aware of profile loading order.