Profiles
Master Spring Profiles for environment-specific configuration — separating dev, test, staging, and production settings without code changes.
Last reviewed: January 2025
🔍 What Is It?
Spring Profiles provide a way to segregate parts of your application configuration and make it only available in certain environments.
Profile-specific config files:
- →
application.yml— defaults for all profiles - →
application-dev.yml— dev overrides - →
application-test.yml— test overrides - →
application-staging.yml— staging overrides - →
application-prod.yml— production overrides
Profile-specific beans:
- →
@Profile("dev")— only register this bean in dev - →
@Profile("!prod")— register in all profiles except prod - →
@Profile({"dev", "test"})— register in dev and test
Activation:
- →
SPRING_PROFILES_ACTIVE=prod(environment variable — production) - →
--spring.profiles.active=dev(command line) - →
spring.profiles.active=dev(application.properties — never for prod) - →
@ActiveProfiles("test")(tests)
🎯 Why Do We Need It?
Without profiles, you'd either:
- →Have one config file with if/else logic (messy)
- →Manually edit properties before each deployment (error-prone)
- →Have different code branches per environment (unmaintainable)
Profiles provide a clean, declarative way to manage environment differences.
🏗️ What Happens in Real Projects?
Standard enterprise profile setup:
- →dev: H2 in-memory DB, DEBUG logging, all Actuator endpoints exposed, hot reload
- →test: Testcontainers or H2, INFO logging, no external services
- →staging: Real database (staging), INFO logging, same config as prod
- →prod: Production database, WARN logging, minimal Actuator exposure, SSL
⚙️ How It Works
Spring loads application.yml first, then application-{profile}.yml. Profile-specific properties override defaults. Multiple active profiles are supported — properties from later profiles override earlier ones.
💻 Example
Profile Configuration — Environment-specific configuration and profile-specific beans.
🤔 Common Confusions
❓ Should I set spring.profiles.active in application.properties?
Never for production. Setting it in application.properties means the profile is always active, defeating the purpose. Set it via: SPRING_PROFILES_ACTIVE environment variable (Kubernetes, Docker), --spring.profiles.active command-line arg, or @ActiveProfiles in tests. The production profile should be activated by the deployment environment, not the code.
❓ Can I have multiple active profiles simultaneously?
Yes. SPRING_PROFILES_ACTIVE=prod,feature-x activates both. Properties from both are merged, with later profiles taking precedence for conflicts. This is useful for feature flags (prod + feature-new-checkout) or environment + concern (prod + monitoring).
🚨 Common Production Issues
Wrong profile active in production — verify with GET /actuator/env
Dev profile accidentally active in production loading H2 instead of PostgreSQL
Profile-specific @Bean missing in production causing NoSuchBeanDefinitionException
spring.profiles.active hardcoded to dev in application.properties
✅ Best Practices
Never hardcode spring.profiles.active in application.properties
Activate profiles via SPRING_PROFILES_ACTIVE environment variable in production
Use @Profile to swap implementations (mock vs real services)
Verify active profile at startup in production logs
Use @ActiveProfiles in tests to ensure correct profile
🏛️ Architect's Note
Profiles solve the environment problem, but they're not a secrets manager. Never put database passwords, API keys, or secrets in profile-specific properties files committed to Git. Use environment variables for secrets (injected by Kubernetes Secrets, AWS Secrets Manager, or HashiCorp Vault). Profiles manage structural differences (which database type, which service endpoints); secrets management handles sensitive values.
💬 Frequently Asked Questions
🎯 Key Takeaways
🔗 Related Topics
🎯 Practice this topic in interviews
↗ Where this topic fits
Spring Boot Technology Guide
Return to the Spring Boot learning hub.
Backend Engineer Career Path
A structured journey through Core Java, Spring Boot, production backend engineering, and interview preparation.
Full Stack Java Developer Career Path
A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.
Sources
Sources / References
Use these Spring Boot references to verify the concept in official docs and continue into the most relevant SplashRide pages.
Official documentation
Related SplashRide pages
SplashRide Spring Boot learning path
Browse the full Spring Boot topic collection and learning order on SplashRide.
Spring Boot Interview Prep
Practice Spring Boot interview questions and scenario-based answers.
Backend Engineer Career Path
A structured journey through Core Java, Spring Boot, production backend engineering, and interview preparation.
Full Stack Java Developer Career Path
A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.
Application Properties
Master Spring Boot configuration — application.properties, application.yml, profiles, @ConfigurationProperties, and externalized configuration for production deployments.
Actuator
Master Spring Boot Actuator — the production-ready features for health checks, metrics, info, and management endpoints that every enterprise Spring Boot application needs.