Module 17: Spring Boot Service Development
Configuration Properties and Profiles
Organize configuration so the same application can run cleanly in development, test, staging, and production. You will use typed properties, profiles, and externalized values to keep environment differences out of core application logic.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Use profiles to activate environment-specific beans or behavior intentionally
- Bind structured configuration into typed Java classes
- Separate secrets and deploy-time values from the codebase itself
Before you start
- You understand classes, objects, exceptions, collections, and basic persistence concepts
Lesson roadmap: Start with the mental model, then follow the design choices, common pitfalls, and the practical workflow you should apply in a real project.
Profiles let one application behave differently across environments: Local development, testing, and production rarely share the same settings.
Configuration properties make settings structured and typed: That is cleaner than reading raw strings all over the app.
Environment variables and secrets management matter: Credentials and private settings should not live directly in code.
Operational discipline starts here: Clean config management is part of building deployable services, not just an advanced extra.
Externalized configuration mindset: Application code should describe behavior, while the environment supplies values such as ports, hosts, credentials, feature toggles, and service endpoints.
Typed properties improve safety: Binding configuration into a dedicated class gives you names, types, defaults, and one place to document what the application expects.
Profiles are a coarse-grained tool: They are useful when different environments really need different beans or settings, but they should not become a dumping ground for every tiny switch.
Operational discipline: Production-ready services document required properties, keep secrets outside version control, and make the active profile easy to discover at startup.
How to study this module: Keep one small service running while you learn. Seeing one controller call one service and one repository is much easier than reading isolated annotations with no end-to-end flow.
Code review mindset: Spring code stays healthy when each layer has one job. Controllers translate HTTP, services coordinate rules, repositories load and save data, and configuration wires the environment together.
Production habit: Favor explicit boundaries over framework magic. Auto-configuration is helpful, but teams still need to know where behavior comes from and how to override it safely.
Runnable examples
A typed properties class
@ConfigurationProperties(prefix = "app.mail")
record MailProperties(String host, int port) {}Expected output
The application can bind external config into a typed Java structure.
A bean can load only for one profile
@Configuration
@Profile("production")
class ProductionConfig {
}Expected output
The configuration is activated only when the `production` profile is active.
Common mistakes
Hard-coding environment-specific values directly in services
Pull those values into configuration properties so the code stays portable across environments.
Creating many overlapping profiles with unclear behavior
Use profiles sparingly and document what each one changes.
Mini exercise
Write a short configuration plan for a task API that needs different database URLs in local and production environments. Include one typed properties class and one profile-specific difference.
Summary
- Profiles separate environment-specific behavior.
- Typed properties keep settings cleaner and safer.
- Secrets and configuration should not be scattered through application code.
- Profiles and typed properties keep environments separate without cloning the codebase.
- Good config management is part of application design, not a last-minute deployment task.
Next step
Finish the Spring module with a task API mini-project.
Sources used