Externe und überschreibbare Konfiguration

A core principle of portable apps is storing configuration in the environment, not in code. The same artifact should run anywhere, with behavior changed only by external config.

Spring Boot embraces this: a single jar reads from many sources and merges them with a well-defined precedence.

Boot collects configuration from numerous property sources — files, environment variables, command-line args, and more — into one unified Environment.

• Each source contributes key/value pairs
• Higher-priority sources win on conflicts
• Your code never knows or cares where a value came from

When the same key appears in several sources, the highest-priority source wins. A simplified, commonly used ordering:

• Command-line arguments
• OS environment variables
• Profile-specific application-{profile} files
• Base application files
• Defaults in code / @Value fallbacks

This is why a CLI flag can override anything baked into the jar.

Pass --key=value after the jar. These have very high precedence and are ideal for one-off overrides or container entrypoints.

Environment variables use an UPPER_SNAKE_CASE form of the property name: dots and dashes become underscores. This is the standard way to inject config in containers.

Because env var names are constrained, Spring maps them back to canonical property names. APP_MAIL_MAX_RETRIES resolves to app.mail.maxRetries. This lets you set any property from the environment.

Keep secrets out of the jar; reference them with placeholders and let the platform supply real values via env vars. The committed file holds only a safe default or none.

Point Boot at config outside the jar with spring.config.location or add extra files with spring.config.additional-location. Operators can drop a file next to the deployment without rebuilding.

Modern Boot supports spring.config.import to pull in extra documents, optional files, or even config server entries, merged with the normal precedence rules.

The random property source generates values on demand — handy for test data or ephemeral identifiers, though not for stable secrets.

When a value is not what you expect, inspect the merged Environment. The actuator /env endpoint lists every property source and the winning value, making precedence problems easy to diagnose.

Externalized config makes one artifact run everywhere.

• Many sources merge into one Environment by precedence
• CLI args > env vars > profile files > base files > code defaults
• Env vars use UPPER_SNAKE_CASE relaxed binding
• Inject secrets via placeholders at deploy time
• Use /actuator/env to debug where a value originated