Introduction

Spring Boot supports environment-specific configuration through profiles, letting the same application run with different settings in development, test, and production. The normal pattern is to keep shared values in application.properties and override selected keys in profile-specific files such as application-dev.properties or application-prod.properties.

How Profile-Specific Files Work

Spring Boot reads application.properties as the baseline configuration. If a profile is active, it also reads the matching profile file and overlays those values on top of the defaults.

A simple layout looks like this:

1src/main/resources/
2  application.properties
3  application-dev.properties
4  application-test.properties
5  application-prod.properties

That lets you define one set of common properties and then override only what changes by environment, such as database URLs, log levels, or external service endpoints.

Example Configuration

A typical base file contains values that are safe for all environments.

spring.application.name=demo-app
server.port=8080
logging.level.root=INFO

Then a development profile can override a subset:

1spring.datasource.url=jdbc:h2:mem:devdb
2spring.datasource.username=sa
3spring.datasource.password=
4logging.level.com.example=DEBUG

And a production profile can replace those with deployment-specific settings:

1spring.datasource.url=jdbc:postgresql://db.internal:5432/app
2spring.datasource.username=app_user
3spring.datasource.password=${DB_PASSWORD}
4logging.level.com.example=WARN

The key idea is that profile files override matching keys rather than replacing the whole configuration.

Activate A Profile

You can activate a profile in several common ways.

From the command line:

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

With an environment variable:

export SPRING_PROFILES_ACTIVE=prod
java -jar app.jar

In tests, Spring also supports annotations such as @ActiveProfiles("test") so test configuration is explicit and reproducible.

Prefer Defaults Plus Overrides

A good configuration strategy is to put stable defaults in application.properties and keep profile files small. That makes it obvious which values actually differ by environment.

If every profile file is a full copy of every property, configuration drifts easily and mistakes become harder to spot. Small override files are easier to review and safer to maintain.

Understand Property Precedence

Profile files are only one part of Spring Boot's configuration model. Command-line arguments, environment variables, and some external configuration sources can override values from packaged property files.

That is useful in deployment pipelines because you can keep a production profile in place while still overriding a few values, such as a database password or service URL, at deploy time without rebuilding the artifact.

Properties Versus YAML

The same profile mechanism works with YAML files. For example, application-prod.yml works the same way as application-prod.properties.

Choose one format and stay consistent inside the project. Teams often pick .properties for simple key-value files and YAML when the configuration tree is larger and more nested.

Handle Secrets Carefully

Profile-specific files are not a secure secret store. They are a convenient configuration layer, but production passwords, API keys, and certificates should usually come from environment variables, container secrets, or a dedicated secret-management system.

In the earlier example, ${DB_PASSWORD} keeps the password outside the source-controlled properties file while still letting Spring inject it at runtime.

Common Pitfalls

A common mistake is setting spring.profiles.active inside a profile file itself and creating confusing or circular configuration behavior. Activate profiles from the environment, command line, or startup configuration instead.

Another mistake is copying every property into every environment file. That removes the benefit of layered configuration and increases maintenance cost.

It is also easy to commit real production secrets into application-prod.properties. Profile-specific files are about organization, not security.

Summary

• Use application.properties for shared defaults and application-<profile>.properties for overrides.
• Activate profiles with spring.profiles.active from the command line, environment, or test configuration.
• Keep profile files small so only environment-specific values are overridden.
• YAML and properties both support the same profile-based approach.
• Store secrets outside source-controlled config files whenever possible.