@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

Environment	Typical Requirements
dev	H2 DB, mock APIs, debug logging
test	Test DB, test configurations
qa	Near-production setup
prod	MySQL/PostgreSQL, real APIs, security

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

Active Profile	DevEmailService Created
dev	Yes
prod	No
test	No
none (default)	No

---

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)

Active Profile	Loaded Bean
dev	DevPaymentService
prod	ProdPaymentService

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

Feature	@Profile	@ConditionalOnProperty
Based on	Environment (dev/test/prod)	Property value (application.properties / env)
Best for	Selecting environment-specific beans	Feature flags, optional features
Flexibility	Medium	High
Activation	Startup profile	Property values, can enable/disable features dynamically
Typical Use Case	dev vs prod services	feature.payment.enabled=true

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:

Environment	Services
dev	Local + mock services
qa	Staging services
prod	Real services

• 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