Almost every application needs settings that differ between environments: a different database on a laptop than in production, a different port during testing, or a secret key that should never be written directly into code. Spring Boot reads these kinds of settings from application.properties, letting behaviour change without touching a single line of Java.

Where it lives and how it works

The file sits in src/main/resources and is read automatically the moment the application starts. Spring Boot itself already understands a long list of built-in settings, and a project can also define its own for its specific needs, all in the same simple key equals value format:

server.port=9090
spring.datasource.url=jdbc:h2:mem:test
spring.jpa.hibernate.ddl-auto=update
app.welcome-message=Welcome to my site

The first line changes the port the app listens on. The next two configure the database connection and how Hibernate manages the schema. The last is a custom property that only this application understands, since it does not match any setting Spring Boot recognises on its own.

Reading a custom value

The @Value annotation injects a single property straight into a field:

@Value("${app.welcome-message}")
private String welcome;

Grouping related settings

Once a feature has several related settings, @ConfigurationProperties is usually cleaner than several separate @Value fields. It binds a whole group of properties sharing a prefix onto one class:

@ConfigurationProperties(prefix = "app.mail")
public class MailProperties {
  private String host;
  private int port;
  // getters and setters
}
app.mail.host=smtp.example.com
app.mail.port=587

This keeps configuration organised as a project grows, since related settings live together on one typed class instead of scattered across many separate injected fields.

Different settings per environment with profiles

Spring Boot supports profile-specific files, such as application-dev.properties and application-prod.properties, which override or add to the base file when that profile is active. Activating a profile is as simple as setting spring.profiles.active=dev, letting a database point at a local instance during development and a real server in production, without changing any code between the two.

Keeping secrets out of the file

A password or API key should not be committed to source control inside application.properties. Spring Boot allows any property to be overridden by an environment variable, so a value like spring.datasource.password can instead be supplied as SPRING_DATASOURCE_PASSWORD on the machine running the application, keeping secrets outside the codebase entirely while the code stays unaware of the difference.

Why this matters

Centralising configuration this way means the same compiled application can behave differently depending only on which properties file or environment variables are present when it starts, which is exactly the flexibility needed to move an application from a laptop to a test server to production without rebuilding it each time.