Profiles

Master Spring Profiles for environment-specific configuration — separating dev, test, staging, and production settings without code changes.

Last reviewed: January 2025

·Spring Boot 2.7Spring Boot 3.x
✅
Quick Understanding: Spring Profiles let you have different configurations for different environments. application-dev.properties has H2 database and debug logging. application-prod.properties has PostgreSQL and INFO logging. Activate a profile with SPRING_PROFILES_ACTIVE=prod environment variable. Beans can also be profile-specific with @Profile("prod").

🔍 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.

yaml
# application.yml (defaults)
spring:
  application:
    name: order-service
server:
  port: 8080
logging:
  level:
    root: INFO

---
# application-dev.yml
spring:
  datasource:
    url: jdbc:h2:mem:devdb
    driver-class-name: org.h2.Driver
  jpa:
    hibernate:
      ddl-auto: create-drop
    show-sql: true
  h2:
    console:
      enabled: true
logging:
  level:
    com.company: DEBUG
    org.hibernate.SQL: DEBUG
management:
  endpoints:
    web:
      exposure:
        include: "*"

---
# application-prod.yml
spring:
  datasource:
    url: jdbc:postgresql://${DB_HOST}:5432/${DB_NAME}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate
logging:
  level:
    root: WARN
    com.company: INFO
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics

🤔 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

Senior Architect's Perspective

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

How do I verify which profile is active in production?

GET /actuator/env shows all properties including the active profile. Or check the startup logs — Spring Boot logs "The following profiles are active: prod" at INFO level. Add logging.level.org.springframework.boot=INFO to ensure this is logged.

🎯 Key Takeaways

1Profile-specific config files: application-{profile}.yml override application.yml
2@Profile annotation makes beans environment-specific
3Activate via SPRING_PROFILES_ACTIVE env var — never hardcode in properties
4Multiple profiles can be active simultaneously
5Use @Profile to swap mock vs real implementations
6Profiles manage structural differences; use secrets manager for sensitive values

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Spring Boot references to verify the concept in official docs and continue into the most relevant SplashRide pages.

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.