Configuration and Profiles

Introduction

An application behaves differently on your laptop, in testing and in production: different ports, databases and secrets. Spring Boot separates configuration from code. The property names in this lesson (such as server.port and spring.profiles.active) were checked in the metadata of the Spring Boot 4.1.2 release, but the code was not compiled or run here.

application.properties

The file src/main/resources/application.properties holds settings, one per line:

spring.application.name=library
server.port=8081
logging.level.com.example=DEBUG

• server.port changes the web server port (default 8080).
• logging.level.<package> sets the log level for a package.
• You may use application.yml instead, which uses indentation. Pick one style per project.

Where settings can come from

Spring Boot reads configuration from several places, with later, more specific sources overriding earlier ones. In practice, from weaker to stronger:

1. Default values in code
2. application.properties in your jar
3. Profile-specific files such as application-dev.properties
4. Environment variables
5. Command-line arguments

This lets the same jar run anywhere, with settings supplied from outside. For example:

SERVER_PORT=9090 java -jar app.jar
java -jar app.jar --server.port=9090

Environment variables use relaxed binding: SERVER_PORT maps to server.port.

Profiles

A profile is a named set of configuration, such as dev, test and prod.

Create application-dev.properties:

logging.level.com.example=DEBUG
spring.h2.console.enabled=true

and application-prod.properties:

logging.level.com.example=INFO
server.shutdown=graceful

Activate a profile:

spring.profiles.active=dev

or with an environment variable: SPRING_PROFILES_ACTIVE=prod. Settings in the active profile file override the main file.

You can also make beans appear only in some profiles:

import org.springframework.context.annotation.Profile;
import org.springframework.stereotype.Component;

@Component
@Profile("dev")
public class DevDataLoader { /* creates sample data in dev only */ }

Reading single values

import org.springframework.beans.factory.annotation.Value;

@Value("${app.greeting:Hello}")
private String greeting;

${app.greeting:Hello} reads app.greeting and uses Hello if it is missing. It works, but scattered @Value fields are hard to maintain.

Typed configuration

Group related settings in a record and let Spring bind and validate them.

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.context.properties.EnableConfigurationProperties;

@ConfigurationProperties(prefix = "library")
public record LibraryProperties(String name, int maxLoans) {}

Enable it on a configuration class or the main class:

@SpringBootApplication
@EnableConfigurationProperties(LibraryProperties.class)
public class DemoApplication { /* ... */ }

with properties:

library.name=City Library
library.max-loans=5

Property names written in kebab case (max-loans) bind to the Java name maxLoans. You can then inject LibraryProperties into any class that needs it.

Secrets

• Never commit passwords, API keys or tokens in properties files.
• Supply them through environment variables or a secrets manager.
• Add local files that contain secrets to .gitignore.
• Keep a template with fake values for teammates.

Try it yourself

Add application-dev.properties and application-prod.properties with different log levels. Run the app with each profile active and compare the logs. Bind a LibraryProperties record and show its values from an endpoint.

Summary

• Settings live in application.properties, and environment variables and arguments override them.
• Profiles hold environment-specific settings and are activated with spring.profiles.active.
• Use @ConfigurationProperties for typed settings, and never commit secrets.