Mark
#1
When working with Spring Boot, one of the first things you’ll often do is connect your application to external services like MinIO for file storage and PostgreSQL for your database. While application.yml is a popular choice for configuration, many developers prefer application.properties for its simplicity—especially when keeping configurations separate for development and production.
In this article, we’ll walk through how to configure MinIO and PostgreSQL using application.properties for both development (application-dev.properties) and production (application-prod.properties) environments. The production example is tailored for a Kubernetes setup, where environment variables are used for sensitive data.
Let’s dive in!

Why Use Separate Configuration Files?

Spring Boot makes it easy to manage multiple environments using profiles. You can create multiple .properties files like:
  • application-dev.properties – for local development
  • application-prod.properties – for production (e.g., in Kubernetes)
This keeps your development and production configurations clean, secure, and easy to manage.

Development Configuration (application-dev.properties)

In development, it’s common to run services locally or in Docker. You can hardcode values here, since the environment is controlled and private. 
# MinIO config for dev
minio.url=http://localhost:9000
minio.accessKey=minioadmin
minio.secretKey=minioadmin123

# PostgreSQL config for dev
spring.datasource.url=jdbc:postgresql://localhost:5432/devdb
spring.datasource.username=postgres
spring.datasource.password=postgres
spring.datasource.driver-class-name=org.postgresql.Driver

# JPA settings
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
This setup allows you to test changes quickly and work in an environment that mirrors production closely, without needing to worry about secrets management.

Production Configuration (application-prod.properties for Kubernetes)

In production, especially when deploying to Kubernetes, you should never hardcode secrets. Instead, inject values using environment variables or Kubernetes secrets. 
# MinIO config for prod (Kubernetes)
minio.url=${MINIO_URL}
minio.accessKey=${MINIO_ACCESS_KEY}
minio.secretKey=${MINIO_SECRET_KEY}

# PostgreSQL config for prod
spring.datasource.url=${DB_URL}
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}
spring.datasource.driver-class-name=org.postgresql.Driver

# JPA settings for safety
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false
spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
This approach ensures that your sensitive credentials (like DB passwords or MinIO keys) are not exposed in version control. Kubernetes lets you define these values as environment variables or ConfigMaps/Secrets and inject them into your pods securely.

Switching Between Dev and Prod

To tell Spring Boot which configuration file to use, you can set the active profile in a few ways:

1. In application.properties

spring.profiles.active=dev

2. As a command-line argument (recommended for production)

java -jar yourapp.jar --spring.profiles.active=prod

3. Using an environment variable

export SPRING_PROFILES_ACTIVE=prod
This makes your application smart enough to load the right config depending on where and how it’s running.

Best Practices

  • Use application-dev.properties for development with hardcoded values (if safe).
  • Use application-prod.properties in Kubernetes with environment variables.
  • Never hardcode secrets in production.
  • Keep ddl-auto=update in dev, but use validate or none in production to avoid accidental schema changes.
  • Use profiles to clearly separate dev and prod configurations.

image quote pre code
Share: