Spring Boot Project Setup & Auto-Configuration
Spring Boot Profiles — dev, staging, prod Configuration
Setting up profile-specific properties and active config environments dynamically.
Introduction
When building backend systems, you run your application in multiple environments: locally on developer laptops, on staging environments for quality assurance testing, and on production servers for live users. Each environment requires different configurations: local developers want lightweight, quick in-memory databases, staging requires QA setups, and production demands high-performance connection pooling and secure credentials.
Spring Boot solves this using **Profiles**. Profiles allow you to map configurations or partition bean registrations to specific active environments.
Why It Matters
Without profiles, you have to manually edit configuration values or swap properties before packaging the application, which is highly error-prone and can result in local test settings accidentally overwriting production configurations.
Real-World Analogy
Think of Spring Profiles like a **smart clothing package**. Depending on the weather profile active in the morning ("Winter", "Summer", or "Rain"), you pick a specific outfit. The person remains identical (the Java class files), but the active weather profile changes the outer gear (active properties, database drivers, or mail configurations) dynamically.
How It Works
Spring Boot enables profile-specific configurations using two main strategies:
- Profile-Specific Files: Alongside your default
application.yml, you can define files namedapplication-{profile}.yml(e.g.,application-dev.yml,application-prod.yml). When a profile is active, Spring Boot loads the profile-specific file, and its properties override any matching keys inside the default file. - Conditional Bean Filtering: You can apply the
@Profileannotation directly to configurations or service classes. A component annotated with@Profile("prod")will only be loaded and registered as a bean in the container if the "prod" profile is active.
Profiles are activated using the command-line argument:
java -jar app.jar --spring.profiles.active=prod
Practical Example
Here is how to register different service beans (mock vs production) depending on the active environment profile:
Quick Quiz
Q1: What happens if you define a bean with @Profile("!prod") annotation?
A) The bean is only loaded if the 'prod' profile is active.
B) The bean is loaded in all active profiles EXCEPT the 'prod' profile.
C) The application fails to boot with a profile syntax exception.
D) The bean is registered only during testing operations.
Answer: B — The exclamation mark (!) acts as a logical NOT operator, instructing Spring to register the bean under any profile sequence except 'prod'.
Q2: Which profile is active by default if no active profiles are specified during startup?
A) dev
B) prod
C) default
D) test
Answer: C — If unspecified, Spring Boot defaults the active profile to default, loading values from application-default.properties if present.
Scenario-Based Challenge
Production Scenario:
You want to define default logging patterns in a shared configuration file, but you need your production profile to log outputs only at the ERROR level, whereas development profiles should log at the detailed DEBUG level. How do you design this in a single application.yml file?
Modern Spring Boot supports multi-profile documents in a single YAML file using the document separator --- and the spring.config.activate.on-profile configuration:
Interview Questions
1. Conceptual: Can you activate multiple profiles simultaneously in Spring Boot? How do they resolve conflicts?
Yes, you can activate multiple profiles by passing a comma-separated list: -Dspring.profiles.active=dev,swagger. If conflicts occur, the last profile listed in the active array takes precedence and overrides properties set in the earlier ones.
2. Technical: How do you verify which profile is active programmatically inside a component class?
Inject the Spring Environment interface bean into your component and query the active profile names using environment.getActiveProfiles(), or inject the profiles list directly using standard SpEL: @Value("${spring.profiles.active}").
Production Considerations
In production pipelines, configure container environment variables (e.g. SPRING_PROFILES_ACTIVE=prod) to dictate the active profile, rather than packaging profile settings statically. Ensure that your staging profile matches production settings as closely as possible to catch environment-specific bugs prior to release.