Externalized and Override Configuration
Override config via environment and command line.
Externalized and Override Configuration is a free Spring Boot 4 Microservices & REST APIs lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Spring Boot 4 Microservices & REST APIs learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The 12-Factor Idea
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.
Many Sources, One Environment
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
Precedence Order (High to Low)
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
applicationfiles - Defaults in code /
@Valuefallbacks
This is why a CLI flag can override anything baked into the jar.
Overriding with Command-Line Args
Pass --key=value after the jar. These have very high precedence and are ideal for one-off overrides or container entrypoints.
java -jar app.jar \
--server.port=9090 \
--spring.profiles.active=prod \
--app.mail.host=smtp.prod.example.comOverriding with Environment Variables
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.
# property: app.mail.host
export APP_MAIL_HOST=smtp.prod.example.com
# property: server.port
export SERVER_PORT=9090
# property: spring.datasource.password
export SPRING_DATASOURCE_PASSWORD=s3cretRelaxed Binding for Env Vars
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.
Injecting Secrets at Deploy Time
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.
spring:
datasource:
url: ${DB_URL}
username: ${DB_USER:app}
password: ${DB_PASSWORD}External Config Files
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.
java -jar app.jar \
--spring.config.additional-location=file:/etc/myapp/Importing Config
Modern Boot supports spring.config.import to pull in extra documents, optional files, or even config server entries, merged with the normal precedence rules.
spring:
config:
import:
- optional:file:/etc/myapp/override.yml
- configserver:Random Values
The random property source generates values on demand — handy for test data or ephemeral identifiers, though not for stable secrets.
app:
instance-id: ${random.uuid}
jitter-ms: ${random.int(0,500)}Debugging Where a Value Came From
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.
# requires spring-boot-starter-actuator + exposure
GET /actuator/env/server.portQuick Check
Test your understanding of precedence.
Recap
Externalized config makes one artifact run everywhere.
- Many sources merge into one
Environmentby 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/envto debug where a value originated
Frequently asked questions
Is the “Externalized and Override Configuration” lesson free?
Yes — the full text of “Externalized and Override Configuration” is free to read here on the web, and the Spring Boot 4 Microservices & REST APIs course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Spring Boot 4 Microservices & REST APIs course, upgrade to CoddyKit PRO.
What will I learn in “Externalized and Override Configuration”?
Override config via environment and command line. You practise Spring Boot 4 Microservices & REST APIs with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Spring Boot 4 Microservices & REST APIs?
No prior experience is required. Spring Boot 4 Microservices & REST APIs on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Externalized and Override Configuration” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Spring Boot 4 Microservices & REST APIs lesson?
Yes. Every Spring Boot 4 Microservices & REST APIs lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- application.properties and YAML
- Profiles for Environments
- Type-Safe Configuration with @ConfigurationProperties
- Externalized and Override Configuration