Guide

Feature flag guide

Feature flags (often called feature toggles) let you change application behaviour without deploying new code. Used well, they reduce release risk; used carelessly, they add long-term complexity. This page summarises the ideas teams usually need first.

What a feature flag actually is

At its core, a flag is a named decision point: given a context (user, environment, random bucket, etc.), the system chooses one of several variants — often just “on” or “off.” The important part is that the decision can be updated centrally and quickly, separate from a full rollout of new binaries or containers.

When flags tend to help

Gradual rollouts — ship code to production early while limiting who sees new behaviour.
Kill switches — turn off a path that is misbehaving without redeploying.
Operational modes — maintenance windows, degraded functionality, or provider fallbacks.
Experimentation — compare variants for product or infrastructure changes (with appropriate measurement and ethics guardrails).

Patterns worth knowing

Release toggles vs long-lived toggles

Many teams distinguish short-lived “release” toggles (meant to be removed after a launch) from long-lived configuration or entitlement toggles. Mixing the two without naming or ownership conventions is a common source of confusion.

Server-side vs client-side evaluation

Evaluating flags on the server usually keeps rules and data safer and avoids leaking targeting logic. Client-side evaluation can be right for UX experiments or offline behaviour, but think through consistency, caching, and what attackers can observe.

Defaults and failure behaviour

Decide what happens when the flag service is slow or unavailable. Safe defaults — and clear metrics for flag evaluation errors — prevent invisible outages.

Hygiene that pays off

Name flags so the intent and owning team are obvious; include ticket or lifecycle hints when helpful.
Remove or archive release toggles on a schedule; treat stale flags as technical debt.
Document who can change production values and how changes are reviewed (especially in regulated environments).
Correlate flag changes with observability — deploys alone do not tell the whole story anymore.

Rest of this guide

These sections sit alongside this overview — use the header menu “Feature flag guide” anytime to jump between them:

See Libraries and links for SDK starting points. Use Search to jump across topics.

If you adopt a managed platform, vendor documentation remains the source of truth for APIs — for example Featureflow docs for integration detail.