Application Properties
Master Spring Boot configuration — application.properties, application.yml, profiles, @ConfigurationProperties, and externalized configuration for production deployments.
Last reviewed: January 2025
🔍 What Is It?
Spring Boot's externalized configuration system lets you configure your application without changing code.
Configuration sources (in priority order, highest first):
- Command-line arguments (
--server.port=9090) SPRING_APPLICATION_JSONenvironment variable- OS environment variables (
SERVER_PORT=9090) application-{profile}.properties(profile-specific)application.properties/application.yml@PropertySourceannotations- Default values in code
Configuration formats:
- →
application.properties— key=value pairs (simpler) - →
application.yml— YAML (hierarchical, less repetition)
Binding approaches:
- →
@Value("${property.name}")— inject single value - →
@ConfigurationProperties(prefix="app")— bind a group of properties to a class (preferred)
🎯 Why Do We Need It?
Without externalized configuration:
- →Database URLs would be hardcoded in source code
- →The same JAR couldn't run in dev, staging, and production
- →Changing a port would require recompilation
- →Secrets would be committed to Git
With Spring Boot's config system:
- →One JAR runs in all environments — only config changes
- →Secrets come from environment variables or Vault at runtime
- →Profiles activate environment-specific config automatically
- →Teams can change behavior without touching code
🏗️ What Happens in Real Projects?
In production microservices:
- →
application.propertiescontains non-sensitive defaults - →
application-prod.propertiesoverrides for production - →Database passwords come from environment variables (Kubernetes Secrets)
- →Feature flags come from a Config Server (Spring Cloud Config)
- →Logging levels changed at runtime via Actuator without restart
⚙️ How It Works
Property relaxed binding:
Spring Boot normalizes property names — these are all equivalent:
- →
spring.datasource.url(properties) - →
SPRING_DATASOURCE_URL(env var) - →
--spring.datasource.url(command line)
@ConfigurationProperties binding:
Spring reads all properties with the given prefix and binds them to the class fields using relaxed binding. Supports nested objects, lists, and maps. Much safer than @Value — validates at startup, not at runtime.
💻 Example
Configuration in Practice — From simple properties to type-safe configuration classes.
🤔 Common Confusions
❓ @Value vs @ConfigurationProperties — which should I use?
@ConfigurationProperties is strongly preferred for groups of related properties. It provides type safety, validation at startup, and IDE autocompletion. Use @Value only for simple one-off injections or SpEL expressions.
❓ How do environment variables override properties?
Spring Boot uses relaxed binding — SPRING_DATASOURCE_URL (env var) maps to spring.datasource.url (property). Environment variables take higher priority than application.properties. In Kubernetes, inject secrets as env vars.
❓ application.properties vs application.yml — which is better?
YAML is preferred for complex configurations — it's hierarchical and eliminates repetition. Properties files are simpler for flat configs. Pick one and be consistent. YAML requires careful indentation — use 2 spaces, never tabs.
🚨 Common Production Issues
Secrets in application.properties committed to Git — use environment variables or Spring Cloud Vault
Wrong profile active in production — verify with /actuator/env endpoint
@ConfigurationProperties fields not binding — ensure setters exist
YAML indentation errors cause silent misconfiguration — validate in CI
✅ Best Practices
Use @ConfigurationProperties over @Value for groups of related properties
Add @Validated to @ConfigurationProperties classes to catch missing config at startup
Never put secrets in application.properties — use environment variables
Use spring-boot-configuration-processor for IDE autocompletion of custom properties
Use spring.config.import to pull config from external sources (Config Server, Vault)
🏛️ Architect's Note
For microservices at scale, use Spring Cloud Config Server — a centralized configuration service where all microservices pull their config at startup. This enables config changes without redeployment. In Kubernetes environments, use ConfigMaps for non-sensitive config and Secrets (mounted as env vars) for sensitive values.
💬 Frequently Asked Questions
🎯 Key Takeaways
🔗 Related Topics
🎯 Practice this topic in interviews
↗ Where this topic fits
Spring Boot Technology Guide
Return to the Spring Boot learning hub.
Backend Engineer Career Path
A structured journey through Core Java, Spring Boot, production backend engineering, and interview preparation.
Full Stack Java Developer Career Path
A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.
Sources
Sources / References
Use these Spring Boot references to verify the concept in official docs and continue into the most relevant SplashRide pages.
Official documentation
Related SplashRide pages
SplashRide Spring Boot learning path
Browse the full Spring Boot topic collection and learning order on SplashRide.
Spring Boot Interview Prep
Practice Spring Boot interview questions and scenario-based answers.
Backend Engineer Career Path
A structured journey through Core Java, Spring Boot, production backend engineering, and interview preparation.
Full Stack Java Developer Career Path
A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.
Spring Boot Introduction
Understand what Spring Boot is, why it exists, and how it transforms enterprise Java development by eliminating boilerplate configuration.
Auto Configuration
Understand how Spring Boot's auto-configuration works under the hood — how it detects your classpath, applies conditional configuration, and how to customize or disable it.