Introduction

Spring Boot can load configuration from several property files, but the right mechanism depends on why you are splitting the config. Profile-specific files work best for environment overrides. Imported files work best for grouping related settings. External locations work best when operations teams need to change values without rebuilding the jar.

Use Profile-Specific Files for Environments

The most common setup is one shared file plus one file per environment:

• 'application.properties'
• 'application-dev.properties'
• 'application-prod.properties'

Put defaults in the base file and environment-specific overrides in the profile files.

1# application.properties
2app.name=demo
3logging.level.root=INFO
4feature.audit=false

# application-dev.properties
logging.level.root=DEBUG
feature.audit=true

Enable a profile at startup:

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

This pattern is predictable and built into Boot. It should be your first choice when the only difference is environment.

Import Additional Property Files by Concern

If the goal is modularity rather than environment separation, use spring.config.import. This lets you break configuration into smaller files such as database, messaging, or feature settings.

# application.properties
spring.config.import=classpath:database.properties,classpath:messaging.properties

# database.properties
db.pool.size=10
db.timeout.seconds=30

# messaging.properties
messaging.queue=jobs
messaging.retries=5

This keeps one file from becoming a thousand-line dump of unrelated keys.

If a file is optional, mark it that way:

spring.config.import=optional:file:/etc/myapp/override.properties

That is useful when a deployment may or may not mount an extra file.

Load External Files Without Rebuilding

Some values should not live in the packaged artifact at all. For those cases, point Boot at an external directory or file.

java -jar app.jar \
  --spring.config.additional-location=file:/etc/myapp/

This is a good fit for deployment-specific configuration that changes independently of code. It also helps keep operational settings out of the classpath when the application is promoted across environments.

Use @PropertySource Carefully

@PropertySource still exists, but it is usually better for custom bean configuration than for core Boot startup settings. If you need a configuration class to read an extra property file, it can be appropriate:

1import org.springframework.context.annotation.Configuration;
2import org.springframework.context.annotation.PropertySource;
3
4@Configuration
5@PropertySource("classpath:feature-flags.properties")
6public class FeatureFlagsConfig {
7}

However, for main application configuration, Boot's standard config loading rules are usually clearer. Relying on @PropertySource for everything makes startup behavior harder to reason about.

Understand Precedence Before Splitting Files

Multiple files only stay maintainable if everyone knows which source wins. Typical high-level precedence looks like this:

1. command-line arguments
2. external config files
3. profile-specific packaged files
4. base packaged files

That means duplicate keys are not merged in a magical way. One value wins according to precedence. If you split config across several files without documenting this, debugging turns into guesswork.

A Practical Layout

For many applications, a clean structure looks like this:

1. application.properties for stable defaults
2. application-dev.properties and application-prod.properties for environment overrides
3. imported module files for large config groups
4. external files or secret stores for deployment-only sensitive data

This gives you separation without making startup behavior obscure.

Common Pitfalls

• Using @PropertySource for core Boot settings when standard Boot config loading would be clearer.
• Splitting keys across many files without documenting precedence.
• Duplicating the same property in several places and then guessing which one is active.
• Bundling secrets into source-controlled classpath files.
• Mixing profiles, imports, and external locations without a clear reason for each.

Summary

• Spring Boot supports multiple property files through profiles, imports, and external locations.
• Use profile files for environment-specific overrides.
• Use spring.config.import to group related settings into focused files.
• Use external locations when config should change without rebuilding the app.
• Keep the precedence model clear so another engineer can predict startup behavior quickly.