If your Spring Boot app had a filing cabinet it would be called application.properties and it would judge you for messy keys. This file is the simplest way to externalize configuration, set server ports, and bind values into your beans without chanting ancient deployment rituals.

Where to put the file

Create a file named application.properties and drop it under src/main/resources for a normal Maven or Gradle project. Spring Boot auto configuration will pick it up from the classpath so you do not need wizardry to make it work.

Key value basics

Keep properties plain and predictable. Use consistent naming so your future self does not hate you. Example lines look like this

server.port=8081
app.name=MyApp
app.featureX.enabled=true

server.port controls the embedded server port. Change it for local testing or to avoid port wars on your machine.

Binding properties to beans

For single values use @Value when you need a quick grab. For groups of related values prefer @ConfigurationProperties for cleaner code and easier testing.

Quick single value bind

public class SomeBean {
    @Value("${app.name}")
    private String appName;

    // getter and maybe setter
}

Group binding with ConfigurationProperties

Make a POJO that maps a prefix to fields. This is the polite way to keep configuration sane when values grow.

@Component
@ConfigurationProperties("app")
public class AppProperties {
    private String name;
    private Feature feature = new Feature();

    public static class Feature {
        private boolean enabled;
        // getters and setters
    }

    // getters and setters
}

Tip prefer @ConfigurationProperties for coherent groups of settings. It keeps validation and structure simple.

Profiles for environment specific overrides

Profiles let you keep dev and prod settings from fighting each other. Create files like application-dev.properties and application-prod.properties. Activate a profile by setting spring.profiles.active=dev in the environment or via command line when you start the app.

# application.properties
app.name=MyApp

# application-dev.properties
app.name=MyApp Dev

# application-prod.properties
app.name=MyApp

The active profile file will override matching keys from the base file when that profile is active. This is the polite way to have different settings per environment without rebuilding jars.

Externalized configuration and precedence

Want to tweak things without rebuilding or redeploying The external properties trick is for you. Put an application.properties outside the jar on the filesystem and Spring Boot can load it at runtime. This makes ops people very happy and developers slightly nervous.

Spring Boot follows a clear order of precedence from highest to lowest. A few common tiers look like this

1. Command line arguments
2. External properties files on the filesystem
3. application properties on the classpath
4. Defaults provided by Spring Boot

Use this to your advantage when you want a safe override surface for emergency fixes or per host settings.

Recap and best practices

• Create application.properties under src/main/resources
• Use simple key value pairs like server.port and app.name
• Prefer @ConfigurationProperties for grouped settings and use @Value for quick single values
• Use application-{profile}.properties for environment specific overrides
• Externalize config for runtime tweaks and follow the precedence rules when troubleshooting

If you follow these steps your configuration will be predictable and your ops team will stop calling at 2 AM. Well maybe they will still call but at least you will be able to change server.port without a full rebuild.