characteristic flags constructed for the age of AI

AI is writing extra code than ever. AI-assisted contributions now account for a quickly rising share of recent code throughout the platform. Agentic coding instruments like OpenCode and Claude Code are delivery total options in minutes.

AI-generated code getting into manufacturing is simply going to speed up. However the larger shift is not simply pace — it is autonomy.

In the present day, an AI agent writes code and a human opinions, merges, and deploys it. Tomorrow, the agent does all of that itself. The query turns into: how do you let an agent ship to manufacturing with out eradicating each security internet?

Characteristic flags are the reply. An agent writes a brand new code path behind a flag and deploys it — the flag is off, so nothing modifications for customers. The agent then permits the flag for itself or a small check cohort, workout routines the characteristic in manufacturing, and observes the outcomes. If metrics look good, it ramps the rollout. If one thing breaks, it disables the flag. The human would not must be within the loop for each step — they set the boundaries, and the flag controls the blast radius.

That is the workflow characteristic flags had been all the time constructing towards: not simply decoupling deployment from launch, however decoupling human consideration from each stage of the delivery course of. The agent strikes quick as a result of the flag makes it secure to maneuver quick.

In the present day, we’re saying Flagship — Cloudflare’s native characteristic flag service, constructed on OpenFeature, the CNCF open customary for characteristic flag analysis. It really works all over the place — Staff, Node.js, Bun, Deno, and the browser — however it’s quickest on Staff, the place flags are evaluated inside the Cloudflare community. With the Flagship binding and OpenFeature, integration appears to be like like this:

await OpenFeature.setProviderAndWait(
    new FlagshipServerProvider({ binding: env.FLAGS })
);

Flagship is now out there in closed beta.

Many Cloudflare builders have resorted to the pragmatic workaround: hardcoding flag logic immediately into their Staff. And truthfully, it really works properly sufficient to start with. Staff deploy in seconds, so flipping a boolean in code and pushing it to manufacturing is quick sufficient for many conditions.

But it surely would not keep easy. One hardcoded flag turns into ten. Ten turns into fifty, owned by totally different groups, with no central view of what is on or off. There isn’t any audit path — when one thing breaks, you are looking out git blame to determine who toggled what.

One other frequent sample used on employees is to make an HTTP request to an exterior service within the following method:

const response = await fetch(" {
      ...
      physique: JSON.stringify({
        flagKey: "new-checkout-flow",
        context: {
          ...
        },
      }),
    });
const { worth } = await response.json();
if (worth === true) {
    return handleNewCheckout(request);
}
return handleLegacyCheckout(request);

That outbound request sits on the crucial path of each single consumer request. It might add appreciable latency relying on how far the consumer is from the flag service’s area.

This can be a unusual scenario. Your utility runs on the edge, milliseconds from the consumer. However the characteristic flag test forces it to succeed in again throughout the Web to a different API earlier than it may well resolve what to render.

Some characteristic flag companies provide a “local evaluation” SDK. As a substitute of calling a distant API on each request, the SDK downloads the total set of flag guidelines into reminiscence and evaluates them regionally. No outbound request per analysis and the flag determination occurs in-process.

On Staff, none of those assumptions maintain. There isn’t any long-lived course of: a Employee isolate could be created, serve a request, and be evicted between one request and the following. A brand new invocation might imply re-initializing the SDK from scratch.

On a serverless platform, you want a distribution primitive that is already on the edge, one the place the caching is managed for you, reads are native, and you do not want a persistent connection to maintain issues updated.

Cloudflare KV is a good primitive for this!

Flagship is constructed totally on Cloudflare’s infrastructure — Staff, Sturdy Objects, and KV. There aren’t any exterior databases, no third-party companies, and no centralized origin servers within the analysis path.

While you create or replace a flag, the management aircraft writes the change atomically to a Sturdy Object — a SQLite-backed, globally distinctive occasion that serves because the supply of reality for that app’s flag configuration and changelog. Inside seconds, the up to date flag config is synced to Staff KV, Cloudflare’s globally distributed key-value retailer, the place it is replicated throughout Cloudflare’s community.

When a request evaluates a flag, Flagship reads the flag config immediately from KV on the edge — the identical Cloudflare location already dealing with the request. The analysis engine then runs proper there in an isolate: it matches the request context towards the flag’s concentrating on guidelines, resolves the rollout proportion, and returns a variation. Each the info and the logic dwell on the edge — nothing is distributed elsewhere to be evaluated.

For groups working Cloudflare Staff, Flagship provides a direct binding that evaluates flags contained in the Staff runtime — no HTTP round-trip, no SDK overhead. Add the binding to your wrangler.jsonc and your Employee is related:

{
  "flagship": [
    {
      "binding": "FLAGS",
      "app_id": ""
    }
  ]
}

That is it. Your account ID is inferred out of your Cloudflare account, and the app_id ties the binding to a selected Flagship app. In your Employee, you simply ask for a flag worth:

export default {
  async fetch(request: Request, env: Env) {
    // Easy boolean test
    const showNewUI = await env.FLAGS.getBooleanValue('new-ui', false, {
      userId: 'user-42',
      plan: 'enterprise',
    });
    // Full analysis particulars whenever you want them
    const particulars = await env.FLAGS.getStringDetails('checkout-flow', 'v1', {
      userId: 'user-42',
    });
    // particulars.worth = "v2", particulars.variant = "new", particulars.motive = "TARGETING_MATCH"
  },
};

The binding helps typed accessors for each variation sort – getBooleanValue(), getStringValue(), getNumberValue(), getObjectValue() – plus *Particulars() variants that return the resolved worth alongside the matched variant and the rationale it was chosen. On analysis errors, the default worth is returned gracefully. On sort mismatches, the binding throws an exception — that is a bug in your code, not a transient failure.

Most characteristic flag SDKs include their very own interfaces and analysis patterns. Over time, these grow to be deeply embedded in your codebase — and switching suppliers means rewriting each name web site.

We did not wish to construct one other a kind of. Flagship is constructed on OpenFeature, the CNCF open customary for characteristic flag analysis. OpenFeature defines a standard interface for flag analysis throughout languages and suppliers — it is the identical relationship that OpenTelemetry has to observability. You write your analysis code as soon as towards the usual, and swap suppliers by altering 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 shopper = OpenFeature.getClient();
const showNewCheckout = await shopper.getBooleanValue(
  'new-checkout-flow',
  false,
  {
    targetingKey: 'user-42',
    plan: 'enterprise',
    nation: 'US',
  }
);

When you’re working on Staff with the Flagship binding, you may move it on to the OpenFeature supplier. The binding already carries your account context, so there’s nothing to configure — 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 shopper = OpenFeature.getClient();
    const showNewCheckout = await shopper.getBooleanValue('new-checkout-flow', false, {
      targetingKey: 'user-42',
      plan: 'enterprise',
    });
  },
};

Your analysis code would not change — the OpenFeature interface is equivalent. However below the hood, Flagship evaluates flags via the binding as a substitute of over HTTP. You get the portability of the usual with the efficiency of the binding.

A client-side supplier can also be out there for browsers. It pre-fetches the flags you specify, caches them with a configurable TTL, and serves evaluations synchronously from that cache.

Flagship helps the patterns you’d count on from a characteristic flag service and those that grow to be crucial when AI-generated code is touchdown in manufacturing day by day.

Flag values could be boolean, strings, numbers, or full JSON objects — helpful for configuration blocks, UI theme definitions, or routing customers to totally different API variations with out sustaining separate code paths.

Every flag can have a number of guidelines, evaluated in precedence order. The primary rule that matches wins.

A rule consists of:

• Situations that decide whether or not the rule applies to a given context

• A flag variation to serve when the rule matches

• An non-obligatory rollout for percentage-based supply

• A precedence that determines analysis order when a number of guidelines are current (decrease quantity = greater precedence)

Situations could be composed utilizing AND/OR logic, nested as much as 5 ranges deep. A single rule can categorical issues like:

(plan == “enterprise” AND area == “us” ) OR (consumer.e-mail.endsWith(“@cloudflare.com”))
= serve (“premium”)

On the high stage of a rule, a number of situations are mixed with implicit AND the place all situations should move for the rule to match. Inside every situation, you may nest AND/OR teams for extra complicated logic.

Not like gradual deployments, which cut up site visitors between totally different uploaded variations of your Employee, characteristic flags allow you to roll out habits by proportion inside a single model that’s serving 100% of site visitors.

Any rule can embody a proportion rollout. As a substitute of serving a variation to everybody who matches the situations, you serve it to a proportion of them.

Rollouts use constant hashing on the desired context attribute. The identical attribute worth (userId, for instance) all the time hashes to the identical bucket, so they will not flip between variations throughout requests. You’ll be able to ramp from 5% to 10% to 50% to 100% of customers, so those that had been already within the rollout keep in it.

AI-generated code getting into manufacturing is simply going to speed up. Agentic workflows will push it additional — brokers that autonomously deploy, check, and iterate on code in manufacturing. The groups that thrive on this world will not be those delivery the quickest. They’re going to be those who can ship quick and nonetheless preserve management over what their customers see, roll again in seconds when one thing breaks, and steadily expose new code paths with confidence.

That is what Flagship is constructed for:

• Analysis throughout area Earth, cached globally utilizing Okay/V.

• A full audit path. Each flag change is recorded with field-level diffs, so you recognize who modified what and when.

• Dashboard integration. Anybody on the workforce can toggle a flag or alter a rollout with out touching code.

• OpenFeature compatibility. Undertake Flagship with out rewriting your analysis code. Go away with out rewriting it both.

Beginning at present, Flagship is in personal beta. You’ll be able to request for entry right here. We’ll share extra particulars on pricing as we method common availability.

• Go to the Cloudflare dashboard to create your first Flagship app

• Set up the SDK: npm i @cloudflare/flagship; or use the Employee binding immediately in your Employee

• Learn the documentation for integration guides and API reference

• Try the supply code for examples and to contribute

When you’re at present hardcoding flags in your Staff, or evaluating flags via an exterior service that provides latency to each request, give Flagship a strive. We might love to listen to what you construct.