Cloudflare Flagship — feature flags inside Workers

Every feature flag SaaS on the market — LaunchDarkly, Flagsmith, Unleash — shares one architectural assumption: when your code wants to evaluate a flag, it makes an outbound HTTP call to a central evaluation server. On a traditional server that round-trip adds tens of milliseconds and is easy to ignore. On Cloudflare Workers, where your entire execution budget is measured in single-digit milliseconds, that outbound call is a structural problem.

Cloudflare's answer landed on May 26: Flagship, a native feature flag service for Workers that evaluates flags using a local binding — no outbound HTTP, no extra vendor endpoint, no added latency. 1

The announcement came through a Changelog entry rather than a blog post — which underplays its significance. Flagship is not a minor Workers update. It's a new product category for the platform: the first Cloudflare-native feature flag service, backed by Workers KV for global propagation and Durable Objects as the single source of truth for flag state. 2 3

Flag configuration changes propagate globally "within seconds" after saving — no Worker redeployment required. If the Cloudflare dashboard is temporarily unavailable, evaluation continues against the last-propagated configuration rather than failing open or closed. 3

Kristian Freeman (Cloudflare) pointed out the behavior that most distinguishes this from in-app feature flag libraries:

That "originless" pattern — using flags to route traffic before it ever reaches your application server — has no equivalent in existing feature flag SaaS products that run inside application code. 4

The API surface is deliberately minimal. A Worker accesses its Flagship application through env.FLAGS — a binding declared in wrangler.toml pointing to a specific Flagship app. The binding exposes nine methods: get(), getBooleanValue(), getStringValue(), getNumberValue(), getObjectValue<T>(), and *Details variants for each typed method. 5

The *Details variants return evaluation metadata alongside the flag value — including the reason field ("TARGETING_MATCH", "DEFAULT"), variant, errorCode, and errorMessage. None of the evaluation methods throw exceptions; they always return a value, falling back to the provided defaultValue on any error.

Evaluation context — the user attributes used for targeting rules — is passed as a plain Record<string, string|number|boolean> as the third argument to any evaluation call. Flagship supports 4 variant types (boolean, string, number, JSON object), 11 targeting operators (equals, contains, starts_with, in, not_in, and numeric comparisons), AND/OR logic groups nested up to 6 levels, and consistent-hash percentage rollouts that guarantee the same user always gets the same flag value across requests. 6 7

A single Worker can bind multiple Flagship apps. Each app appears as a separate Flagship-typed property in the env object.

For teams already on Workers, the migration path is the smoothest available. Flagship implements the OpenFeature standard (CNCF), which means the TypeScript SDK drop-in is literal: replace new LaunchDarklyProvider({ sdkKey }) with new FlagshipServerProvider({ binding: env.FLAGS }). Evaluation call sites — every client.variation(...) or client.boolVariation(...) in your application — require zero changes. 8

As the Cloudflare docs state directly: "If you use another OpenFeature-compatible provider (for example, LaunchDarkly or Flagsmith), switch to Flagship by replacing the provider initialization. No changes are needed at evaluation call sites." 8

The SDK ships two hooks out of the box — LoggingHook for structured evaluation logging and TelemetryHook for timing and observability data — so the observability surface most flag services charge for is included. 9

Beyond the migration mechanics, the elimination of a third-party vendor matters operationally. You go from managing API keys for an external SaaS, monitoring its status page, and paying its per-evaluation billing to using a native Workers binding that scales with your existing Workers plan. For teams spending upward of $500/month on LaunchDarkly, the reduction in vendor surface and per-evaluation billing alone justifies a serious look. 10

The browser-side SDK (FlagshipClientProvider) pre-fetches all flag values at initialization and evaluates from in-memory cache synchronously thereafter — no per-evaluation network call from the client. This model works well for flag-gating UI features where you want zero render-blocking delay.

No pricing, three days after launch. As of May 29, Cloudflare has published zero pricing information for Flagship — no free-tier limits, no paid tier costs, no per-evaluation pricing. Other Cloudflare services announced this week (Pipelines, R2 SQL, R2 Data Catalog) each shipped with explicit pricing pages and the standard "billing not yet enabled, 30-day notice" language. Flagship has neither. 10 Third-party analysts speculate Cloudflare will use usage-based pricing consistent with its other developer products, but that's an assumption, not a commitment.

The client-side API token is account-scoped, not app-scoped. Kelly (TechPlanet) flagged this explicitly: the API token used with FlagshipClientProvider in browser code can evaluate flags across all applications in the account, not just the one you intend. 11 Cloudflare says app-scoped tokens are in development, but they're not available in the current beta. For teams with multiple applications on the same Cloudflare account, this is a meaningful security constraint before exposing a token in client-side code.

No enterprise governance layer. LaunchDarkly's core competitive moat isn't the flag evaluation engine — it's change approvals, audit trails, compliance reporting, and experimentation frameworks. Flagship has audit history in the dashboard, but no approval workflows, no scheduled flag changes, and no experiment analysis. For teams that need those controls, Flagship is not a replacement today. 12

Python SDK is HTTP-only. The cloudflare-flagship PyPI package supports flag evaluation via the Flagship HTTP endpoint — not via a Workers binding. This means Python workloads that need sub-millisecond evaluation can't use the binding model, only the standard network-hop approach. 9

Here's how the options compare on the dimensions that matter most for a Workers deployment:

Migrate now if: you're actively deploying on Cloudflare Workers and your team is paying for an external feature flag service. The OpenFeature-compatible provider swap is low-effort — a few lines in your provider initialization — and the zero-HTTP evaluation model directly improves the latency profile of every request that hits a flagged code path. The beta works in non-production environments today, and the Worker-level originless routing capability (routing traffic before it reaches your app) isn't available from any other feature flag provider. 4

Start the migration in staging, hold on production if: you use client-side flag evaluation across multiple Cloudflare apps, until app-scoped tokens are released. The account-level token scope in the current beta is a real security consideration before exposing tokens in browser JavaScript. 11

Watch and wait if: your stack is not on Cloudflare Workers. The binding-model evaluation — the feature that makes Flagship compelling — only exists inside a Worker. Running Flagship from Node.js, a container, or a non-Cloudflare edge runtime uses the HTTP evaluation endpoint, which offers no latency advantage over any other flag SaaS. Wait for pricing to be public before evaluating the total cost of switching.

Don't migrate if: your team relies on LaunchDarkly's approval workflows, scheduled rollouts, or experimentation framework. Flagship replaces the evaluation engine cleanly, but the governance layer is missing entirely. The flag evaluation core is solid; the organizational controls around it aren't there yet.

The HN thread on launch day surfaced one durable observation worth keeping: feature flags accumulate. Teams that treat them as short-lived shipping tools stay ahead of the debt; teams that let flags live for quarters end up with an undocumented configuration layer that's harder to reason about than the code it was supposed to protect. 12 Flagship makes the evaluation infrastructure easier — the flag hygiene problem it doesn't solve.