application.properties in Spring Boot: The Settings That Matter

Every Spring Boot application has a single file where its external behaviour is tuned: application.properties. Change one line and the server moves to a new port; change another and it connects to a different database. This tutorial covers the settings you will actually touch, the formats and profiles that organise them, and the override rules that make the same JAR run correctly in dev, test and production.

Where the file lives and when it loads

The conventional location is src/main/resources/application.properties. Spring Boot loads it automatically during startup — there is no configuration required to point at it, because reading this file is part of the framework's default behaviour. By the time your beans are created, every value in it is already available.

This tight integration is why properties and auto-configuration go together. When Spring Boot auto-configures a datasource or a web server, it reads the relevant properties to build those beans. Your file is not parsed by your own code; it feeds the framework's configuration.

The settings you will change most

A handful of properties account for the majority of real edits:

## Server
server.port=8081
server.servlet.context-path=/api

## Datasource
spring.datasource.url=jdbc:mysql://localhost:3306/shopdb
spring.datasource.username=root
spring.datasource.password=secret

## JPA / Hibernate
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

## Logging
logging.level.org.springframework.web=INFO
logging.level.com.example=DEBUG

Each key maps to an auto-configured bean's property. server.port retunes the embedded Tomcat. The spring.datasource.* keys feed the connection pool. The spring.jpa.* keys configure Hibernate, which is exactly what you tune when working through Spring Data JPA. You rarely invent these names — they are documented, and your IDE autocompletes them.

Pro tip: Set spring.jpa.show-sql=true while learning or debugging to watch the exact SQL Hibernate generates. Turn it off in production, where it floods the logs and can leak query details. Small toggles like this are why the properties file is the first place to look when behaviour surprises you.

Properties vs YAML

Spring Boot accepts the same configuration in two formats. Properties files are flat:

spring.datasource.url=jdbc:mysql://localhost:3306/shopdb
spring.datasource.username=root
spring.jpa.show-sql=true

YAML expresses the same hierarchy with indentation, which many find cleaner once nesting deepens:

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/shopdb
    username: root
  jpa:
    show-sql: true

Both are equivalent. Pick one per project and stay consistent — mixing application.properties and application.yml in the same module leads to confusion about which value wins.

Common mistake: Getting YAML indentation wrong. YAML is whitespace-sensitive, and a stray tab or misaligned key silently changes the structure so your value never binds. If a YAML setting is being ignored, check indentation before anything else.

Profiles: one app, many environments

You almost never want the same database URL in development and production. Profiles solve this. A profile-specific file layers on top of the base file when that profile is active:

## application.properties (base)
spring.profiles.active=dev
server.port=8080

## application-dev.properties
spring.datasource.url=jdbc:mysql://localhost:3306/shopdb_dev

## application-prod.properties
spring.datasource.url=jdbc:mysql://prod-db:3306/shopdb

With spring.profiles.active=dev, Spring Boot loads the base file and then overlays application-dev.properties, so the dev database URL wins. Switch the active profile to prod at deploy time and the same build points at the production database. Nothing in your code changes.

The override order that saves deployments

Properties files are only one of several configuration sources, and they sit fairly low in priority. Spring Boot resolves each property from the highest-priority source that defines it, in roughly this order (highest first):

1. Command-line arguments (--server.port=9090)
2. Environment variables (SERVER_PORT=9090)
3. Profile-specific properties files
4. The base application.properties

This ordering is what makes a single JAR portable. You commit safe defaults in the file, then override secrets and environment-specific values at runtime without editing the artifact — the standard pattern for Docker and cloud deployment. Note the relaxed binding: the environment variable SERVER_PORT maps to the property server.port automatically.

Reading custom values in code

Beyond framework settings, you will define your own properties. Inject a single value with @Value:

@Service
public class InvoiceService {
    @Value("${invoice.tax-rate}")
    private double taxRate;

    public double withTax(double amount) {
        return amount * (1 + taxRate);
    }
}

For a group of related keys, bind them to a type-safe class with @ConfigurationProperties, which is cleaner and validates better than scattering @Value everywhere:

@Component
@ConfigurationProperties(prefix = "invoice")
public class InvoiceProperties {
    private double taxRate;
    private String currency;
    // getters and setters
}

With invoice.tax-rate=0.18 and invoice.currency=INR in the file, both fields populate automatically. @ConfigurationProperties is the pattern to prefer once you have more than a couple of related settings.

Placeholders, defaults and relaxed binding

Properties are more capable than plain key=value pairs suggest. You can reference one property from another, and supply a fallback when a value might be missing:

app.name=shop-service
app.banner=Welcome to ${app.name}
server.port=${PORT:8080}

The ${app.name} placeholder substitutes another property's value, and ${PORT:8080} reads the PORT environment variable if present, falling back to 8080 otherwise. That fallback syntax is the backbone of container configuration: the same JAR uses 8080 locally and whatever port the platform injects in production.

Relaxed binding is the other quiet convenience. Spring Boot treats server.port, SERVER_PORT, server_port and serverPort as the same property. This is what lets an environment variable in UPPER_SNAKE_CASE override a dotted property name — essential because environment variables cannot contain dots. You do not have to think about it; you just benefit from it.

Configuration for containers and the cloud

The override order is not academic — it is the whole reason a single build runs everywhere. In a containerised deployment you bake safe defaults into the properties file, then inject environment-specific values as environment variables at run time:

## same JAR, production values supplied by the platform
export SPRING_DATASOURCE_URL=jdbc:mysql://prod-db:3306/shopdb
export SPRING_DATASOURCE_PASSWORD=$DB_SECRET
export SPRING_PROFILES_ACTIVE=prod
java -jar shop-service.jar

Nothing in the artifact changes between environments. The database URL, the password from a secret store, and the active profile all arrive from outside. This is the twelve-factor style of configuration, and Spring Boot supports it natively through the same override order you already learned. Secrets in particular should never live in a committed properties file — pass them as environment variables so they stay out of version control.

Interview note: If asked "how do you keep passwords out of your properties file", the expected answer is externalised configuration: environment variables or a secrets manager supplying the value at run time, with the file holding only non-sensitive defaults. Mentioning the override order that makes this work shows you have actually deployed something.

Where this fits in the bigger picture

The properties file is the tuning dial for the beans that Spring Boot builds for you. Understanding it means you can change ports, swap databases, adjust logging and manage environments without touching Java — and it complements the Spring Boot annotations that shape the beans themselves. Together, annotations define the structure and properties tune the behaviour.

Interview relevance

Configuration questions are common because they reveal whether you have shipped a real application. Be ready to explain where application.properties lives, the difference between properties and YAML, and how profiles layer environment-specific values. The strongest point to make is the override order: command-line and environment variables beat the file, which is how one build runs in every environment. Mention @Value versus @ConfigurationProperties for reading custom keys. These come up in the Spring Boot fresher interview questions right alongside starters and auto-configuration.