Pro Tips — Environment Profile Strategy and Managing Sensitive Information

1. Profile Separation Architecture by Environment

Local development, QA testing, and production environments all require different databases and configuration values. Spring Boot supports this cleanly through config file separation.

The most popular production file structure looks like this:

src/main/resources/
 ├── application.yml         (Common defaults and active profile declaration)
 ├── application-local.yml   (Local H2/Debug logging setup)
 ├── application-dev.yml     (Dev DB, Integration testing env)
 └── application-prod.yml    (Prod DB, Error logging, high connection pool setup)

Specify the active profile in application.yml:

spring:
  profiles:
    active: local

2. Overriding Profiles at Deployment

Typically, you don't change the active value inside the source code (application.yml) every time. Instead, you inject it via Environment Variables or Command Line Arguments when booting up the application. They always override default properties logically.

Container/Server Startup Script Example:

# Option 1: JVM Arguments
java -jar -Dspring.profiles.active=prod myapp.jar

# Option 2: Environment Variables (Most popular for Docker, Server OS)
export SPRING_PROFILES_ACTIVE=prod
java -jar myapp.jar

3. Encrypting Sensitive Information (Passwords, Keys) using Jasypt

You must never push plain-text DB passwords or AWS Secret Keys to GitHub (this has caused thousands of fatal security breaches). In practice, production teams heavily use the Jasypt (Java Simplified Encryption) library to encrypt configuration values before putting them into application.yml.

spring:
  datasource:
    # Password encrypted by Jasypt (ENC() format)
    password: ENC(Zf9P4n+lR42m...)

The "Master Password" used to decrypt this cipher text must NEVER exist within the source code. It should exclusively be stored safely as a direct environment variable on the deployment server to fulfill a secure design paradigm.