[[features.profiles]] == Profiles Spring Profiles provide a way to segregate parts of your application configuration and make it be available only in certain environments. Any `@Component`, `@Configuration` or `@ConfigurationProperties` can be marked with `@Profile` to limit when it is loaded, as shown in the following example: [source,java,indent=0] ---- include::{docs-java}/features/profiles/ProductionConfiguration.java[] ---- NOTE: If `@ConfigurationProperties` beans are registered via `@EnableConfigurationProperties` instead of automatic scanning, the `@Profile` annotation needs to be specified on the `@Configuration` class that has the `@EnableConfigurationProperties` annotation. In the case where `@ConfigurationProperties` are scanned, `@Profile` can be specified on the `@ConfigurationProperties` class itself. You can use a configprop:spring.profiles.active[] `Environment` property to specify which profiles are active. You can specify the property in any of the ways described earlier in this chapter. For example, you could include it in your `application.properties`, as shown in the following example: [source,yaml,indent=0,subs="verbatim",configprops,configblocks] ---- spring: profiles: active: "dev,hsqldb" ---- You could also specify it on the command line by using the following switch: `--spring.profiles.active=dev,hsqldb`. If no profile is active, a default profile is enabled. The name of the default profile is `default` and it can be tuned using the configprop:spring.profiles.default[] `Environment` property, as shown in the following example: [source,yaml,indent=0,subs="verbatim",configprops,configblocks] ---- spring: profiles: default: "none" ---- [[features.profiles.adding-active-profiles]] === Adding Active Profiles The configprop:spring.profiles.active[] property follows the same ordering rules as other properties: The highest `PropertySource` wins. This means that you can specify active profiles in `application.properties` and then *replace* them by using the command line switch. Sometimes, it is useful to have properties that *add* to the active profiles rather than replace them. The `SpringApplication` entry point has a Java API for setting additional profiles (that is, on top of those activated by the configprop:spring.profiles.active[] property). See the `setAdditionalProfiles()` method in {spring-boot-module-api}/SpringApplication.html[SpringApplication]. Profile groups, which are described in the <> can also be used to add active profiles if a given profile is active. [[features.profiles.groups]] === Profile Groups Occasionally the profiles that you define and use in your application are too fine-grained and become cumbersome to use. For example, you might have `proddb` and `prodmq` profiles that you use to enable database and messaging features independently. To help with this, Spring Boot lets you define profile groups. A profile group allows you to define a logical name for a related group of profiles. For example, we can create a `production` group that consists of our `proddb` and `prodmq` profiles. [source,yaml,indent=0,subs="verbatim",configblocks] ---- spring: profiles: group: production: - "proddb" - "prodmq" ---- Our application can now be started using `--spring.profiles.active=production` to active the `production`, `proddb` and `prodmq` profiles in one hit. [[features.profiles.programmatically-setting-profiles]] === Programmatically Setting Profiles You can programmatically set active profiles by calling `SpringApplication.setAdditionalProfiles(...)` before your application runs. It is also possible to activate profiles by using Spring's `ConfigurableEnvironment` interface. [[features.profiles.profile-specific-configuration-files]] === Profile-specific Configuration Files Profile-specific variants of both `application.properties` (or `application.yml`) and files referenced through `@ConfigurationProperties` are considered as files and loaded. See "<>" for details.