Introduction

Spring Boot lets you change profile selection and configuration file loading at startup without rebuilding the application. Two of the most common command-line properties are spring.profiles.active and the configuration-location properties.

The detail that matters is whether you want to replace Boot's default config search locations or add extra ones on top of them. Many deployment mistakes come from choosing the wrong property for that distinction.

Activate Profiles From the Command Line

The standard way to activate a profile is:

java -jar myapp.jar --spring.profiles.active=prod

This tells Spring Boot to load profile-specific configuration such as application-prod.yml or application-prod.properties in addition to the shared base configuration.

You can activate multiple profiles too:

java -jar myapp.jar --spring.profiles.active=prod,audit

That is useful when one profile represents the environment and another enables an orthogonal feature set.

Replace Config Search Locations With spring.config.location

If your config should come from a specific external place instead of the default search paths, use:

java -jar myapp.jar --spring.config.location=file:/etc/myapp/

This replaces the default config search locations. If the target is a directory, keep the trailing slash so Boot treats it as a directory and not as a file path.

You can also point to a specific file:

java -jar myapp.jar --spring.config.location=file:/etc/myapp/application.yml

Add Extra Locations With spring.config.additional-location

If you want to keep Boot's defaults and add another location on top, use:

java -jar myapp.jar --spring.config.additional-location=file:/etc/myapp/

This is often the safer production choice because the packaged defaults still participate in resolution, while the external directory provides overrides or additions.

The difference is important:

• 'spring.config.location replaces default search locations'
• 'spring.config.additional-location extends them'

Combine Profile and Location Cleanly

A common startup pattern is:

java -jar myapp.jar \
  --spring.profiles.active=prod \
  --spring.config.additional-location=file:/etc/myapp/

This keeps the normal packaged config, adds external overrides, and still applies profile-specific resolution in the combined search set.

That is a clean deployment model when operations wants environment-specific config outside the jar but the application still ships with sensible defaults.

Command-Line Arguments Override Other Sources Easily

Spring Boot also supports environment variables such as:

export SPRING_PROFILES_ACTIVE=staging

But command-line arguments usually have very high precedence, so this:

java -jar myapp.jar --spring.profiles.active=prod

will override the environment setting. That is convenient for one-off runs, but it also means startup scripts can override environment-level configuration more easily than some teams expect.

Common Pitfalls

The biggest mistake is using spring.config.location when the real intent was only to add another external directory. That can accidentally stop Boot from loading the normal packaged defaults.

Another common issue is forgetting the trailing slash on a directory location, which can make Boot interpret the argument differently from what you intended.

Developers also activate multiple profiles without thinking through how overlapping properties should resolve. Profile composition is powerful, but it still needs a clear convention.

Finally, do not assume environment variables and command-line arguments behave the same in precedence. Command-line startup flags are often stronger than people realize.

That makes startup scripts powerful, but it also makes them a frequent source of accidental overrides.

Summary

• Use --spring.profiles.active=... to choose one or more active profiles at startup.
• Use --spring.config.location=... when you want to replace the default config search path.
• Use --spring.config.additional-location=... when you want to add external config while keeping the defaults.
• Combine profiles and additional locations for clean environment-specific deployments.
• Be explicit about precedence so command-line overrides do not surprise you later.