Skip to content

SYSTEM Cited by 1 source

Cloudflare Flagship

Flagship is Cloudflare's native feature flag service (blog.cloudflare.com/flagship), announced 2026-04-17 in private beta. Built on OpenFeature (the CNCF open standard) and on Cloudflare's own developer-platform primitives (Workers, Durable Objects, Workers KV).

Framed explicitly in the launch post as the safety net for agent-shipped code — the bounded-blast-radius primitive an AI agent ramps itself against when shipping to production — see concepts/agent-controlled-deployment.

Architecture

Direct from the post (Cloudflare, 2026-04-17):

"When you create or update a flag, the control plane writes the change atomically to a Durable Object — a SQLite- backed, globally unique instance that serves as the source of truth for that app's flag configuration and changelog. Within seconds, the updated flag config is synced to Workers KV, Cloudflare's globally distributed key-value store, where it's replicated across Cloudflare's network. When a request evaluates a flag, Flagship reads the flag config directly from KV at the edge — the same Cloudflare location already handling the request. The evaluation engine then runs right there in an isolate."

Three layers:

  1. Control plane → per-app Durable Object. SQLite-backed, single-writer, holds the full flag config and the per-flag changelog. Writes land atomically.
  2. Config replication → Workers KV. Within seconds of a DO write, the new config is pushed to KV, which fans out globally to every edge POP.
  3. Edge evaluation → Workers isolate. The evaluation engine runs in the same V8 isolate already handling the user request, reads the flag config from local KV, matches the request context against the flag's rules, resolves any rollout percentage, and returns a variation. No outbound HTTP call.

This is the canonical wiki instance of patterns/do-plus-kv-edge-config-distribution (DO as source-of-truth, KV as edge-replicated read tier) and of patterns/in-isolate-rule-evaluation (eval in the same isolate serving the request, no network hop, no long-lived rules-cache SDK).

Why Workers makes "local-evaluation SDK" the wrong shape

Most third-party flag services offer a local-evaluation SDK: download all rules into memory once, evaluate locally per request, refresh in the background. On a serverless isolate substrate that assumption collapses, and the post names it explicitly:

"On Workers, none of these assumptions hold. There is no long-lived process: a Worker isolate can be created, serve a request, and be evicted between one request and the next. A new invocation could mean re-initializing the SDK from scratch. On a serverless platform, you need a distribution primitive that's already at the edge, one where the caching is managed for you, reads are local, and you don't need a persistent connection to keep things up to date. Cloudflare KV is a great primitive for this!"

KV replaces the in-process rules cache as the distribution primitive — cache warmup / refresh is the platform's problem, not the SDK's.

Worker binding

// wrangler.jsonc
{
  "flagship": [
    { "binding": "FLAGS", "app_id": "<APP_ID>" }
  ]
}

"Your account ID is inferred from your Cloudflare account, and the app_id ties the binding to a specific Flagship app."

Typed accessors for every variation type:

  • env.FLAGS.getBooleanValue(key, default, context)
  • env.FLAGS.getStringValue(key, default, context)
  • env.FLAGS.getNumberValue(key, default, context)
  • env.FLAGS.getObjectValue(key, default, context)
  • *Details() variants return value + variant + reason (e.g. reason: "TARGETING_MATCH").

Failure semantics, named in the post:

  • Evaluation errors → default value returned gracefully.
  • Type mismatches → binding throws. "That's a bug in your code, not a transient failure." Load-bearing because silently coerced object/JSON flags would corrupt downstream.

OpenFeature as the SDK surface

Flagship is an OpenFeature provider:

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',
  })
);

The post's explicit framing (word-for-word):

"You write your evaluation code once against the standard, and swap providers by changing a single line of configuration."

A client-side browser provider pre-fetches flags the developer specifies and caches them with a configurable TTL, serving evaluations synchronously from the cache.

Rule model

A rule has four parts:

  • Conditions — implicit-AND at the top level; nested AND/OR groups up to 5 levels deep.
  • Variation — the value to serve on match.
  • Optional rollout — serve the variation to a percentage of matching contexts using consistent hashing on a chosen context attribute.
  • Priority — lower number = higher priority; first match wins.

Post-supplied example:

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

Values can be boolean, string, number, or full JSON object — the JSON-object variation collapses the "flag service vs. config store" distinction on the edge (one distribution primitive covers both).

Percentage rollout vs. gradual deployment

"Unlike gradual deployments, which split traffic between different uploaded versions of your Worker, feature flags let you roll out behavior by percentage within a single version that is serving 100% of traffic."

Rollouts use consistent hashing on the specified context attribute (typically userId):

"The same attribute value (userId, for example) always hashes to the same bucket, so they won't flip between variations across requests. You can ramp from 5% to 10% to 50% to 100% of users, so those who were already in the rollout stay in it."

The ramp-safety guarantee — monotonic bucket growth — lives on consistent hashing, not on flag state. See concepts/percentage-rollout.

Production-grade surface claimed

From the closing section of the post:

  • Evaluation across region Earth, cached globally using KV.
  • Full audit trail — every change recorded with field- level diffs; "you know who changed what and when". See concepts/audit-trail.
  • Dashboard integration — anyone on the team can toggle a flag or adjust a rollout without touching code.
  • OpenFeature compatibility — "Adopt Flagship without rewriting your evaluation code. Leave without rewriting it either."

The agent-controlled-deployment framing

The launch lede is not "a better flag service" but "flags are the substrate that makes agent-driven shipping safe":

"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. The human doesn't need to be in the loop for every step — they set the boundaries, and the flag controls the blast radius."

Canonical wiki instance of concepts/agent-controlled-deployment — the flag is bounded-blast-radius-as-primitive.

Availability

Caveats

  • Private beta, no GA pricing, no published SLOs for DO→KV propagation beyond "within seconds".
  • No flag-count / rule-size / JSON-object-size limits published per app.
  • Rule-evaluation CPU on hot paths is billable Worker CPU; deep 5-level-nested rules consume more.
  • Client-side browser provider staleness is a configurable-TTL knob with no post-supplied default guidance.

Seen in

Last updated · 200 distilled / 1,178 read