@Profile-Based Beans in Spring / Spring Boot

In Spring and Spring Boot, @Profile-based beans are beans that are created only when a specific Spring profile is active.

In simple words:

@Profile = Load this bean only for a specific environment

Profiles help Spring decide which beans to load and which to ignore at application startup.

Why Do We Need @Profile?

Different environments need different configurations.

Real-World Environments

Without Profiles

• Developers manually change code
• High risk of deploying wrong config

With @Profile

• Spring loads correct beans automatically
• Clean, safe, and production-ready setup

What Is a Spring Profile?

A Spring Profile is a named logical group of beans.

• Beans are loaded only if their profile is active
• Multiple profiles can be active at the same time

Common Profile Names

dev, test, qa, prod, default

Default Behavior (Without @Profile)

If @Profile is not used, the bean is created in all environments.

@Component
publicclassEmailService {
}

✔ Always loaded

❌ No environment control

How @Profile Works Internally

1. Spring application starts
2. Reads active profile(s)
3. Matches profile with bean definitions
4. Creates only matching beans
5. Ignores non-matching beans

• Decision happens before bean creation
• No runtime overhead

Using @Profile on a Bean (Class Level)

The @Profile annotation can be applied directly on a bean class to control when the bean should be created based on the active Spring profile.

Example

@Component
@Profile("dev")
publicclassDevEmailService {
}

Explanation

• This bean belongs to the dev profile
• Spring checks the active profile at application startup
• The bean is created only if the dev profile is active
• If any other profile is active, Spring ignores this bean

Behavior Table

Multiple Implementations Using @Profile

A common and recommended use of @Profile is to provide different implementations of the same interface for different environments.

This approach avoids if-else logic, keeps the code clean, and follows SOLID principles.

1. Interface

publicinterfacePaymentService {
voidpay();
}

• Defines a common contract
• Business code depends on the interface, not the implementation

2. Dev Implementation

@Service
@Profile("dev")
publicclassDevPaymentServiceimplementsPaymentService {

@Override
publicvoidpay() {
        System.out.println("Dev payment processing");
    }
}

• Loaded only when dev profile is active
• Usually used for:
  • Mock payments
  • Sandbox APIs
  • Testing logic

3. Prod Implementation

@Service
@Profile("prod")
publicclassProdPaymentServiceimplementsPaymentService {

@Override
publicvoidpay() {
        System.out.println("Prod payment processing");
    }
}

• Loaded only when prod profile is active
• Used for:
  • Real payment gateways
  • Live transactions

4. Result (At Runtime)

Spring automatically injects the correct implementation.

5. Why This Is a Best Practice

• No if-else or profile checks in business code
• Clean separation of environments
• Easy to test and maintain
• Follows Dependency Inversion Principle
• Safe for production deployments

6. How Business Code Looks (Profile-Agnostic)

@Service
publicclassOrderService {

privatefinal PaymentService paymentService;

publicOrderService(PaymentService paymentService) {
this.paymentService = paymentService;
    }

publicvoidplaceOrder() {
        paymentService.pay();
    }
}

• No knowledge of dev or prod
• Spring decides which implementation to inject

Using @Profile with @Configuration and @Bean

The @Profile annotation can also be used on @Bean methods inside a @Configuration class.

This is commonly used for environment-specific infrastructure beans, such as databases.

Example

@Configuration
publicclassAppConfig {

@Bean
@Profile("dev")
public DataSourcedevDataSource() {
returnnewH2DataSource();
    }

@Bean
@Profile("prod")
public DataSourceprodDataSource() {
returnnewMySQLDataSource();
    }
}

How It Works

• Spring checks the active profile at startup
• If profile = dev
  • devDataSource() is executed
  • H2 DataSource bean is created
• If profile = prod
  • prodDataSource() is executed
  • MySQL DataSource bean is created
• The other method is ignored

Activating a Profile

Spring profiles must be explicitly activated so that Spring knows which beans and configurations to load.

1. Using application.properties

spring.profiles.active=dev

• Activates the dev profile
• Most common and simplest approach
• Suitable for local development

2. Using Profile-Specific Property Files

application-dev.properties
application-prod.properties

• Spring automatically loads the file that matches the active profile
• Example:
  • dev → application-dev.properties
  • prod → application-prod.properties
• Profile-specific properties override application.properties

3. Using Command Line Arguments

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

• Useful for:
  • CI/CD pipelines
  • Docker containers
  • Production deployments
• Overrides values defined in property files

4. Using Environment Variables

SPRING_PROFILES_ACTIVE=prod

• Preferred in cloud platforms (AWS, Kubernetes, Docker)
• Keeps configuration outside the codebase

Priority Order (Highest to Lowest)

1. Command line arguments
2. Environment variables
3. application.properties
4. Default profile

Multiple Active Profiles

Spring allows multiple profiles to be active at the same time.

This is useful when your application needs combined configurations (e.g., environment + cloud).

Activating Multiple Profiles

spring.profiles.active=dev,cloud

• Both dev and cloud profiles are active
• Spring evaluates beans against all active profiles

Bean with Multiple Profiles

@Component
@Profile({"dev", "cloud"})
publicclassCloudDevService {
}

How It Works

• Spring checks the active profiles
• If any one of the listed profiles matches:
  • The bean is created
• If none match:
  • The bean is ignored

When to Use Multiple Profiles

• Cloud-specific features
• Dev + cloud configurations
• Feature combinations
• Microservices deployments

NOT (!) Profile Condition

Spring allows you to exclude a profile using the ! (NOT) operator in @Profile.

This means the bean will be created for all profiles except the specified one.

Example

@Component
@Profile("!prod")
publicclassNonProdLogger {
}

How It Works

• Spring checks the active profile at startup
• If the active profile is prod → bean is NOT created
• If any other profile is active → bean IS created

Default Profile

If no profile is set, Spring uses default.

@Component
@Profile("default")
publicclassDefaultService {
}

✔ Loaded only when no profile is active

Profile-Specific Property Loading Order

When a Spring profile is active, Spring loads configuration files in a fixed and predictable order.

Example: Active Profile = dev

1. application.properties
2. application-dev.properties (overrides default values)

• Default values come first
• Profile-specific values override them
• Safe and predictable configuration behavior

Profile Groups (Spring Boot 2.4+)

Profile groups allow you to activate multiple related profiles using a single name.

Example

spring.profiles.group.dev=dev,cloud,debug
spring.profiles.group.prod=prod,security

spring.profiles.active=dev

How It Works

• Activating dev automatically activates:
  • dev
  • cloud
  • debug
• No need to list profiles manually

Why Profile Groups Are Useful

• Cleaner configuration
• Fewer deployment mistakes
• Ideal for microservices and cloud environments

Using @Profile in Tests

Spring allows activating profiles only for test execution.

Example

@SpringBootTest
@ActiveProfiles("test")
publicclassPaymentServiceTest {
}

Behavior

• Only beans with @Profile("test") are loaded
• Prod and dev beans are ignored
• Test environment stays isolated

✔ Essential for JUnit and integration testing

Combining @Profile with @Lazy

You can combine @Profile with @Lazy for environment-based and on-demand initialization.

Example

@Component
@Profile("prod")
@Lazy
publicclassHeavyProdService {
}

Behavior

• Bean is created only in prod profile
• Initialization happens only when first used
• Reduces startup time and memory usage

✔ Best for heavy, optional production components

@Profile vs @ConditionalOnProperty (Real Use Cases)

Spring provides multiple ways to conditionally create beans, but @Profile and @ConditionalOnProperty are commonly used for different purposes.

Comparison Table

Example: @ConditionalOnProperty

@Component
@ConditionalOnProperty(
    name = "feature.payment.enabled",
    havingValue = "true"
)
publicclassPaymentService {
publicPaymentService() {
        System.out.println("PaymentService created!");
    }
}

• Bean is created only if feature.payment.enabled=true
• Used for feature toggles or optional modules

Key Recommendations

• Use @Profile for environment-specific beans
  • Example: dev database vs prod database
• Use @ConditionalOnProperty for feature flags
  • Example: Enable or disable new features without changing the environment

Spring Boot Auto-Configuration

Spring Boot automatically configures beans based on:

• Classpath: detects available libraries
• Properties: values from application.properties or application-<profile>.properties
• Active profiles: environment-specific configuration

How Profiles Affect Auto-Configuration

• Active profiles determine which auto-configurations are enabled or disabled
• Examples:
  • prod → Real database auto-configuration
  • dev → Embedded database auto-configuration

Microservices Environment Strategy

• Maintain one codebase for all environments
• Use different profiles to control behavior:

• Simplifies deployments
• Cloud & Kubernetes-friendly
• Reduces code duplication

Common Mistakes to Avoid

• Forgetting to set spring.profiles.active
• Defining multiple beans of the same type without profiles
• Mixing profile logic directly into business code

Best Practices

• Use profiles only for environment-specific differences
• Keep business logic profile-agnostic
• Use one interface → multiple profile implementations
• Prefer configuration over code changes for environment-specific setups

Conclusion

@Profile-based beans allow Spring applications to load only the beans required for a specific environment.

They help you:

• Avoid manual configuration changes
• Prevent production mistakes
• Write clean, scalable, and maintainable code
• Build enterprise and microservice-ready applications