skip to content

Where does Spring Boot look for application.properties/application.yml by default, in what order, and how do profile-specific files fit in?

level: middleimportance: must knowfreq 65%

answer

  1. classpath:/, classpath:/config/, file:./, file:./config/
  2. Filesystem beats classpath
  3. profile file overrides plain; last active profile wins
  4. .properties beats .yml in same location
  5. location replaces vs additional-location adds

basics

~10 s

By default Spring Boot searches four locations: classpath root, classpath /config, the current working directory, and a ./config folder. Locations outside the jar override packaged ones, and profile-specific files (application-{profile}.properties) override the plain file.

solid answer

~40 s

Spring Boot loads 'config data' from these default locations, in increasing priority: classpath root (`classpath:/`), classpath `/config` package, the current directory (`file:./`), and the `./config/` directory (plus its immediate subdirectories). Filesystem locations override classpath ones, so an external `./config/application.properties` beats the one packaged in the jar. Within any location, profile-specific files like `application-prod.yml` override the plain `application.yml`, and among active profiles the last one listed wins. If both `.properties` and `.yml` exist in the same location, `.properties` takes precedence. You can replace the search list with `spring.config.location` (replaces defaults) or extend it with `spring.config.additional-location`, and import extra files via `spring.config.import`. This whole 'config data' bundle is still just one tier of the larger precedence order — env vars, system properties, and CLI args all outrank it.

code

kotlin · 19 lines
kotlin
// Default search order (increasing priority):
//   classpath:/            -> application.yml packaged in the jar (defaults)
//   classpath:/config/
//   file:./                -> external file next to the process
//   file:./config/         -> external override folder (highest of the four)
//
// Replace the default locations entirely:
//   java -jar app.jar --spring.config.location=optional:file:/etc/myapp/
//
// Add extra locations on top of the defaults (keeps defaults):
//   java -jar app.jar --spring.config.additional-location=file:/etc/myapp/
//
// Import an extra file from inside application.yml:
//   spring:
//     config:
//       import: "optional:file:/etc/myapp/extra.yml"
//
// Activate a profile so application-prod.yml is layered on top:
//   java -jar app.jar --spring.profiles.active=prod

go deeper

for a junior

Knows application.properties/yml lives in src/main/resources; may not know the four-location order.

for a middle

Should list the four default locations, the filesystem-over-classpath rule, and profile-specific overriding.

for a senior

Should discuss spring.config.location vs additional-location vs import, and multi-profile last-wins ordering.

for a principal

Designs the layering: packaged defaults + external/env overrides, avoiding surprising CWD-relative resolution in containers.

## What 'config data' means Since Spring Boot 2.4, `application.properties` and `application.yml` (and their profile variants) are loaded by the **Config Data** mechanism (`ConfigDataEnvironmentPostProcessor`). Together they form one tier in the overall property-source precedence — a tier that sits *below* environment variables, system properties, `SPRING_APPLICATION_JSON`, and command-line arguments, but above framework defaults. ## The four default locations With no customization, Spring Boot searches these locations (the effective default of `spring.config.location`), each wrapped as `optional:` so a missing one is not an error: 1. `classpath:/` — root of the classpath (e.g. `src/main/resources/application.properties` packaged in the jar) 2. `classpath:/config/` — a `config` package on the classpath 3. `file:./` — the current working directory where the process runs 4. `file:./config/` — a `config` subdirectory of the working directory, **and its immediate child directories** (`file:./config/*/`) **Precedence increases down this list.** So a `config` value in `file:./config/application.properties` (an external file next to your running process) overrides the same key in the jar-packaged `classpath:/application.properties`. This is deliberate: it lets ops drop an override file beside the deployed jar without rebuilding it. ## `.properties` vs `.yml` in the same location If you have **both** `application.properties` and `application.yml` in the *same* location, the `.properties` file takes precedence for overlapping keys. Best practice is to pick one format per project to avoid confusion. ## Profile-specific files For each location, Spring Boot also loads `application-{profile}.properties` / `application-{profile}.yml` when that profile is active (set via `spring.profiles.active`, `SPRING_PROFILES_ACTIVE`, or `--spring.profiles.active=...`). - Profile-specific files **override** the non-profile-specific `application.properties` in the same location. - If multiple profiles are active, they are applied in listed order and **the last profile listed wins** on conflicts (e.g. with `spring.profiles.active=prod,eu`, `application-eu` overrides `application-prod`). - A single YAML file can hold multiple profile documents separated by `---`, each guarded by `spring.config.activate.on-profile`. ## Customizing the search - `spring.config.location` — **replaces** the default location list entirely. Prefix a path with `optional:` to tolerate its absence; a location ending in `/` is treated as a directory, otherwise as a specific file. - `spring.config.additional-location` — **adds** locations that take priority over the defaults, without discarding them (safer than replacing). - `spring.config.name` — change the base filename from `application` to something else. - `spring.config.import` — pull in additional documents (other files, `configtree:` mounted secrets, external config servers). Note these config-influencing keys must themselves be set early (env var / system property / CLI), since they steer where the files come from. ## Gotchas - **Working directory is the process CWD, not the project root.** In containers/services `file:./config/` resolves relative to wherever the JVM was launched. - **`.yaml` vs `.yml`:** Spring Boot recognizes `.yml`; `.yaml` also works, but be consistent. - **YAML has no `@PropertySource` support** — you cannot load a YAML file via `@PropertySource`; use config-data locations or `spring.config.import`. - Missing default locations are silently optional; a *custom* `spring.config.location` without `optional:` that points at a non-existent file will fail startup. ## When to use what Package sensible defaults in `classpath:/application.yml`; keep per-environment overrides in profile-specific files or external `./config/` files or, better for cloud, in environment variables that outrank all of these.

  • You put application.properties in ./config/ next to the running jar but it doesn't override the packaged one — why might that be?
    The working directory is the process CWD, not necessarily where the jar file sits. `file:./config/` resolves against wherever the JVM was launched, so if you started the process from a different directory the external file isn't found. Verify with an absolute `spring.config.additional-location`.
  • What's the difference between spring.config.location and spring.config.additional-location?
    `spring.config.location` replaces the entire default search list (you lose classpath:/ etc. unless you re-add them), while `spring.config.additional-location` prepends extra high-priority locations while keeping the defaults. The additional form is safer for adding an override folder.

saying these in an interview costs you the question

  • Claiming Spring only reads src/main/resources/application.properties
  • Saying classpath files override external filesystem files (it's the reverse)
  • Thinking application.yml overrides application.properties in the same location (properties wins)
  • Believing the first active profile wins on conflict rather than the last

context

resolving links…