By Feature flags have a dirty secret: they add a network call. Every time your application checks whether a feature is enabled, it reaches out to LaunchDarkly, Unleash, or Split.io — and that trip costs you. Optimized implementations get down to 25ms. Real-world averages run higher. For AI agents and high-frequency edge workloads, that cost compounds fast. Cloudflare’s new Flagship service eliminates it entirely.
Flagship, currently in private beta, evaluates feature flags inside your Cloudflare Worker using a native binding that reads flag configuration directly from KV at the same edge location handling the request. No HTTP round-trip. No external dependency. The evaluation happens in the same isolate as your code, making flag checks effectively free.
How the Binding Works
The integration starts in your wrangler.jsonc:
{
"flagship": [
{ "binding": "FLAGS", "app_id": "<APP_ID>" }
]
}That binding wires Flagship directly into your Worker’s environment. Authentication is implicit — no API keys to manage in code, no SDK initialization that requires network access. In your Worker, you use the standard OpenFeature SDK with Cloudflare’s provider:
import { OpenFeature } from "@openfeature/server-sdk";
import { FlagshipServerProvider } from "@cloudflare/flagship";
await OpenFeature.setProviderAndWait(
new FlagshipServerProvider({ binding: env.FLAGS })
);
const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue(
new-checkout-flow,
false,
{ targetingKey: userId, plan: userPlan, country: userCountry }
);If the flag doesn’t exist or evaluation fails, you get the default value. Flagship is built to fail safe.
OpenFeature: The Part That Actually Matters
Flagship is built on OpenFeature, the CNCF standard for vendor-neutral feature flag evaluation. This is not marketing language — it is the reason Flagship is worth paying attention to even before it reaches general availability.
OpenFeature separates flag evaluation logic from the backend that stores and manages flags. Your application code calls client.getBooleanValue(). Whether that resolves against Flagship, LaunchDarkly, Unleash, or a local stub for testing is the provider’s job — not your code’s. Swapping backends is a provider swap, not a refactor. Teams that built on vendor-specific SDKs are now locked in; teams that adopted OpenFeature are not.
The feature flag ecosystem has consolidated around OpenFeature. LaunchDarkly, Flagsmith, Unleash, Flipt, and DevCycle all publish spec-compliant providers. Cloudflare joining with a native edge provider closes the last gap: latency.
Targeting and Rollouts
Flagship supports the targeting patterns that matter in production. Flags can evaluate to boolean, string, number, or full JSON objects — useful for routing users to different API versions or serving dynamic configuration blocks without redeployment.
Targeting rules run in priority order. Each rule matches on context attributes (user ID, plan tier, country, any attribute you pass), and percentage rollouts use consistent hashing: a given user ID always maps to the same bucket. When you ramp from 5% to 10% to 50%, users who were in the rollout stay in it. No flipping, no inconsistent experiences mid-session.
Why This Lands Now: The AI Agent Problem
Cloudflare titled its announcement “feature flags built for the age of AI,” and the framing is accurate. AI agents ship code fast and constantly — but shipping AI behavior changes without a rollout mechanism is dangerous. A new prompt, a different model, a changed tool list can degrade output quality in ways that are subtle and slow to catch.
Feature flags solve this: the agent deploys behind a flag, enables it for 5% of traffic, watches for quality degradation, and ramps up only when the signal is clean. The flag is the deploy gate. When that check runs inside a Worker with sub-millisecond evaluation, it stops being a tax and becomes the default pattern for every AI feature shipped through the edge.
This is why edge-native flag evaluation matters for agent workloads specifically: agents handling thousands of requests per second cannot afford 25ms per flag check. Flagship makes the check cost-neutral.
Access and What to Expect
Flagship is in private beta with no published pricing yet. You can request access through Cloudflare’s developer docs, and the GitHub repository is public for those who want to read the provider implementation. Pricing details are expected at general availability — Cloudflare’s pattern is to meter storage (KV) and execution (Workers) at low per-unit costs, which favors high-volume workloads over the per-seat models used by SaaS alternatives.
If you are running workloads on Cloudflare Workers, request access now. If you are not on Workers, the OpenFeature standard still applies: build against the standard SDK today, and migrating to Flagship — or any other provider — when you are ready will be a provider swap, not a rewrite. InfoQ’s coverage captures the developer community reaction if you want a second take on the announcement.
