Introduction

External configuration is one of Spring Boot’s most useful features because it lets the same application binary run in development, test, and production with different settings. Instead of recompiling code for each environment, you supply values from files, environment variables, or command-line arguments. The important part is understanding both where Spring Boot reads properties from and how those values are bound into your application.

Start with application.properties or YAML

Spring Boot automatically loads configuration from standard locations such as the classpath and common external config directories. You can use either .properties or YAML files.

A simple YAML example:

1server:
2  port: 8081
3
4app:
5  name: billing-service
6  feature-enabled: true

The equivalent properties file would be:

server.port=8081
app.name=billing-service
app.feature-enabled=true

Spring Boot supports overriding packaged configuration with external files. In practice, that means you can ship default settings inside the jar and provide environment-specific values outside the jar at deployment time.

Bind Configuration with @ConfigurationProperties

For anything beyond a couple of simple values, @ConfigurationProperties is cleaner than scattering @Value throughout the codebase. It gives you structured, typed configuration and makes validation easier.

1package com.example.demo;
2
3import org.springframework.boot.context.properties.ConfigurationProperties;
4
5@ConfigurationProperties(prefix = "app")
6public class AppProperties {
7    private String name;
8    private boolean featureEnabled;
9
10    public String getName() {
11        return name;
12    }
13
14    public void setName(String name) {
15        this.name = name;
16    }
17
18    public boolean isFeatureEnabled() {
19        return featureEnabled;
20    }
21
22    public void setFeatureEnabled(boolean featureEnabled) {
23        this.featureEnabled = featureEnabled;
24    }
25}

Then enable scanning and inject the properties bean:

1package com.example.demo;
2
3import org.springframework.boot.SpringApplication;
4import org.springframework.boot.autoconfigure.SpringBootApplication;
5import org.springframework.boot.context.properties.ConfigurationPropertiesScan;
6
7@SpringBootApplication
8@ConfigurationPropertiesScan
9public class DemoApplication {
10    public static void main(String[] args) {
11        SpringApplication.run(DemoApplication.class, args);
12    }
13}

This approach scales much better than reading raw strings from the environment in many places.

Use Environment Variables and Command-Line Overrides

Spring Boot’s property resolution order is designed so that later, more specific sources can override earlier defaults. In real deployments, environment variables and command-line flags are common override layers.

For example:

export SERVER_PORT=9090
export APP_NAME=billing-prod
java -jar app.jar --app.feature-enabled=false

Spring Boot maps environment variables such as APP_NAME to app.name. Command-line arguments such as --app.feature-enabled=false have even higher precedence than file-based configuration.

That makes them useful for last-mile deployment tweaks, but it also means you should document them carefully. Mystery overrides from shell scripts are a common source of confusion.

Profiles and Imported Config

Profiles let you keep related settings grouped by environment. For example, application-prod.yml is loaded when the prod profile is active.

1spring:
2  config:
3    activate:
4      on-profile: prod
5
6server:
7  port: 8443

Run the application with:

java -jar app.jar --spring.profiles.active=prod

Spring Boot also supports imported config data. That is useful when you need to pull settings from an external file path or platform-provided location:

spring.config.import=optional:file:/etc/myapp/secrets.properties

This keeps sensitive or deployment-specific settings out of the packaged application.

Common Pitfalls

One common mistake is mixing too many configuration formats in the same project. Spring Boot supports both .properties and YAML, but consistency makes troubleshooting easier.

Another mistake is assuming an external file is loaded when it is actually in the wrong location or profile. If a property does not seem to apply, check active profiles and the property source order first.

Developers also often overuse @Value for grouped settings. It works, but it becomes fragile as configuration grows. Structured binding with @ConfigurationProperties is easier to test and refactor.

Finally, do not treat external configuration as a secure secret store by itself. Environment variables and files can still leak. For sensitive values, combine external config with a proper secret-management system.

Summary

• Spring Boot supports external configuration from files, environment variables, and command-line arguments.
• Packaged defaults can be overridden by environment-specific external values.
• '@ConfigurationProperties is the preferred way to bind grouped settings into typed Java classes.'
• Profiles and spring.config.import help organize environment-specific configuration.
• Most configuration bugs come from misunderstanding precedence, active profiles, or file locations.