Spring Boot Profiles for Environment-Specific Configurations

The Core Concept: Segregating Configuration

The fundamental idea behind Spring Profiles is to segregate parts of your application configuration and make them available only in certain environments. Instead of having one large configuration file with commented-out sections or complex logic, you can define separate configurations for each target environment, such as dev, staging, and prod.

Spring Boot makes this incredibly intuitive through a file naming convention.

• application.yml (or .properties) contains your base configuration—properties that are common across all environments or serve as defaults.
• application-{profile}.yml contains profile-specific overrides. For example, application-dev.yml holds properties exclusively for the dev environment.

When a profile (e.g., dev) is activated, Spring Boot loads both application.yml and application-dev.yml. If a property exists in both files, the value from the profile-specific file (application-dev.yml) takes precedence.

To start, let's watch a short video that introduces the problem Spring Profiles solve and the basic mechanics of how they work.

Creating and Activating Profiles

Now that you understand the "why," let's get into the "how."

1. Creating Profile-Specific Files

In your project's src/main/resources directory, alongside your base application.yml, you can create new files following the application-{profile}.yml pattern.

application.yml (Base Configuration)

server:
  port: 8080 # Default port

logging:
  level:
    root: INFO # Default logging level

app:
  message: "Hello from the default profile!"

application-dev.yml (Development Profile)

# Overrides the port for development
server:
  port: 8088




# More verbose logging for development
logging:
  level:
    com.yourcompany: DEBUG




# Profile-specific message
app:
  message: "Hello from the DEV profile!"

application-prod.yml (Production Profile)

# Use environment variables for sensitive data
spring:
  datasource:
    url: ${DATABASE_URL}
    username: ${DATABASE_USER}
    password: ${DATABASE_PASSWORD}




# Stricter logging for production
logging:
  level:
    root: WARN
    com.yourcompany: INFO

app:
  message: "Hello from the PROD profile!"

2. Activating a Profile

Spring needs to be told which profile to activate. If you don't specify one, it uses the default profile (loading only application.yml). There are several ways to activate a profile, but the most common and flexible methods are done externally, without changing your code.

The following resource provides a comprehensive list of activation methods.

As highlighted in the article, the most practical way to activate a profile when running your packaged application is via a command-line argument:

# Run the application with the 'prod' profile active
java -jar my-application.jar --spring.profiles.active=prod




# Run the application with the 'dev' profile active
java -jar my-application.jar --spring.profiles.active=dev

This single command-line switch determines which entire set of configurations is loaded, allowing you to deploy the exact same jar file to any environment.

The following video demonstrates creating, configuring, and activating profiles, including the crucial override behavior.

A Practical Walkthrough: Dev, Staging, & Prod

Let's ground this theory in a more realistic scenario that reflects a typical microservice deployment pipeline. We'll look at specific configurations for dev, staging, and prod environments.

The next video provides an excellent walkthrough of setting up these three environments with distinct, practical configurations.

Here's a summary of the key principles demonstrated:

Beyond Properties: Profile-Specific Beans with @Profile

Profiles can do more than just switch property values. They can also determine which Spring beans are created and loaded into the ApplicationContext. This is a powerful feature for implementing different behaviors based on the environment.

A classic use case is providing a mock implementation of a service for local development or testing, while the real implementation is used in production. This is done with the @Profile annotation.

import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.stereotype.Service;

// Interface defining the service contract
public interface NotificationService {
    void sendNotification(String message);
}

// A mock implementation that only logs the message
// This bean will only be created if the 'dev' or 'test' profile is active
@Service
@Profile({"dev", "test"}) 
public class MockNotificationService implements NotificationService {
    @Override
    public void sendNotification(String message) {
        System.out.println("MOCK NOTIFICATION: " + message);
    }
}

// The real implementation that connects to an external service (e.g., Twilio, SendGrid)
// This bean will only be created if the 'prod' profile is active
@Service
@Profile("prod")
public class SmsNotificationService implements NotificationService {
    // ... logic to connect to a real SMS gateway ...
    @Override
    public void sendNotification(String message) {
        // Real implementation sends an SMS
    }
}

Spring will only instantiate the bean whose @Profile annotation matches the active profile. If you run with --spring.profiles.active=dev, the MockNotificationService is used. If you run with prod, the SmsNotificationService is used. This prevents your application from even trying to connect to a real SMS gateway during local development.

The @Profile annotation also supports more complex logic:

• @Profile("!prod"): Active if the prod profile is not active.
• @Profile("prod & cloud"): Active only if both prod and cloud profiles are active.

An Alternative: Multi-Document YAML Files

While using separate files is the most common approach, Spring Boot (since version 2.4) also supports defining multiple profiles within a single application.yml file. This can be convenient for smaller projects where you want to see all configurations in one place.

You use three dashes (---) to separate the documents within the file.

# Default properties (no profile)
app:
  message: "Hello from the default profile!"
server:
  port: 8080
---



# 'dev' profile configuration
spring:
  config:
    activate:
      on-profile: dev
server:
  port: 8088
app:
  message: "Hello from the DEV profile!"
---



# 'prod' profile configuration
spring:
  config:
    activate:
      on-profile: prod
logging:
  level:
    root: WARN
app:
  message: "Hello from the PROD profile!"

This is functionally equivalent to using separate files. The choice between separate files and a single multi-document file is largely a matter of team preference and project complexity. For larger projects, separate files are often easier to manage.

Conclusion

In this lesson, we've explored Spring Profiles, a cornerstone feature for building and deploying robust, real-world applications. You are now equipped to manage configurations across multiple environments in a clean, scalable, and maintainable way.

Key Takeaways:

• Purpose: Spring Profiles allow you to group and segregate configurations for different environments like development, testing, and production.
• File-based Convention: The standard approach is to use a base application.yml for shared properties and application-{profile}.yml for environment-specific overrides.
• Activation: Profiles are typically activated externally via the --spring.profiles.active=... command-line argument or the SPRING_PROFILES_ACTIVE environment variable. This allows a single application artifact to be used across all environments.
• Property Overriding: Properties defined in an active profile always take precedence over those in the default application.yml file.
• Conditional Bean Creation: The @Profile annotation is a powerful tool for conditionally creating beans, enabling different application behavior (e.g., using mocks vs. real services) depending on the active environment.

With your understanding of application configuration now solidified, we are ready to move on to building the web layer of our application. In the next lesson, we will begin our dive into Spring Web MVC, starting with its core architecture and the DispatcherServlet that handles all incoming HTTP requests.