[← Precedence list](01-the-precedence-list.md) · [Index](../README.md) · [Seeing precedence →](03-seeing-precedence.md)

# 2. Profiles: files, documents and groups

## Profile-specific files

`application-<profile>.yaml`, loaded from the same locations as `application.yaml`, and always
overriding it. With several profiles active, last one wins:
`--spring.profiles.active=prod,live` means `application-live.yaml` beats
`application-prod.yaml`.

## Multi-document files

The same effect without multiplying files. Documents are separated by `---` and activated by
condition:

```yaml
demo:
  greeting: from-multidoc-default-document
---
spring:
  config:
    activate:
      on-profile: staging
demo:
  greeting: from-multidoc-staging-document
```

Later documents win over earlier ones, so an unconditional first document acts as the default
and each conditional document overrides it. Measured in
[`04-import-and-multidoc.txt`](output/04-import-and-multidoc.txt).

`spring.config.activate.on-cloud-platform` and `spring.config.activate.on-profile` can be
combined; both must match.

## Profile groups

One profile that activates several:

```yaml
spring:
  profiles:
    group:
      prod: prod-db,prod-metrics
```

`--spring.profiles.active=prod` reports all three as active, and all three
`application-<name>.yaml` files are loaded. Groups are resolved before config data is
processed, which is why declaring a group in `application.yaml` can still affect which files
get loaded.

## The activation Spring Boot refuses

`spring.profiles.active` cannot be set from a document that is itself profile-specific:

```
InvalidConfigDataPropertyException: Property 'spring.profiles.active' imported from location
'class path resource [application-badactivation.yaml]' is invalid in a profile specific
resource [origin: ... - 12:13]
```

A profile that activates itself would change which files are loaded after the set of files had
already been decided. Boot refuses rather than half-applying it. `spring.profiles.include` has
the same restriction; `spring.config.activate.on-profile` is how you express the condition.

## `@Profile` is a different mechanism

`@Profile("prod")` on a bean is evaluated when the context is built, long after config data is
resolved. It decides which *beans* exist, not which *properties* are set. The two use the same
profile names and nothing else.