Spring Boot Profiles

Introduction

The datasource configuration you wrote in the last lesson pointed at a local database with a local password — exactly right for your machine, and exactly wrong for a production server. Every real application needs different configuration depending on where it's running: different database credentials, different logging levels, different feature flags. Spring Boot profiles solve this cleanly, letting you maintain multiple sets of configuration and switch between them with a single setting.

Why Profiles Exist

Consider the datasource URL and password from Lesson 21: fine for local development, but a production deployment needs a different host, different credentials, and probably ddl-auto=validate instead of update, since you never want Hibernate silently altering a production schema. Without profiles, you'd need to manually edit application.properties every time you moved between environments — error-prone and easy to get wrong at exactly the wrong moment.

Profile-Specific Property Files

Spring Boot recognizes files named application-{profile}.properties automatically, alongside your base application.properties. Values in a profile-specific file override the base file when that profile is active.

# application.properties (shared, always loaded)
spring.application.name=student-api
spring.jpa.show-sql=false

# application-dev.properties
spring.datasource.url=jdbc:mysql://localhost:3306/studentdb
spring.datasource.username=root
spring.datasource.password=devpassword

spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
logging.level.org.springframework=DEBUG

# application-prod.properties
spring.datasource.url=jdbc:mysql://prod-db.internal:3306/studentdb
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}

spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false
logging.level.org.springframework=WARN

Notice how the production file references ${DB_USERNAME} and ${DB_PASSWORD} rather than hardcoding real credentials — Spring Boot resolves these from environment variables at startup, keeping secrets out of version control entirely.

Activating a Profile

A profile is activated by setting spring.profiles.active, which can be done in several ways depending on how you're running the application.

# In application.properties, to set a default
spring.profiles.active=dev

# As a command-line argument when running the packaged jar
java -jar student-api.jar --spring.profiles.active=prod

# As an environment variable
export SPRING_PROFILES_ACTIVE=prod
java -jar student-api.jar

The @Profile Annotation

Beyond property files, the @Profile annotation controls whether an entire Spring bean or configuration class is created at all, depending on the active profile. This is useful for swapping entire implementations — for example, a fake email sender for development versus a real one for production.

@Service
@Profile("dev")
public class FakeEmailService implements EmailService {
    @Override
    public void send(String to, String subject, String body) {
        System.out.println("[DEV] Would send email to " + to + ": " + subject);
    }
}

@Service
@Profile("prod")
public class RealEmailService implements EmailService {
    @Override
    public void send(String to, String subject, String body) {
        // Actual SMTP/API integration here
    }
}

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

You can now maintain clean, separate configuration for development and production, and switch between them safely without editing code. Next, you'll step back from configuration and look at how Spring Boot wires all these beans together in the first place, with a deep dive into Dependency Injection.