Profiles for Environments
Switch configuration per environment with profiles.
Profiles for Environments is a free Spring Boot 4 Microservices & REST APIs lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Spring Boot 4 Microservices & REST APIs learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Profiles Exist
Real applications run in several environments — local, dev, staging, production — each needing different datasources, log levels, and feature toggles. Profiles let one codebase carry many configurations and activate the right set at runtime.
A profile is just a named label. Beans and property files can be tagged so they apply only when that profile is active.
Profile-Specific Property Files
Boot automatically loads application-{profile}.yml on top of the base application.yml. The profile file overrides matching keys while inheriting everything else.
# application.yml (base, always loaded)
spring:
jpa:
show-sql: false
# application-dev.yml (loaded when dev active)
spring:
jpa:
show-sql: true
datasource:
url: jdbc:h2:mem:devdbActivating a Profile
Set spring.profiles.active to choose which profiles run. You can do this in a file, as an environment variable, or on the command line.
# Command line
java -jar app.jar --spring.profiles.active=prod
# Environment variable
export SPRING_PROFILES_ACTIVE=prod
# Multiple profiles
java -jar app.jar --spring.profiles.active=prod,metricsConditional Beans with @Profile
@Profile on a bean or configuration class makes it register only when that profile is active. This is ideal for swapping implementations between environments.
@Configuration
public class PaymentConfig {
@Bean
@Profile("prod")
public PaymentGateway liveGateway() {
return new StripeGateway();
}
@Bean
@Profile("!prod")
public PaymentGateway fakeGateway() {
return new InMemoryGateway();
}
}Profile Expressions
The @Profile value supports simple logic: ! for NOT, & for AND, and | for OR. Group expressions with parentheses.
@Profile("!prod") // anything except prod
@Profile("prod & metrics") // both active
@Profile("dev | test") // either active
@Profile("prod & (eu | us)") // groupedThe Default Profile
When no profile is active, Spring enables the implicit default profile. You can target it explicitly with @Profile("default") for fallback beans used during plain local runs.
@Bean
@Profile("default")
public DataSeeder localSeeder() {
return new SampleDataSeeder();
}Profile Groups
A profile group bundles several profiles under one name, so activating the group activates them all. Great for composing cross-cutting concerns.
spring:
profiles:
group:
production:
- prod
- metrics
- swagger-off
# Now: --spring.profiles.active=production turns on all threeIncluding Profiles
spring.profiles.active sets the primary profiles, while spring.profiles.include adds extra ones unconditionally, regardless of which primary profile is selected.
spring:
profiles:
include:
- common-logging
- auditInspecting Active Profiles at Runtime
You can read active profiles from the Environment bean. This is useful for guard logic or for logging which configuration is live.
@Component
public class StartupLogger {
private final Environment env;
public StartupLogger(Environment env) { this.env = env; }
@PostConstruct
void log() {
System.out.println("Active: "
+ String.join(",", env.getActiveProfiles()));
}
}Profiles in Tests
In integration tests, annotate the class with @ActiveProfiles to force a specific configuration, such as an in-memory database profile.
@SpringBootTest
@ActiveProfiles("test")
class OrderServiceTest {
// loads application-test.yml + @Profile("test") beans
}Common Pitfalls
Watch for these mistakes:
- Forgetting to set
spring.profiles.activein production, so dev defaults leak in - Putting secrets in
application-dev.ymland committing it - Overusing
@Profilewhere a simple property toggle would do
Quick Check
Test your grasp of profile expressions.
Recap
Profiles tailor one codebase to many environments.
application-{profile}.ymloverrides base config- Activate via
spring.profiles.active(file, env var, or CLI) @Profileconditionally registers beans, with!,&,|expressions- Profile groups bundle related profiles
- Use
@ActiveProfilesin tests
Frequently asked questions
Is the “Profiles for Environments” lesson free?
Yes — the full text of “Profiles for Environments” is free to read here on the web, and the Spring Boot 4 Microservices & REST APIs course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Spring Boot 4 Microservices & REST APIs course, upgrade to CoddyKit PRO.
What will I learn in “Profiles for Environments”?
Switch configuration per environment with profiles. You practise Spring Boot 4 Microservices & REST APIs with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Spring Boot 4 Microservices & REST APIs?
No prior experience is required. Spring Boot 4 Microservices & REST APIs on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Profiles for Environments” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Spring Boot 4 Microservices & REST APIs lesson?
Yes. Every Spring Boot 4 Microservices & REST APIs lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.