Learn Spring Boot - Application Configuration & Properties

#Introduction

An application can't run in just one environment. Configuration written correctly lets the application move from development to production without changing code. Episode 8 covers application configuration and properties thoroughly.

You'll learn to choose a configuration format, leverage environment variables, separate configuration per profile, and — just as importantly — keep secrets from leaking into code or the repository.

#application.properties vs application.yml

#Two Formats, One Semantics

Both formats support the same properties. application.properties uses a flat key=value format, while application.yml uses hierarchical indentation:

server.port=8081
spring.datasource.url=jdbc:postgresql://localhost:5432/belajar
spring.datasource.username=belajar
spring.jpa.show-sql=true

server:
  port: 8081
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/belajar
    username: belajar
  jpa:
    show-sql: true

Choose YAML when the configuration is large and nested — it's easier to read. Choose properties when the configuration is short. Remember: don't have both files at once because Spring reads only one.

#Accessing Properties in Code

Access a property from code with @Value or with type-safe configuration @ConfigurationProperties:

@ConfigurationProperties(prefix = "app.storage")
public class StorageProperties {
 
    private String bucket;
    private String region;
 
    // getter dan setter
}

With @ConfigurationProperties, a group of properties is bundled into a typed, easily testable object. Enable it with @EnableConfigurationProperties or @ConfigurationPropertiesScan on the main class.

#Externalized Configuration

#Environment Variables

Spring Boot loads configuration from many sources in a specific priority order. Environment variables sit above the application.properties file, so they can override without changing the file. The server.port property converts to the SERVER_PORT environment variable:

export SERVER_PORT=9000
export SPRING_DATASOURCE_URL=jdbc:postgresql://db.internal:5432/prod
./mvnw spring-boot:run

This relaxed binding mechanism makes deployment to different environments flexible — just set environment variables, without changing the application artifact.

#Command Line Arguments

You can also override via command line arguments when running the jar:

java -jar target/belajar-spring-boot.jar \
  --server.port=9000 --spring.profiles.active=prod

Command line arguments have the highest priority. This is useful when running the application manually or in deployment scripts. For example: java -jar target/belajar-spring-boot.jar --server.port=9000 --spring.profiles.active=prod combines a port override and profile activation in a single command.

#Profile-Specific Configuration

#Profile-Based Files

Per-environment configuration is split into files with a profile suffix: application-dev.yml, application-test.yml, application-prod.yml. The main application.yml file contains shared configuration, while profile files contain the differences:

spring:
  datasource:
    url: jdbc:postgresql://${DB_HOST}:5432/${DB_NAME}
    username: ${DB_USER}
    password: ${DB_PASSWORD}

Production configuration reads values from environment variables. This keeps credentials from ever being written into a configuration file.

#Activating a Profile

Activate a profile with the spring.profiles.active property, the SPRING_PROFILES_ACTIVE environment variable, or a command line argument:

export SPRING_PROFILES_ACTIVE=prod
java -jar target/belajar-spring-boot.jar

The application now loads application.yml and then overlays it with application-prod.yml. Profiles can also mark specific beans as active only on certain profiles with @Profile.

#Securing Secrets and Credentials

#Don't Put Secrets in the Repository

Database passwords, API keys, and tokens must not be written into application.properties or committed to git. The basic principle: secrets come in through environment variables or a secret manager, not configuration files.

export DB_PASSWORD='sangat-rahasia'
export API_KEY='sk-xxxx'

Spring Boot uses environment variables to fill in properties like DB_PASSWORD above. In production, secrets are managed by platforms such as Kubernetes Secrets, AWS Secrets Manager, or HashiCorp Vault — not hardcoded.

#Adding an Encryption Layer

For certain cases, property values can be encrypted. A common approach is using Jasypt to decrypt properties at runtime:

mvn jasypt:encrypt-value -Djasypt.encryptor.password=master \
  -Djasypt.plugin.value="sangat-rahasia"

The encrypted value is placed in the configuration in ENC(...) form, and Jasypt decrypts it when the application starts using a master password provided through an environment variable. Make sure the master password isn't committed.

#Closing

Episode 8 equipped you with proper configuration management: choosing between the properties and YAML formats, leveraging environment variables and command line arguments for externalized configuration, separating configuration per profile, and keeping secrets safe.

Key takeaways:

• Use YAML for nested configuration, properties for short configuration.
• Environment variables and command line args override configuration files.
• @ConfigurationProperties makes configuration type-safe and easy to test.
• Split configuration per profile with application-<profile>.yml files.
• Secrets must come in through environment variables or a secret manager, not configuration files.
• Encrypt properties with Jasypt for an extra security layer.

In the next episode, episode 9, we'll discuss logging, metrics, and health — Logback for structured logging, Spring Boot Actuator for health checks and metrics, custom actuator endpoints, and Micrometer integration with Prometheus for observability.