Introduction

Spring Boot already supports profile-specific files such as application-dev.yml and application-prod.yml, but larger applications often need more than one configuration file per environment. The modern way to do that is to keep one logical profile active and import additional config files from that profile's main configuration.

In current Spring Boot versions, spring.config.import is usually the right tool. It is clearer than trying to fake one environment with many profiles or scattering configuration through several unrelated mechanisms.

The Default Spring Boot Model

Out of the box, Spring Boot loads:

• 'application.properties or application.yml'
• then profile-specific variants such as application-prod.yml

That is enough until one profile grows into a very large file containing database settings, mail settings, feature flags, integration endpoints, and local overrides. At that point, splitting by concern becomes easier to maintain.

Use spring.config.import Inside the Profile File

A clean pattern is to keep application-prod.yml as the profile entry point and import focused config files from there.

1spring:
2  config:
3    import:
4      - "classpath:db-prod.yml"
5      - "classpath:mail-prod.yml"
6      - "optional:file:./config/prod-overrides.yml"
7
8app:
9  environment-name: production

When prod is active, Spring Boot loads the base config, then application-prod.yml, then the imported files.

You can activate the profile in the usual way:

SPRING_PROFILES_ACTIVE=prod ./mvnw spring-boot:run

This keeps the meaning of prod simple while still letting configuration live in several files.

Why Not Activate Several Profiles Instead

Some teams try to model one environment by activating several profiles such as prod, db, and mail. That can work, but it usually mixes two different concerns:

• environment selection
• configuration modularity

If the files all belong to production, one active profile plus imports is easier to reason about than three or four profiles that only exist to simulate file splitting.

Use multiple active profiles when they express real independent dimensions of behavior. Do not use them only as a workaround for file organization.

@PropertySource Is Usually Not the Best Primary Tool

You can load extra property files with @PropertySource, but it is better suited to narrower bean configuration cases than to central application configuration.

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

The main drawback is timing and visibility. Properties loaded this way may arrive too late for some bootstrap decisions, and the full configuration picture becomes harder to trace as the application grows.

For most profile-level file splitting, spring.config.import is the cleaner and more modern answer.

Watch Property Precedence

Once you import several files, precedence matters. If the same key appears in multiple sources, the later one wins.

That can be helpful for deliberate overrides, but it can also hide mistakes. A good discipline is:

• keep files focused by concern
• avoid defining the same property in several places
• document intentional override order

For example:

• 'db-prod.yml for datasource settings'
• 'mail-prod.yml for mail transport settings'
• 'prod-overrides.yml for deployment-specific values outside version control'

That structure reduces accidental overlap.

External Files Are Often Worth It

For sensitive or environment-specific overrides, importing an external file can be cleaner than keeping everything in the packaged artifact.

1spring:
2  config:
3    import:
4      - "optional:file:/etc/myapp/prod-secrets.yml"

The optional: prefix is useful when the application should still start without that file in some environments.

Common Pitfalls

The biggest mistake is using many profiles just to simulate multiple files for one environment. Another is relying on @PropertySource for configuration that should participate in the main Spring Boot config loading process. Teams also get into trouble when several imported files define the same keys and nobody documents which one is supposed to win. Finally, mixing classpath files, external files, and secret injection without a clear precedence plan makes incidents harder to debug.

Summary

• Spring Boot supports multiple files per profile by importing them from the profile's main config file.
• 'spring.config.import is the preferred modern mechanism.'
• Keep one logical environment profile active unless multiple profiles represent real separate concerns.
• Use @PropertySource sparingly for narrower cases, not as the main profile-loading strategy.
• Organize imported files by concern and document override order.