Spring boot - custom variables in Application.properties
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Custom variables in application.properties are the standard Spring Boot way to externalize application-specific behavior. Instead of hardcoding URLs, feature flags, retry limits, or timeouts in Java classes, define them under a clear prefix and let Spring bind them into your application.
Define Application-Specific Keys
The simplest pattern is to choose a prefix such as app. and keep related settings under it:
This avoids collisions with built-in Spring properties and makes it obvious which settings belong to your code rather than to the framework.
Inject Small Numbers of Properties with @Value
For a few isolated values, @Value works fine:
The :1000 part is a default value. It is useful for optional settings, but once you have many related values, @Value becomes harder to maintain.
Prefer @ConfigurationProperties for Groups
For structured configuration, bind a whole prefix into a dedicated class:
This approach scales better because:
- the config is type-safe
- the prefix is defined once
- related settings stay grouped
It also makes testing much cleaner because a whole configuration block can be reasoned about as one object.
Override with Environment Variables
Spring Boot lets environment variables override file-based properties. For example:
- '
APP_NAMEmaps toapp.name' - '
APP_TIMEOUT_MSmaps toapp.timeout-ms'
Example:
That will override the value from application.properties at runtime. This is especially useful in containers and deployment systems where the artifact stays the same but environment-specific values differ.
Use Profiles for Environment Differences
Spring Boot also supports profile-specific files such as:
- '
application.properties' - '
application-dev.properties' - '
application-prod.properties'
Activate a profile from configuration or the environment:
or:
This keeps development, staging, and production differences out of your Java code.
Keep Secrets Out of the File When Possible
Custom variables are great for flags and non-sensitive settings, but secrets need extra care. Avoid checking passwords or tokens into source control. Instead, reference environment variables or a secret manager:
That keeps the property binding model consistent while moving the sensitive value out of the repository.
Common Pitfalls
- Mixing application-specific keys with Spring framework keys under no clear naming convention.
- Using
@Valuefor large configuration groups and ending up with scattered property strings everywhere. - Forgetting that environment variables can override file values at runtime.
- Storing secrets directly in
application.propertiesand committing them to version control. - Treating configuration as untyped strings when
@ConfigurationPropertieswould give stronger structure.
Summary
- Define custom application properties under a clear prefix such as
app.. - Use
@Valuefor a small number of isolated values. - Prefer
@ConfigurationPropertiesfor grouped, structured configuration. - Override values cleanly with environment variables and profile-specific files.
- Keep sensitive values external even when the property key itself lives in Spring Boot configuration.

