Cloudflare introduces Flagship, an OpenFeature-based flag service

Cloudflare introduced Flagship on April 17, a native feature-flag service built around the CNCF OpenFeature standard. The launch post says the service supports Workers, Node.js, Bun, Deno, and browsers, with an edge-local evaluation path optimized for Workers.

Configuration and evaluation follow different paths

When an operator creates or updates a flag, Flagship stores the change atomically in a Durable Object that acts as the source of truth for an application’s configuration and changelog. The configuration then synchronizes to Workers KV. At request time, a Worker reads the replicated configuration and evaluates targeting rules inside its isolate, avoiding a remote evaluation call on every request.

That architecture favors low-latency reads, but it also means rollout code should account for propagation time. An update recorded in the control plane is not proof that every location has observed it at the same instant. Cloudflare updated the post on May 26 to say Flagship had entered public beta; the original April event remains the product announcement.

Flags need owners and retirement dates

A safe rollout should define who may change a flag, which metric stops expansion, and how the team verifies that a requested variation reached each cohort. Automated agents can operate within those rules, but disabling a flag is only a useful recovery mechanism when the old path remains tested.

Long-lived flags create branches that are easy to forget. Teams should attach an owner, intended lifetime, and removal issue when each flag is created. They should also avoid using a feature flag as the sole authorization boundary, because application permissions require stronger invariants than a rollout control.

Flagship brings flag evaluation into Cloudflare’s existing runtime and data primitives. Its operational benefit will depend on disciplined rollout policy and cleanup as much as evaluation speed.