Spring Boot Configuration Loading Order (Production Guide)

Spring Boot reads configuration from multiple sources —
but the order in which these sources are applied matters.

Understanding this order helps you:

• Predict final property values
• Avoid configuration overrides going unnoticed
• Diagnose environment-specific bugs
• Secure your application configuration

This guide explains Spring Boot’s configuration loading order in a practical, production-ready way, with examples and best practices.

What Is Configuration Loading Order?

Spring Boot supports configuration from:

• Properties files
• YAML files
• Environment variables
• Command-line arguments
• Profile-specific files
• External config servers

However, these sources are not treated equally — Spring Boot applies them in a specific order.

Knowing this order is key to controlling how your application behaves in different environments.

Default Configuration Sources

By default, Spring Boot will look for configuration files in:

In Classpath

• application.properties
• application.yml

Located in:

src/main/resources/

These provide your base configuration.

Profile-Specific Configuration

Spring Boot also supports profile-specific files:

• application-dev.yml
• application-test.yml
• application-prod.yml

When a profile is active, Spring Boot loads:

1. Default config
2. Profile-specific config

Example:
If prod profile is active:

• application.yml
• then application-prod.yml

This lets profile settings override defaults.

Configuration Loading Precedence (Order of Priority)

Spring Boot applies configuration sources in this order (high → low):

1. Command-line arguments
2. Java system properties (-D properties)
3. OS environment variables
4. Profile-specific application config
5. Application config (application.yml / .properties)
6. Default values in Spring Boot

This means that a value defined in the environment can override the same value in the file.

How Profiles Affect Loading

You specify active profiles using:

• spring.profiles.active property
• Environment variables
• Command line

Example:

SPRING_PROFILES_ACTIVE=prod

Spring Boot then loads:

• application.yml
• application-prod.yml
• environment overrides

If the same property exists in multiple places, the last applied wins.

Using Environment Variables and Profiles Together

In production environments (like Docker or Kubernetes), using environment variables is common.

Example:

SPRING_PROFILES_ACTIVE=prod
SERVER_PORT=9000
DATABASE_URL=jdbc:...

Spring Boot picks up all of these in the correct order and applies them consistently.

This approach is both secure and scalable.

Command-Line Overrides

If you run your application with:

java -jar app.jar --server.port=8081

This overrides:

• application.yml
• profile config
• environment variables

Command-line args have highest precedence.

External Configuration Locations

Spring Boot also supports external configuration locations.

Example:

spring.config.location=/etc/app/conf/

This helps separate configuration from the packaged jar — essential for production deployments.

Properties here typically override packaged configuration.

Understanding Property Source Order at Runtime

To debug the final value of a single property, you can enable logging:

logging.level.org.springframework.core.env=DEBUG

This prints property resolution details and shows exactly which source provided which value.

Real-World Examples

Example 1: Dev vs Prod Port

application.yml:

server:
  port: 8080

application-dev.yml:

server:
  port: 8081

spring.config.activate.on-profile=dev

If dev profile is active → final port is 8081.

Example 2: Environment Variable Override

Environment:

SERVER_PORT=9000

Even if application-prod.yml says 8080, the environment value wins.

Best Practices for Production

1. Avoid Hardcoding Secrets

Never store sensitive values inside config files in Git.
Use environment variables or secret managers.

2. Use Profiles Consistently

Define specific behavior for:

• dev
• test
• prod

Keep config DRY and maintainable.

3. Validate Effective Configuration

Use logging or health endpoints to expose active profiles and effective configurations.

Common Mistakes Developers Make

Overlooking Environment Variables

Relying only on files leads to confusing bugs in cloud or container environments.

Confusing Profiles with Conditional Logic

Profiles control which config files load, not when beans are created. For that, use @Profile.

How This Topic Connects to Your Spring Boot Knowledge

Configuration loading order is closely related to:

• Spring Boot startup flow:
  https://springbootfixes.com/how-spring-boot-application-starts-startup-flow-explained/
• Profiles and environments:
  https://springbootfixes.com/spring-boot-configuration-and-profiles-explained-beginner-to-production-guide/
• Properties vs YAML:
  https://springbootfixes.com/application-properties-vs-application-yml-in-spring-boot-when-and-why-to-use-each/

These form the core configuration understanding you need before moving to bean errors, DI, and production debugging.

Frequently Asked Questions

Does Spring Boot prefer .yml over .properties?

No — both formats are supported equally. YAML is just more readable for hierarchical config.

What happens if the same property exists in multiple sources?

Spring Boot uses the source with the highest precedence based on the loading order.

Can configuration values be changed without redeploying?

Yes — using environment variables or externalized config locations.

Summary

Spring Boot configuration loading order is a key part of understanding how your application behaves across environments.

When you understand:

• how properties are resolved
• how profiles influence overrides
• how environment and command line values fit in

…you gain full control of your deployment behavior.