Application Properties

Master Spring Boot configuration — application.properties, application.yml, profiles, @ConfigurationProperties, and externalized configuration for production deployments.

Last reviewed: January 2025

·Spring Boot 2.7Spring Boot 3.x
✅
Quick Understanding: Spring Boot reads configuration from application.properties (or application.yml) in src/main/resources. Properties control everything — server port, database URL, logging levels, and your own custom settings. For production, you externalize sensitive values via environment variables or a config server — never hardcode secrets.

🔍 What Is It?

Spring Boot's externalized configuration system lets you configure your application without changing code.

Configuration sources (in priority order, highest first):

  1. Command-line arguments (--server.port=9090)
  2. SPRING_APPLICATION_JSON environment variable
  3. OS environment variables (SERVER_PORT=9090)
  4. application-{profile}.properties (profile-specific)
  5. application.properties / application.yml
  6. @PropertySource annotations
  7. 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.properties contains non-sensitive defaults
  • →application-prod.properties overrides 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.

yaml
spring:
  application:
    name: order-service
  datasource:
    url: jdbc:postgresql://localhost:5432/orders
    username: postgres
    password: ${DB_PASSWORD}
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: false

server:
  port: 8080
  shutdown: graceful

app:
  jwt:
    secret: ${JWT_SECRET}
    expiration-ms: 86400000
  cors:
    allowed-origins:
      - https://app.company.com
  features:
    new-checkout: false

🤔 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

Senior Architect's Perspective

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

How do I activate a profile?

Several ways: (1) SPRING_PROFILES_ACTIVE=prod environment variable (preferred for production), (2) --spring.profiles.active=prod command-line arg, (3) @ActiveProfiles in tests. Never hardcode the active profile in application.properties.

Can I have multiple active profiles at once?

Yes. SPRING_PROFILES_ACTIVE=prod,feature-x activates both profiles. Properties from both are merged, with later profiles taking precedence for conflicts.

🎯 Key Takeaways

1Configuration sources have a priority order — environment variables override application.properties
2@ConfigurationProperties is preferred over @Value for type-safe, validated configuration
3Profiles enable environment-specific config — activate with SPRING_PROFILES_ACTIVE env var
4Never commit secrets to properties files — use environment variables
5YAML is hierarchical and reduces repetition compared to .properties format

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Spring Boot references to verify the concept in official docs and continue into the most relevant SplashRide pages.

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.