skip to content

How do profile-specific config files like application-{profile}.yaml load and override the base application.yaml?

level: middleimportance: must knowfreq 65%

answer

  1. Base always loads, then profile files layer on top
  2. Profile-specific keys override base; others inherited
  3. active=a,b -> b wins over a
  4. Can't set active inside a profile file
  5. External location beats classpath

basics

~10 s

Spring Boot always loads application.yaml first, then loads application-{profile}.yaml for each active profile on top of it. Values in the profile-specific file override the same keys in the base file.

solid answer

~40 s

Spring Boot loads the base application.yaml/properties unconditionally, then for every active profile it loads the matching application-{profile}.yaml layered on top. Profile-specific properties have higher precedence, so they override the same keys from the base file; keys not overridden are inherited. If multiple profiles are active (e.g. active=prod,metrics), the files load in the order the profiles are listed, so later-listed profiles win on conflicts. This is Boot's config-data mechanism (Boot 2.4+), applied per config location (classpath, then external ./config etc.). Profile files never replace the base file — they merge over it. The active profile itself cannot be declared inside a profile-specific document; you set it in the base file, via property, or with spring.profiles.group.

code

java · 11 lines
java
// application.yaml (base — always loaded)
// server.port: 8080
// app.feature.cache: false

// application-prod.yaml (loaded when prod active)
// server.port: 80        <-- overrides base 8080
// app.feature.cache: true <-- overrides base
// (app.other.key from base is inherited, not repeated)

// Run with: --spring.profiles.active=prod
// Effective: server.port=80, app.feature.cache=true

go deeper

for a junior

Knows profile files override the base file for matching keys.

for a middle

Must know ordering when multiple profiles are active and that base always loads.

for a senior

Understands config-data precedence across locations, .properties vs .yaml, and the 2.4+ activation restriction.

for a principal

Designs a config layering strategy (shared defaults + minimal per-env deltas) and secrets externalization across environments.

### The layering model Spring Boot's **Environment** is built from ordered **property sources**. Config files contribute sources with a defined precedence. The base `application.yaml`/`application.properties` is loaded **unconditionally**. Then, for each **active** profile `p`, Boot looks for `application-{p}.yaml`/`.properties` and adds it as a **higher-precedence** source. Higher precedence means: when the *same key* exists in both, the profile-specific value **wins**; keys present only in the base are **inherited**. ### Multiple active profiles: ordering With `spring.profiles.active=prod,metrics`, both `application-prod.yaml` and `application-metrics.yaml` load. The **order profiles are listed matters**: later-listed profiles take precedence on conflicting keys. So `metrics` overrides `prod` overrides base. ### Where files are searched Boot searches several **config locations** in order (roughly: classpath root, classpath `/config`, current dir, current dir `/config`, plus anything in `spring.config.location`/`spring.config.additional-location`). External locations override classpath ones. Within each location the base-then-profile layering applies. ### Boot 2.4+ config-data changes (important gotchas) - **Files are processed in the order they are discovered/imported**, and the *document order* now determines override behavior more strictly than the pre-2.4 model. - You **cannot activate a profile from within a profile-specific document**. E.g. putting `spring.profiles.active: foo` inside `application-dev.yaml` is invalid/ignored. Activation must come from the base file, an external property, or `spring.profiles.group`. - `spring.config.import` (e.g. importing extra files or config servers) is processed as part of this mechanism. ### `.properties` vs `.yaml` Both are supported. If both `application.properties` and `application.yaml` exist in the same location, `.properties` takes precedence over `.yaml` for the same keys (properties are loaded with higher priority). Prefer one format per project to avoid confusion. ### Practical rule of thumb Put shared defaults in `application.yaml`; put only the deltas per environment in `application-{profile}.yaml`. Never duplicate the whole config per profile — override just what differs.

  • If active=dev,prod and both files set server.port, which wins?
    application-prod.yaml, because it is listed last. Later-listed active profiles take precedence over earlier ones on conflicting keys.
  • Does application-prod.yaml replace application.yaml?
    No. The base file always loads; the profile file merges over it, overriding only matching keys and inheriting the rest.

saying these in an interview costs you the question

  • Thinking the profile file replaces rather than merges over the base
  • Assuming earlier-listed profile wins over later-listed
  • Trying to set spring.profiles.active inside application-{profile}.yaml

context

resolving links…