If Spring Boot config makes you feel like you are juggling flaming swords while blindfolded you are not alone. This guide is a compact tour of the properties and configuration patterns that stop surprises at runtime and keep deployments from turning into chaos therapy sessions. Expect facts and a few sarcastic asides.

Where Spring looks for config and why you should care

Spring Boot will read application.properties or application.yml from the classpath first. You can split environment concerns into profile specific files like application-dev.yml and application-prod.yml. When in doubt use command line args or environment variables to override values while debugging in containers or CI.

Remember that command line arguments and environment variables win when you need to wrestle a misbehaving app back into compliance. That behavior is deliberate and helpful unless you forgot about it during deployment.

Profiles and profile specific files

Activate a profile with spring.profiles.active=dev and layer settings by environment. Profiles make the app behave like different adults depending on where it runs. Do not mix production secrets into dev files unless you enjoy late night incident investigations.

Datasource and JPA tips

Keep datasource keys predictable and secret free in VCS. Use environment variables for credentials and inject them at runtime. Example property lines work well in a properties file.

spring.datasource.url=jdbc:postgresql://db.example.local:5432/appdb
spring.datasource.username=myuser
spring.datasource.password=${DB_PASSWORD}

For JPA schema management prefer spring.jpa.hibernate.ddl-auto=validate or none in production. Use update or create only on local developer boxes where you do not mind surprises.

Server port and logging without redeploys

Change the port with server.port=8081 when you need two apps to share a machine and they are too stubborn to negotiate. To change verbosity without rebuilding use logging.level entries like this.

logging.level.org.springframework=DEBUG

Environment overrides are your friend here for toggling verbosity in containers or CI runs.

Actuator and security

Actuator endpoints are lifesavers when used carefully and death traps when left open. Expose minimal endpoints with management.endpoints.web.exposure.include=health,info and lock down sensitive endpoints behind authentication and network rules. Treat actuator endpoints like admin doors not open windows.

JSON and serialization settings

Tune Jackson with properties such as spring.jackson.property-naming-strategy=SNAKE_CASE to match client expectations. This avoids writing clever custom serializers that future you will regret.

Configuration binding and validation

Group related settings with @ConfigurationProperties instead of scattering @Value across the codebase. That approach makes testing and validation much less painful and keeps config tidy when you add Kotlin data classes or Java beans.

The configurationproperties pattern plays nicely with Spring Data and typed binding. Validation annotations add a guardrail against bad deploys.

Externalized config and priority

Preferences for overrides are predictable. Command line flags and environment variables trump classpath files. Use that to your advantage in containers and CI pipelines. For a fleet of services consider a centralized config server to avoid copy paste bugs and secrets in the wrong repo.

Quick checklist

• Keep secrets out of VCS and prefer environment variables
• Use profile specific files for dev and prod separation
• Use spring.jpa.hibernate.ddl-auto=validate or none in production
• Expose only needed actuator endpoints and secure them
• Prefer @ConfigurationProperties for grouped settings
• Consider a config server for large deployments

Follow these patterns and your deployments will be less stressful and more boring. Boring is good in production. Now go fix that mysterious property file and tell your future self they are welcome.