Introduction

Spring Boot profiles let you keep one codebase while switching configuration for local development, testing, staging, or production. When you run the app from IntelliJ IDEA, the active profile is usually set through the run configuration rather than by editing source files.

What a Spring Profile Actually Changes

A profile tells Spring Boot which profile-specific properties and beans should be active. For example, dev might use an in-memory database and verbose logging, while prod might use a real database and stricter settings.

Typical configuration files look like this:

# application.properties
spring.application.name=demo
logging.level.root=INFO

# application-dev.properties
server.port=8081
app.payment.provider=mock

# application-prod.properties
server.port=8080
app.payment.provider=stripe

When the dev profile is active, values from application-dev.properties override the defaults where the keys overlap.

The Easiest IntelliJ Method: Program Arguments

For local development, the clearest way to activate a profile in IntelliJ is usually a program argument.

Open:

1. Run
2. Edit Configurations
3. your Spring Boot run configuration

Then add this in Program arguments:

--spring.profiles.active=dev

When you run the application, Spring Boot reads that argument just as it would from the command line.

This is a good default because the chosen profile is obvious in the run configuration, easy to change per developer, and easy to duplicate for multiple setups such as dev, test, or qa.

Other IntelliJ Options: Environment Variables and VM Options

You can also activate a profile with an environment variable:

SPRING_PROFILES_ACTIVE=dev

Set that in the run configuration's environment section.

Another option is a JVM system property in VM options:

-Dspring.profiles.active=dev

All three methods work. The real question is which one your team wants to standardize on.

Practical rule:

• use program arguments when you want the Spring Boot style to be explicit
• use environment variables when you want local runs to resemble containers or deployment systems
• use VM options only when the team already manages runtime flags there

Verify the Profile at Startup

Do not assume the profile was applied correctly just because IntelliJ shows the run configuration you expected. Print or log the active profile at startup.

1import org.springframework.boot.CommandLineRunner;
2import org.springframework.context.annotation.Bean;
3import org.springframework.core.env.Environment;
4
5@Bean
6CommandLineRunner logProfiles(Environment environment) {
7    return args -> {
8        String[] active = environment.getActiveProfiles();
9        System.out.println("Active profiles: " + String.join(", ", active));
10    };
11}

That small check saves time when multiple configuration sources compete with each other.

You can also prove that profile-specific beans are switching correctly:

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.context.annotation.Profile;
4
5interface MailClient {
6    String provider();
7}
8
9@Configuration
10class MailConfig {
11    @Bean
12    @Profile("dev")
13    MailClient devMailClient() {
14        return () -> "mock-mail";
15    }
16
17    @Bean
18    @Profile("prod")
19    MailClient prodMailClient() {
20        return () -> "smtp-mail";
21    }
22}

Running with dev activates the mock implementation, while prod activates the real one.

Keep Test Profiles Separate

IntelliJ run profiles are for application launches, but test classes should usually declare their own profile explicitly. That prevents local IDE settings from accidentally changing test behavior.

1import org.springframework.test.context.ActiveProfiles;
2
3@ActiveProfiles("test")
4class OrderServiceTest {
5}

That way, test execution stays stable whether the developer is currently running the app with dev or some other profile.

Common Pitfalls

The most common problem is setting the profile in more than one place and forgetting that Spring Boot has precedence rules. If Program arguments, environment variables, and VM options all define a profile, debugging becomes harder than it needs to be.

Another issue is editing application.properties to hard-code a local profile for convenience. That tends to leak machine-specific behavior into the project.

Developers also often forget to verify the active profile at startup. If the wrong configuration file is loaded, the app can look broken for reasons that are really just configuration mismatch.

Finally, avoid keeping secrets directly in committed profile files. Use environment variables, secret management, or external configuration for credentials and tokens.

Summary

• In IntelliJ, the simplest way to activate a Spring profile is usually --spring.profiles.active=dev.
• You can also use SPRING_PROFILES_ACTIVE or -Dspring.profiles.active=....
• Verify the active profile at startup instead of assuming the IDE configuration worked.
• Use profile-specific beans and property files to separate environment behavior cleanly.
• Keep test profiles explicit and keep secrets out of committed config files.