Profile presets

TL;DR. Four shipped Spring profiles (pulse-dev, pulse-prod, pulse-test, pulse-canary) tune Pulse for that environment. Activate the matching profile yourself. Auto-detect of dev/prod/test/canary is opt-in via pulse.profile-presets.auto-apply=true.

Adopting Pulse means deciding what every knob should be in dev vs prod vs canary. Most teams default everything and discover the wrong choices in production: 100 % trace sampling on a busy service, the cardinality firewall silently bucketing test users in CI, the trace-context guard rejecting curl requests during local debugging.

Pulse ships four presets that pick the right defaults for you. Each one is a standard Spring profile YAML at the standard location (application-pulse-{env}.yml) — Spring Boot loads them automatically when the matching profile is active. Everything is overridable.

What you get

Preset	Mode	Sampling	Banner	Trace-guard rejects?	Cardinality firewall	Notes
pulse-dev	ENFORCING	100 %	on	no	5 000/meter (loose)	Friendly to forgotten headers
pulse-prod	ENFORCING	10 %	off	no	1 000/meter	Strict, low overhead
pulse-test	ENFORCING	0 %	off	no (filter off)	off	Quiet, deterministic, fast
pulse-canary	DRY_RUN	100 %	on	observed	1 000/meter, observe-only	Safe-rolling lever for new fleets

Turn it on

Two ways. Pick one.

1. Activate a Pulse preset explicitly. Pulse ships these as ordinary Spring profiles:

spring:
  profiles:
    active: prod,pulse-prod

2. Auto-detect (opt-in). Pulse can append the matching pulse-* profile when it sees dev / prod / test / canary in spring.profiles.active. This is off by default because silently adding pulse-prod (and its 10% sampling rate) is a surprising change.

pulse:
  profile-presets:
    auto-apply: true

SPRING_PROFILES_ACTIVE=prod,pulse-prod ./mvnw spring-boot:run

Every property the preset sets is overridable — set the same key in your own profile YAML or application.yml and your value wins.

Customising

Teach Pulse about your own profile names:

pulse:
  profile-presets:
    auto-apply: true
    presets:
      stage: pulse-prod
      qa: pulse-test

What it adds

Just configuration. No new beans (other than the EPP). The presets reference the same pulse.* properties documented elsewhere; reading the YAMLs themselves is the fastest way to see exactly what changes:

$ jar -tf pulse-spring-boot-starter-2.0.2.jar | grep '^application-pulse'
application-pulse-dev.yml
application-pulse-prod.yml
application-pulse-test.yml
application-pulse-canary.yml

When to skip it

You manage all pulse.* values centrally (Vault, Spring Cloud Config, Kubernetes ConfigMap) and don't want a profile file in the chain. That is fine — set pulse.profile-presets.auto-apply=false and don't activate any pulse-* profile. Pulse's compiled-in defaults are also production-safe; the presets are a shortcut, not a requirement.

Under the hood

The presets are plain Spring profile YAMLs at the standard location, so Spring Boot's config-data loader picks them up like any other application-{profile}.yml — properties merge into the environment in declaration order, so anything you set in your own config wins over the preset.

PulseProfilePresetEnvironmentPostProcessor runs at order HIGHEST_PRECEDENCE + 5, before Spring Boot's ConfigDataEnvironmentPostProcessor (HIGHEST_PRECEDENCE + 10), so the profile it appends is visible by the time Spring scans for matching application-{profile}.yml files.

The presets are pure configuration — no enabled-when matchers, no feature-specific @Bean overrides — so they compose cleanly with anything else you load. If you want a preset plus per-environment beans, declare an @Configuration class and @Profile-gate it as usual.

---

Source: application-pulse-*.yml · PulseProfilePresetEnvironmentPostProcessor · Status: Stable since 1.1.0