Application Properties and Profiles

Analogy categoryAnalogies

Externalized Configuration in Spring Boot

Spring Boot follows the principle of externalized configuration, meaning values like database URLs, thread pool sizes, and feature flags live outside compiled code in files such as application.properties or application.yml, environment variables, or command-line arguments. This lets the exact same JAR file run correctly in development, staging, and production simply by supplying different configuration values at each environment, rather than rebuilding the application for every deployment target. Spring Boot binds these external values into beans automatically through mechanisms like @Value, @ConfigurationProperties, and the Environment abstraction.

🏏

Cricket analogy: It's like a stadium's pitch report changing between matches — same ground, same rules of cricket, but the surface conditions (config) are set fresh for each fixture without rebuilding the stadium.

Property Sources and Precedence

Spring Boot resolves properties from many possible sources, and when the same key appears in multiple places, a well-defined precedence order decides which value wins: command-line arguments override environment variables, which override the profile-specific application-{profile}.properties, which override the base application.properties, which override @PropertySource-annotated files, which override default values set in code. This ordering exists so that operational overrides — like a Kubernetes deployment setting an environment variable — can always override a baked-in default without editing or rebuilding the JAR, which is essential for twelve-factor-style deployments.

🏏

Cricket analogy: It's like a DRS decision hierarchy — the on-field umpire's call is the default, but the third umpire's review overrides it, and the match referee's final ruling overrides even that if invoked.

Using Profiles for Environment-Specific Config

Profiles let you group configuration and beans that should only activate in specific environments, using files like application-dev.yml, application-staging.yml, and application-prod.yml alongside the base application.yml, activated via the spring.profiles.active property or the SPRING_PROFILES_ACTIVE environment variable. Beans can also be conditionally registered with @Profile('prod') so, for example, a real SMTP mail sender only wires up in production while a no-op logging mail sender wires up in dev, preventing test runs from accidentally emailing real customers. Multiple profiles can be active simultaneously, and Spring Boot merges their properties, with later-activated profiles taking precedence over earlier ones.

🏏

Cricket analogy: It's like a team fielding different XIs for Test, ODI, and T20 formats — same club, same core philosophy, but a distinct 'profile' of players activated for each format's specific demands.

yaml

# application.yml (base config, shared by all profiles)
spring:
  application:
    name: order-service
  profiles:
    active: dev

---
# application-dev.yml
spring:
  config:
    activate:
      on-profile: dev
  datasource:
    url: jdbc:h2:mem:devdb
logging:
  level:
    com.example: DEBUG

---
# application-prod.yml
spring:
  config:
    activate:
      on-profile: prod
  datasource:
    url: ${DATABASE_URL}
logging:
  level:
    com.example: WARN

Use @ConfigurationProperties(prefix = "app.mail") on a dedicated class instead of scattering @Value("${app.mail.host}") annotations across many beans. It gives you type-safe, IDE-autocompleted, validated configuration binding, and Spring Boot's configuration processor can even generate metadata for autocomplete in application.yml.

Externalized configuration lets one build artifact run correctly across dev, staging, and production.
Property precedence: command-line args > env vars > profile-specific files > base application.properties.
Profiles group environment-specific properties and beans using application-{profile}.yml files.
spring.profiles.active or SPRING_PROFILES_ACTIVE activates one or more profiles.
@Profile on a bean restricts its registration to specific active profiles.
@ConfigurationProperties offers type-safe, validated binding versus scattered @Value calls.
Multiple active profiles merge, with later ones taking precedence on conflicting keys.