Cloudflare Flagship: Feature Flags From the Wrangler CLI

Cloudflare added wrangler flagship to its Wrangler CLI on July 16, 2026, letting developers create feature flags, run percentage-based rollouts and manage targeting rules for Cloudflare's Flagship service entirely from the terminal — including from CI/CD pipelines and AI agents, without touching a dashboard or redeploying a Worker.

What the new commands actually do

Flagship itself isn't new — Cloudflare announced the service on April 17, 2026, as a feature-flag platform built on OpenFeature, the CNCF's open standard for flag evaluation. What shipped on July 16 is CLI access to it. The new command suite covers the full flag lifecycle:

• wrangler flagship apps create — create a Flagship app tied to a project
• wrangler flagship flags create — define a flag as a boolean, string, number or JSON value
• wrangler flagship flags update — change a flag's default variation
• wrangler flagship flags enable / disable — use a flag as a kill switch
• wrangler flagship flags rollout — control exposure with a percentage-based rollout
• wrangler flagship flags split — distribute traffic across variations by weight
• wrangler flagship flags rules update — set targeting rules and priorities

The practical shift is that changing what a Worker does in production no longer requires a redeploy. A rollout percentage, a kill switch, or a targeting rule can change with one CLI command while the Worker itself stays untouched.

Why this matters specifically on Workers

Most feature-flag services evaluate flags one of two ways: an HTTP call to the provider on the request's critical path, or a local SDK that caches flag state in a long-lived process. Neither fits Cloudflare Workers well — an outbound call adds latency on every request, and Workers' isolates are ephemeral, so assumptions about a persistent in-memory cache don't hold.

Flagship runs on Cloudflare's own Workers, Durable Objects and KV, which is what lets flag checks stay inside the same edge request instead of leaving it. Cloudflare describes evaluation as sub-millisecond. Targeting rules support up to five levels of nested AND/OR logic and 11 comparison operators, and percentage rollouts use consistent hashing so the same user keeps getting the same variation across requests.

Binding a flag to a Worker

Flagship attaches to a Worker the same way KV or Durable Objects do — as a binding in wrangler.jsonc:

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

From inside the Worker, the binding exposes typed evaluation methods:

export default {
  async fetch(request, env) {
    const isEnabled = await env.FLAGS.getBooleanValue("my-feature", false, {
      userId: "user-42",
    });
 
    return new Response(isEnabled ? "Feature is on" : "Feature is off");
  },
};

getBooleanValue() takes a flag key, a default value, and an optional evaluation context object — the same pattern getStringValue(), getNumberValue() and getObjectValue() follow for other flag types. Because Flagship implements the OpenFeature standard, the same evaluation code works against server SDKs for TypeScript, Python and Go, and against browser SDKs, without a provider-specific rewrite.

What changes for developers today

Two things are worth separating. First, the CLI commands: wrangler flagship turns flag management into something you can script, put in a Makefile, or call from a deploy pipeline — the kind of workflow teams already expect for Workers KV namespaces or D1 databases. Second, AI coding agents get first-class access to the same surface: Cloudflare explicitly documents the commands as usable by agents to inspect flag state, change a flag's value, or roll a rollout back, which means an agent debugging a production issue can flip a kill switch through the same interface a human would use, instead of needing dashboard access or a custom integration.

The catch is status: Flagship remains in closed beta with no published pricing or GA date, so teams evaluating it today are evaluating a beta product, not a finished one. For a team already deploying to Workers, the CLI addition mainly lowers the cost of trying it — flag management fits into the same wrangler workflow used for everything else, rather than requiring a new dashboard habit or a third-party account.

Getting started

Requesting access is currently the only path in — Cloudflare's Flagship documentation points to a request-access form rather than self-serve signup. Once an app exists, the fastest way to see the CLI in action is wrangler flagship flags create for a single boolean flag, a binding added to wrangler.jsonc, and one getBooleanValue() call gating a code path — the same three-step loop teams already use for KV, applied to flags instead of key-value pairs.