CONCEPT Cited by 1 source

Feature flag¶

A feature flag is a runtime switch that gates a code path by context, rollout percentage, or targeting rule — enabling release to be decoupled from deploy and cohort-scoped rollouts. The code is in production but inert until the flag turns on for some population; ramping is a config change, not a redeploy.

The basic decoupling¶

Without flags, deploy-day = release-day — every user gets the new code path the moment the binary/Worker goes live. With flags:

Deploy: new code ships behind if (flag(...)) { new } else { old }. Flag is off. Nothing changes for users.
Release: flip the flag on — for one user, one cohort, a percentage, a region — watch metrics.
Revert: flip the flag off. Seconds, not a rollback deploy.

This is why flags are the substrate for agent-controlled deployment: the blast radius is bounded by the flag state, which is itself a fast, auditable control-plane edit.

Evaluation model¶

A flag typically has:

Variations — the possible returned values (boolean, string, number, or full JSON object — see Flagship's four variation types).
Rules — conditions evaluated in priority order, first-match wins, each mapping a matching context to a variation (plus an optional percentage rollout).
Default — returned on evaluation error or when no rule matches.

Rules compose via AND/OR — Flagship allows up to 5 levels of nesting, implicit AND at the top of a rule, nested AND/OR groups below.

What's hardcoded flags¶

The anti-pattern is "just commit a boolean and redeploy" — works at one or two flags, collapses at ten:

"One hardcoded flag becomes ten. Ten becomes fifty, owned by different teams, with no central view of what's on or off. There's no audit trail — when something breaks, you're searching git blame to figure out who toggled what." (Source: Cloudflare Flagship, 2026-04-17)

A proper flag service adds: central catalog, dashboard UI, audit trail, rule evaluation engine, rollout ramping with stable bucketing, and vendor-neutral call-site API via OpenFeature.

Evaluation-location trade-offs¶

Where the flag(context) call runs matters:

Remote evaluation (HTTP to flag service) — every user request waits on an outbound call. Centralized, easy to update, but "sits on the critical path of every single user request. It could add considerable latency." (Source: sources/2026-04-17-cloudflare-introducing-flagship-feature-flags-built-for-the-age-of-ai.)
Local-evaluation SDK — rules downloaded into memory, evaluated in-process, refreshed in the background. Assumes a long-lived process; breaks on serverless isolate substrates where "a Worker isolate can be created, serve a request, and be evicted between one request and the next."
Edge-local evaluation against a replicated config store — evaluation in the same runtime isolate that serves the request, reading config from an edge-replicated KV cache; no outbound hop, no long-lived SDK. See patterns/in-isolate-rule-evaluation + patterns/do-plus-kv-edge-config-distribution.

Not just for humans¶

The 2026-04-17 Cloudflare Flagship launch is explicit that the motivating user is an AI agent, not a release manager:

"An agent writes a new code path behind a flag and deploys it — the flag is off, so nothing changes for users. The agent then enables the flag for itself or a small test cohort, exercises the feature in production, and observes the results. If metrics look good, it ramps the rollout. If something breaks, it disables the flag."

See concepts/agent-controlled-deployment.

Seen in¶

sources/2026-04-17-cloudflare-introducing-flagship-feature-flags-built-for-the-age-of-ai — canonical wiki introduction; Flagship is the OpenFeature- native Cloudflare-built primitive, framed explicitly as the bounded-blast-radius substrate for agent-driven shipping.