A dynamic config is a feature flag that carries structured data (JSON objects, typed fields) instead of a simple boolean. Where a standard boolean flag answers "on or off?", a dynamic config answers "what configuration should this user see?" and delivers the specifics: colors, copy strings, layout parameters, pricing tiers, timeout values, or any combination of properties.
Dynamic configs are what make feature flags useful beyond toggles. A team experimenting with a new pricing page doesn't just need to show or hide the page. They need to control the price points, the plan names, the button labels, and the number of tiers displayed. A dynamic config delivers all of that in a single flag evaluation.
How do dynamic configs differ from boolean flags?
A boolean flag has two states: true or false, on or off. It controls whether something exists. A dynamic config has structured variants, each carrying a payload of typed values. It controls what something looks like and how it behaves.
In Confidence, this distinction is built into the flag model. A Confidence flag is a structured configuration with typed schemas, meaning a single flag can define multiple properties (a string, an integer, a boolean, a nested object) and each variant specifies values for all of them. You don't need one flag for "show new header" and another for "header color" and a third for "header copy." One flag handles the entire configuration surface.
This matters for experiment hygiene. When related settings are bundled in a single flag, there's no risk of configuration drift where one property updates but another doesn't. The variant is atomic: users get all the associated values together.
When should you use a dynamic config?
Multi-property experiments. You're testing a redesigned card component. The treatment variant needs a new layout, updated copy, a different image size, and a modified tap target. A dynamic config delivers all of these as a single variant payload.
Operational tuning. You want to adjust a timeout threshold, a retry count, or a cache TTL without deploying code. A dynamic config lets you change the value remotely. Combine it with targeting conditions and you can set different values per region, platform, or user segment.
Personalization parameters. Machine learning models often produce scores or recommendations that feed into the UI. A dynamic config can carry the model version, the number of recommendations to show, and the ranking weights, all controlled through the flag system rather than hardcoded.
What's the alternative?
Without dynamic configs, teams typically use one of two workarounds.
The first is multiple boolean flags: one for each property. This creates a coordination problem. You need to ensure all related flags update together, and a partial update (flag A changed but flag B didn't) puts users in an inconsistent state.
The second is embedding configuration in code and gating it behind a boolean flag. This works for simple cases, but every configuration change requires a code deploy. The point of feature flags is to decouple deployment from release. Embedding config in code re-couples them.
Confidence's structured flags avoid both workarounds. The flag schema is defined once, variants carry the full set of typed values, and evaluation happens locally in-process at microsecond latency.