Spring Boot Profiles

Real applications need different configuration for local development, automated testing, staging, and production — different database URLs, different logging levels, different feature flags. Spring Profiles let you define named sets of configuration and beans that only activate for a chosen environment, without maintaining separate codebases.

Profile-Specific Configuration Files

Alongside the default application.properties (or application.yml), you can create application-{profile}.properties files — for example application-dev.properties and application-prod.properties. Values in the profile-specific file override or add to the base file when that profile is active. In application.yml, the same effect is achieved with multi-document files separated by --- and a spring.config.activate.on-profile key.

Activating a Profile

The active profile is set with the property spring.profiles.active=dev, which can be provided in application.properties, as a JVM argument (-Dspring.profiles.active=prod), as an environment variable (SPRING_PROFILES_ACTIVE=prod), or as a command-line argument when launching the jar. Multiple profiles can be active simultaneously as a comma-separated list, and later ones override earlier ones on conflicting keys.

Profile-Specific Beans

Beyond properties, the @Profile("dev") annotation on a @Bean method or @Component class restricts that bean to only be created when the named profile is active — useful for swapping a real payment gateway client for a mock one during local development and testing.

Profile Expressions: !, & and |

@Profile accepts simple expressions. @Profile("!prod") creates the bean in every environment except production, which is the safest way to declare a fake payment gateway: a new "staging" or "demo" profile automatically gets the fake one, and only prod can ever charge a real card. @Profile("prod & eu") needs both profiles, and @Profile("dev | test") needs either.

Profile Groups

Large applications often split production settings into several files, such as one for the database and one for mail. Instead of asking everyone to remember --spring.profiles.active=prod,prod-db,prod-mail, define a group in the base file: spring.profiles.group.prod=prod-db,prod-mail. Activating prod then switches on all three, and the startup log lists every one of them.

Which Value Wins

Properties from an active profile file override the same keys in application.properties, and keys that a profile file does not mention keep their base values. When several profiles are active and set the same key, the profile listed last wins: with dev,prod you get the prod value, and with prod,dev you get the dev value. When no profile is set at all, Spring Boot uses one called default and logs No active profile set, falling back to 1 default profile: "default".

When to Use Profiles, and When Not To

• Use them for real differences between environments: database URLs, log levels, which implementation of an interface is wired in, and whether test data is seeded.
• Use them in tests with @ActiveProfiles("test") on a test class, so tests get their own settings without touching the developer's local configuration.
• Do not use them for secrets. Passwords and API keys belong in environment variables or a secrets manager, which override files without being committed.
• Do not use them as feature flags. A profile is fixed for the whole run, so a setting you want to switch per customer or at runtime should be an ordinary property or a feature-flag service.

Examples

// application-dev.properties
spring.datasource.url=jdbc:h2:mem:devdb
logging.level.root=DEBUG

// application-prod.properties
spring.datasource.url=jdbc:postgresql://db.internal:5432/webnest
logging.level.root=WARN

// PaymentConfig.java
@Configuration
public class PaymentConfig {

    @Bean
    @Profile("dev")
    public PaymentGateway mockPaymentGateway() {
        return new MockPaymentGateway();
    }

    @Bean
    @Profile("prod")
    public PaymentGateway stripePaymentGateway() {
        return new StripePaymentGateway();
    }
}

// Run with: java -jar app.jar --spring.profiles.active=dev

... The following 1 profile is active: "dev"
... HikariPool-1 - Starting... url=jdbc:h2:mem:devdb
... Started WebnestAppApplication in 1.65 seconds

# application.properties
app.greeting=Hello from the base file
app.region=ap-south-1
spring.profiles.group.prod=prod-db,prod-mail

# application-dev.properties
app.greeting=Hello from dev

# application-prod.properties
app.greeting=Hello from prod

# application-prod-db.properties
app.db=managed postgres

// ProfileReport.java
@Configuration
public class ProfileReport {

    interface PaymentGateway { String name(); }

    @Bean
    @Profile("!prod")   // every environment except production
    PaymentGateway fakeGateway() { return () -> "fake gateway (no real charges)"; }

    @Bean
    @Profile("prod")
    PaymentGateway realGateway() { return () -> "real gateway"; }

    @Bean
    CommandLineRunner report(Environment env, PaymentGateway gateway,
                             @Value("${app.greeting}") String greeting,
                             @Value("${app.region}") String region,
                             @Value("${app.db:none}") String db) {
        return args -> {
            System.out.println("active=" + String.join(",", env.getActiveProfiles()));
            System.out.println("greeting=" + greeting + " | region=" + region + " | db=" + db);
            System.out.println("gateway=" + gateway.name());
        };
    }
}

$ java -jar app.jar
No active profile set, falling back to 1 default profile: "default"
active=
greeting=Hello from the base file | region=ap-south-1 | db=none
gateway=fake gateway (no real charges)

$ java -jar app.jar --spring.profiles.active=prod
The following 3 profiles are active: "prod", "prod-db", "prod-mail"
active=prod,prod-db,prod-mail
greeting=Hello from prod | region=ap-south-1 | db=managed postgres
gateway=real gateway

$ java -jar app.jar --spring.profiles.active=prod,dev
The following 4 profiles are active: "prod", "prod-db", "prod-mail", "dev"
active=prod,prod-db,prod-mail,dev
greeting=Hello from dev | region=ap-south-1 | db=managed postgres
gateway=real gateway

Exercise

A teammate is about to make this mistake: Forgetting to set spring.profiles.active anywhere and being confused why "default" configuration always loads instead of the intended dev/prod file. Use Profile-Specific Configuration Files to review the decision. Write a corrected implementation or design sketch that follows application-{profile}.properties/yml files override the base configuration when that profile is active., then name one edge case you would check.

Quick quiz

Interview questions