Spring Boot lets you externalize configuration so the same application binary runs correctly in different environments. You can supply configuration through Java properties files, YAML files, OS environment variables, and command-line arguments — and Spring Boot resolves all of them through a singleDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/spring-projects/spring-boot/llms.txt
Use this file to discover all available pages before exploring further.
Environment abstraction.
Property source precedence
Spring Boot applies a well-defined ordering so that later sources can override earlier ones. The most important levels from lowest to highest priority are:1. Default properties
1. Default properties
Set programmatically via
SpringApplication.setDefaultProperties(Map). These are always the lowest-priority source.2. Config data files
2. Config data files
application.properties and application.yaml files, loaded from the classpath root, the classpath /config package, the current directory, and subdirectories of config/. Profile-specific variants (e.g., application-prod.properties) always override the non-specific file.3. OS environment variables
3. OS environment variables
Useful in containerized environments. Spring Boot performs relaxed binding, so
SPRING_DATASOURCE_URL maps to spring.datasource.url.4. Java system properties
4. Java system properties
Properties set via
-Dproperty=value on the JVM command line.5. Command-line arguments
5. Command-line arguments
Arguments starting with
-- (e.g., --server.port=9000) are the highest-priority source among non-test sources. Spring Boot converts them to properties and adds them to the Environment.Stick to a single format across your entire application. When both
.properties and .yaml files exist in the same location, .properties takes precedence.application.properties vs application.yaml
Both formats are supported. Spring Boot automatically finds and loads them from the classpath and the current directory.- properties
- yaml
Environment.
Importing additional config files
Usespring.config.import to pull in configuration from additional locations:
optional: prefix prevents startup failure when the file does not exist.
Injecting values with @Value
@Value is the simplest way to inject a single property into a bean field or constructor parameter:
${name:World}.
Type-safe configuration with @ConfigurationProperties
For hierarchical or multi-property configuration,@ConfigurationProperties binds a whole group of related properties to a strongly typed Java class. This is safer and more maintainable than scattering @Value annotations across your codebase.
JavaBean-style binding
| Property | Type | Default |
|---|---|---|
my.service.enabled | boolean | false |
my.service.remote-address | InetAddress | — |
my.service.security.username | String | — |
my.service.security.password | String | — |
my.service.security.roles | List<String> | ["USER"] |
Enabling @ConfigurationProperties types
Register the type either explicitly:@ConfigurationPropertiesScan to your main application class:
Validating configuration
Combine@ConfigurationProperties with Bean Validation to catch configuration errors early at startup:
JSON application properties
When OS environment variable naming restrictions prevent you from setting individual properties, encode a block of configuration as a single JSON string inSPRING_APPLICATION_JSON:
my.name=test being added to the Environment.
Random values
UseRandomValuePropertySource to inject random values at startup, which is useful for secrets and test data:
@Value vs @ConfigurationProperties
@Value | @ConfigurationProperties | |
|---|---|---|
| Binding style | Single property | Whole prefix group |
| Type coercion | Limited | Rich, including collections |
| Validation | Manual | Bean Validation (@Validated) |
| Relaxed binding | Partial | Full |
| IDE metadata support | No | Yes (via annotation processor) |
| Best for | Simple, one-off values | Structured, multi-property config |