Flag evaluation that stays at the edge

Feature flags have always been about separating deployment from release. As AI agents increasingly write, review, and deploy code autonomously, that separation becomes the primary safety mechanism: an agent ships a new code path behind a flag that is off by default, then gradually ramps it up for itself or a test cohort while observing production behavior. If something goes wrong, the flag is disabled instantly without a rollback. The human sets the boundaries; the flag controls the blast radius.

With that workflow in mind, Cloudflare is announcing Flagship, a native feature flag service built on OpenFeature, the CNCF standard for flag evaluation. Flagship is available in public beta and runs on Cloudflare's own infrastructure — Workers, Durable Objects, and KV — with no external databases or third-party services in the evaluation path.

BLOG-3237 hero image

Why Workers need a different approach

Developers on Workers have typically fallen back to hardcoding flag logic directly into their code. That works when there are a handful of flags: Workers deploy in seconds, so changing a boolean and pushing to production is fast. But the approach doesn't scale. Ten hardcoded flags become fifty, owned by different teams with no central visibility and no audit trail — when something breaks, the only way to find out who toggled what is git blame.

The other common pattern is querying an external feature flag service over HTTP. That puts an outbound request on the critical path of every user request:

const response = await fetch("https://flags.example-service.com/v1/evaluate", {
      ...
      body: JSON.stringify({
        flagKey: "new-checkout-flow",
        context: {
          ...
        },
      }),
    });
const { value } = await response.json();
if (value === true) {
    return handleNewCheckout(request);
}
return handleLegacyCheckout(request);

The result is unfortunate: user requests are handled at the edge, milliseconds from the user, yet the flag check forces a round trip across the Internet to a regional API before the application can decide what to render.

Local evaluation SDKs — which download all flag rules into memory and evaluate them in-process — solve the latency problem on traditional servers. But they don't translate to Workers. A Worker isolate can be created, serve a request, and be evicted before the next one arrives. Each new invocation may require re-initializing the SDK from scratch, because there is no long-lived process. What serverless platforms need is a distribution primitive that is already at the edge, with caching managed for the developer, reads that are local, and no persistent connections required. Cloudflare KV is exactly that primitive.

Architecture: Durable Objects for truth, KV for distribution

Flagship's control plane writes every flag creation or update atomically to a Durable Object — a SQLite-backed, globally unique instance that holds the authoritative flag configuration and changelog for an app. Within seconds, the updated config syncs to Workers KV, where it is replicated across Cloudflare's network.

At evaluation time, the flag config is read directly from KV at the same Cloudflare location already handling the request. The evaluation engine runs inside the local isolate: it matches request context against targeting rules, resolves any percentage rollout, and returns a variation. Both the data and the logic live at the edge; nothing is sent elsewhere for evaluation.

BLOG-3237 image 1

Two ways in: a Worker binding and an OpenFeature SDK

For teams on Workers, Flagship offers a direct binding that evaluates flags inside the Workers runtime — no HTTP round trip, no SDK overhead. Setup is a small addition to wrangler.jsonc:

{
  "flagship": [
    {
      "binding": "FLAGS",
      "app_id": "<APP_ID>"
    }
  ]
}

The account ID is inferred from the Cloudflare account; app_id ties the binding to a specific Flagship app. At runtime, asking for a flag value is a single call:

export default {
  async fetch(request: Request, env: Env) {
    // Simple boolean check
    const showNewUI = await env.FLAGS.getBooleanValue('new-ui', false, {
      userId: 'user-42',
      plan: 'enterprise',
    });
    // Full evaluation details when you need them
    const details = await env.FLAGS.getStringDetails('checkout-flow', 'v1', {
      userId: 'user-42',
    });
    // details.value = "v2", details.variant = "new", details.reason = "TARGETING_MATCH"
  },
};

The binding provides typed accessors for every variation type: getBooleanValue(), getStringValue(), getNumberValue(), and getObjectValue(), plus *Details() variants that return the resolved value along with the matched variant and the reason it was selected. Evaluation errors fall back to the default value; type mismatches throw an exception, since those are bugs in the calling code, not transient failures.

Rather than inventing a proprietary interface, Flagship is built on OpenFeature — the same relationship OpenTelemetry has to observability. Code is written once against the standard interface, and providers can be swapped with a single line of configuration:

import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipServerProvider } from '@cloudflare/flagship/server';
await OpenFeature.setProviderAndWait(
  new FlagshipServerProvider({
    appId: 'your-app-id',
    accountId: 'your-account-id',
    authToken: 'your-cloudflare-api-token',
  })
);
const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue(
  'new-checkout-flow',
  false,
  {
    targetingKey: 'user-42',
    plan: 'enterprise',
    country: 'US',
  }
);

On Workers, the Flagship binding can be passed directly to the OpenFeature provider. The binding already carries account context, so authentication is implicit:

import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipProvider } from '@cloudflare/flagship/server';
let initialized = false;
export default {
  async fetch(request: Request, env: Env) {
    if (!initialized) {
      await OpenFeature.setProviderAndWait(
        new FlagshipServerProvider({ binding: env.FLAGS })
      );
      initialized = true;
    }
    const client = OpenFeature.getClient();
    const showNewCheckout = await client.getBooleanValue('new-checkout-flow', false, {
      targetingKey: 'user-42',
      plan: 'enterprise',
    });
  },
};

Evaluation code doesn't change — the OpenFeature interface stays identical — but flags are evaluated through the binding rather than over HTTP. There's also a client-side provider for browsers that pre-fetches specified flags, caches them with a configurable TTL, and serves evaluations synchronously from cache.

Flag model and rollout semantics

Flag values can be booleans, strings, numbers, or full JSON objects, the last useful for configuration blocks, UI themes, or routing users to different API versions without maintaining separate code paths.

Each flag supports multiple targeting rules evaluated in priority order (lower number = higher priority), with the first match winning. A rule is composed of:

  • Conditions determining whether the rule applies to a given context
  • A flag variation to serve when the rule matches
  • An optional percentage-based rollout
  • A priority defining evaluation order among multiple rules

Conditions compose with AND/OR logic, nestable up to five levels deep. At the top level of a rule, multiple conditions combine with implicit AND — all must pass for the rule to match. Within each condition, AND/OR groups can express more complex logic:

(plan == “enterprise” AND region == “us” ) OR (user.email.endsWith(“@cloudflare.com”))
= serve (“premium”)

Percentage rollouts are distinct from gradual deployments, which split traffic between different uploaded Worker versions. Feature flags roll out behavior by percentage within a single version serving 100% of traffic. Any rule can include a rollout that serves a variation to only a percentage of the users who match the conditions.

Rollouts use consistent hashing on the specified context attribute, so a given attribute value — a userId, for example — always hashes to the same bucket and never flips between variations across requests. Ramping from 5% to 20% to 100% keeps users who were already in the rollout in it.

Built for autonomous shipping

Flagship's design targets the workflows that matter when AI-generated code lands in production continuously:

  • Evaluation at the edge, with flag configs cached globally via KV
  • A full audit trail, with field-level diffs on every flag change
  • Dashboard integration, so any team member can toggle a flag or adjust a rollout without touching code
  • OpenFeature compatibility, so adopting Flagship — or leaving it — requires no rewrite of evaluation code

Flagship is now in public beta. Teams can create a Flagship app from the Cloudflare dashboard, install the SDK with npm i @cloudflare/flagship, or use the Worker binding directly. Documentation, source code, and examples are available via the integration guides and the GitHub repository. Pricing details will be announced as the service approaches general availability.