skip to content

What is spring.profiles.group and why would you use it?

level: seniorimportance: should knowfreq 45%

answer

  1. Group = parent profile fans out to children
  2. Activate parent -> children auto-active
  3. Boot 2.4+ replacement for include-in-profile-file
  4. Declared in base application.yaml
  5. One operator switch -> many infra profiles

basics

~10 s

spring.profiles.group lets you define a named group of profiles so activating one profile automatically activates several others. For example, activating 'prod' can pull in 'db-prod' and 'metrics' together.

solid answer

~40 s

spring.profiles.group (Spring Boot 2.4+) defines profile groups: a parent profile name mapped to a list of child profiles. When the parent is activated (via spring.profiles.active), all children are activated too, and their application-{child}.yaml files and @Profile(child) beans switch on. It replaces the pre-2.4 pattern of using spring.profiles.include inside profile-specific documents, which the config-data model disallowed. Groups are declared in the base application.yaml, keeping the operator-facing switch simple: they set active=prod and the app expands it into the full fan-out of infrastructure profiles. The expansion is recursive-ish only to one level of the declared groups; the group definition itself lives with unconditional config, not inside a profile-activated document.

code

java · 14 lines
java
// application.yaml
// spring:
//   profiles:
//     group:
//       prod:
//         - db-postgres
//         - metrics
//     dev:
//       - db-h2
//
// Run: --spring.profiles.active=prod
// Effective active profiles: prod, db-postgres, metrics
//
// @Profile("db-postgres") beans load; application-metrics.yaml loads.

go deeper

for a junior

May not know groups; enough to recognize the term.

for a middle

Knows a group activates several profiles from one name.

for a senior

Should explain the 2.4 motivation, that it replaces include-in-profile-files, and where it must be declared.

for a principal

Uses groups to design a clean operator-facing profile taxonomy; distinguishes group vs include vs active intents.

### The problem it solves Real apps often need to flip **several** profiles together — e.g. going to production means `prod` behavior *plus* `db-postgres` *plus* `metrics` *plus* `secure-cookies`. Making operators type `spring.profiles.active=prod,db-postgres,metrics,secure-cookies` is error-prone. Before Boot 2.4 you'd use `spring.profiles.include` inside `application-prod.yaml` to pull in others — but the 2.4 config-data model **forbids activating/including profiles from within a profile-specific document**. `spring.profiles.group` is the sanctioned replacement. ### Declaring a group In the **base** `application.yaml` (unconditional config): ```yaml spring: profiles: group: prod: - db-postgres - metrics - secure-cookies dev: - db-h2 - debug-logging ``` Now activating **`prod`** (`spring.profiles.active=prod`) makes the **effective active set** `{prod, db-postgres, metrics, secure-cookies}`. Each of those pulls in its own `application-{name}.yaml` and any `@Profile(name)` beans. ### Semantics and edge cases - The group definition must live where it is **always processed** (base file / unconditional document), because profile-conditional documents can't influence activation. - Activating a child directly (e.g. `active=metrics`) does **not** activate the parent — expansion only goes parent → children. - The parent profile itself is also active, so `@Profile("prod")` beans still load in addition to the children. - Groups compose the *active* set that then drives file loading and bean selection; precedence among the resulting profile files still follows the normal layering rules (later-resolved wins). - You can inspect the resolved set via `Environment.getActiveProfiles()` or the `/actuator/env` endpoint. ### spring.profiles.group vs. include vs. active - `spring.profiles.active`: the entry-point set an operator sets. - `spring.profiles.group`: static mapping that **expands** a parent into children when the parent is active. - `spring.profiles.include`: unconditionally adds profiles to the active set (from base config), regardless of what's active — different intent (always-on additions vs. conditional expansion). ### When to use Use groups to give operators a **single meaningful switch** per environment while keeping the underlying infrastructure profiles modular and independently reusable. Avoid over-nesting; keep group names aligned with deployment environments.

  • Why was spring.profiles.group introduced instead of continuing with spring.profiles.include inside profile files?
    Boot 2.4's config-data model forbids activating or including profiles from within a profile-specific document. Groups provide a declarative parent->children expansion that lives in unconditional base config, satisfying that restriction.
  • If I activate a child profile directly, does its parent group activate?
    No. Expansion only flows parent to children. Activating a child does not activate the parent or its other children.

saying these in an interview costs you the question

  • Thinking activating a child profile activates its parent group
  • Declaring the group inside a profile-specific file
  • Confusing group (conditional expansion) with include (unconditional addition)

context

resolving links…