Every feature flag evaluation in a traditional setup costs you a network round trip. LaunchDarkly, Split, Unleash — they all require either an HTTP call to a remote API or a local SDK that initializes by polling. In a serverless Worker that starts cold, that is a 25ms tax before you have done any real work. Cloudflare’s Flagship eliminates it. Flags live in Workers KV, evaluated in the same isolate as your request, at zero additional latency. On July 16, Cloudflare added full Wrangler CLI support, and you can now manage your entire flag lifecycle from the terminal or a CI/CD pipeline without opening a dashboard.
What Flagship Does Differently #
Most feature flag services work like this: your server starts, the SDK contacts a flag evaluation service, downloads the current flag state, and caches it locally. Every subsequent evaluation reads from that cache. The catch is that “locally” is relative — in a serverless environment, there is no persistent process. Every cold start re-initializes from scratch. LaunchDarkly’s edge integration reduces this to 5–15ms via Vercel Edge Config, but you are still paying for a lookup that is architecturally separate from your Worker.
Flagship’s architecture is simpler. Flag configuration lives in Workers KV. Your Worker reads it from the same KV namespace that Cloudflare’s network is already serving at your edge location. No HTTP call. No SDK initialization. The evaluation runs in your isolate, with your code, on the same machine. That is not a minor optimization — it is a category difference for latency-sensitive applications.
OpenFeature: Why the Standard Matters #
Flagship is built on OpenFeature, the CNCF’s vendor-neutral feature flag standard. If you have used OpenTelemetry for observability, OpenFeature plays the same role for flags: a common evaluation interface with the actual provider swappable behind it. This is an unusual move for a vendor. Building on an open standard makes it easy for customers to leave. The fact that Cloudflare did it anyway signals that the network and latency advantages are confident enough to stand on their own.
In practice, you can use Flagship two ways inside a Worker. The native binding is faster:
const showNewCheckout = await env.FLAGS.getBooleanValue(
"new-checkout",
false,
{ userId }
);
If you need portability or you are running the same flag logic outside Workers (Node.js, Python, Go), use the OpenFeature SDK instead:
await OpenFeature.setProviderAndWait(
new FlagshipServerProvider({ binding: env.FLAGS })
);
const showNewCheckout = await OpenFeature.getClient()
.getBooleanValue('new-checkout', false);
The second approach adds a small indirection cost but means your evaluation code does not need to change if you swap providers later.
Setting Up in Under Five Minutes #
Get started via the Flagship getting started guide: create an app in the dashboard under Compute > Flagship, grab the app ID, and add the binding to your wrangler.jsonc
:
{
"flagship": [
{
"binding": "FLAGS",
"app_id": "your-app-id"
}
]
}
Run npx wrangler types
to generate TypeScript definitions. Flag changes propagate globally in seconds — no redeployment needed.
The Wrangler CLI Update: Full Control From the Terminal #
The July 16 changelog is the practical news hook. Wrangler now ships a wrangler flagship
command suite covering the full flag lifecycle:
wrangler flagship apps create "checkout-service" --binding FLAGS --update-config
wrangler flagship flags create new-checkout
wrangler flagship flags rollout new-checkout --variation enabled --percentage 10
wrangler flagship flags disable new-checkout
Before this update, flag management required the dashboard. Now it is scriptable. Wire these commands into GitHub Actions, run them from a deploy script, or let a coding agent trigger a rollout after tests pass.
Feature Flags as AI Agent Safety Infrastructure #
Cloudflare’s launch post makes the agent use case explicit. A coding agent writes a new code path and deploys it behind a flag that starts off. No users are affected. CI runs, tests pass, the agent calls wrangler flagship flags rollout
at 10%. It monitors error rates and either rolls to 100% or rolls back. The agent controls the entire deployment lifecycle without human intervention, and the flag is the guardrail that keeps a broken build from reaching users.
For teams running agentic deployment pipelines, this is the architectural piece that has been missing: a feature flag system that is natively programmable and natively edge. No external service to authenticate against inside the Worker. No HTTP call. The flag evaluation is local.
What Is Not Available Yet #
Flagship is in private beta with pricing not yet announced. The launch post has access requests open but no self-serve GA timeline. There is no native experimentation framework — no statistical significance tracking — and targeting rule depth will not match LaunchDarkly’s full enterprise governance suite for teams deep in experimentation workflows. For teams using Workers and not needing heavy analytics, it removes an entire category of infrastructure overhead. For everyone else, the private beta is the path in for now.