# Cloudflare Flagship adds a local flag store for offline development

Cloudflare's changelog says Flagship bindings can now evaluate flags against a local store during local development instead of calling the remote app, with a pull command to copy existing flags and a remote: true option to keep the old behaviour.

Canonical URL: https://freelancenews.online/news/cloudflare-flagship-adds-a-local-flag-store-for-offline-development-ca87f537
Published: 2026-11-02T12:17:56.768Z
Updated: 2026-11-02T12:17:56.768Z
Source published: 2026-11-02T00:00:00.000Z
Event date: 2026-11-02
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

Cloudflare has published a changelog entry describing a change to how its Flagship feature-flag bindings behave during local development. Per the entry, bindings now evaluate flags against a local flag store rather than calling the remote app. The stated purpose is to let developers work offline and test flag changes without affecting production.

The changelog names the environments covered: wrangler dev, the Cloudflare Vite plugin, the test integration, and cf dev. The same local-store behaviour is described as applying across those tools rather than to a single command, so the change is not confined to one entry point.

The starting state is explicit. The local store begins empty, so evaluations return the default value passed in code until flags are added. That detail is the most consequential part of the entry for anyone whose local runs previously depended on live remote flag values.

Cloudflare lists three ways to populate the store. For Wrangler, developers add --local to flagship flags commands such as create, update and evaluate. A pull path is also documented: running npx wrangler flagship flags pull <APP_ID> copies all flags from the remote app into the local store.

Local Explorer provides a second route. According to the changelog, flags can be created, edited, toggled and evaluated there while the dev server runs. The entry does not describe the interface beyond those verbs, so the exact workflow is left to the linked documentation.

The cf CLI follows the Wrangler pattern: the changelog says to add --local to cf flagship commands. For anyone who wants to keep evaluating against the remote app, the entry states that setting remote: true on the binding preserves that behaviour.

Specified are the version requirements. For the local flag store, you need Wrangler v4.135.0 or later, or @cloudflare/vite-plugin v1.56.0 or later. Higher minimums apply to Flagship in Local Explorer: Wrangler v4.148.0 or later, or @cloudflare/vite-plugin v1.63.0 or later. In a given toolchain, then, the two capabilities do not necessarily arrive together.

The entry closes by pointing readers to a Flagship local development page for details. The supplied excerpt does not describe that page's contents, so configuration specifics beyond the flags and binding option named above are not established by this material.

For freelancers and developers working on Cloudflare-hosted projects, the practical consequence is a shift in default local behaviour. This is an editorial reading of the documented mechanics, not a claim from Cloudflare about migration impact: code that previously reached the remote app during local runs may now resolve to code defaults unless flags are pulled or created locally, or unless remote: true is set.

The pull command is the most direct bridge between the two modes. Because the store starts empty, a developer who wants local evaluation to resemble the remote app's current state would need to copy flags over first, and the changelog presents pull as the way to do that for all flags on an app.

The design carries tradeoffs. A local store supports offline work and isolates experiments from production, but it also creates a second place where flag state lives. The changelog does not describe how local and remote state are reconciled after local edits, so teams should treat that as an open question rather than assume synchronisation.

The version gates deserve a check before adoption. A project on an older Wrangler or Vite plugin build may not get the local store at all, and Local Explorer support requires newer builds than the store itself, so a team could have one capability without the other.

Several things remain unknown from the supplied material. The changelog does not state pricing, does not describe limits on the number of local flags, and does not explain how the test integration behaves when the store is empty beyond returning defaults. It also does not say whether local flag changes can be pushed back to the remote app.

The entry is a changelog note rather than a tutorial, and it defers detail to separate documentation. Readers should verify behaviour against that documentation and their installed versions rather than relying on this summary alone.

The broader takeaway is procedural: local flag evaluation is now a documented, configurable mode with an explicit opt-out. For teams that test flag-dependent code paths locally, choosing between a populated local store and remote: true becomes a deliberate setup decision rather than an incidental one.

## Key points

- Flagship bindings evaluate flags against a local store during local development instead of calling the remote app, per Cloudflare's changelog.
- The local store starts empty, so evaluations return the default value passed in code until flags are added.
- Flags can be added via Wrangler commands with --local, Local Explorer while the dev server runs, or the cf CLI with --local.
- Running npx wrangler flagship flags pull <APP_ID> copies all flags from the remote app to the local store.
- Setting remote: true on the binding keeps evaluation pointed at the remote app.

## Practical implications — editorial interpretation

Editorial interpretation: developers who rely on Flagship during local runs should check their Wrangler or Vite plugin version and decide whether to pull flags into the local store or set remote: true, since an empty store returns code defaults rather than remote flag values.

## Limitations and unknowns

The evidence is a single changelog entry. It does not cover pricing, local flag limits, how local and remote state are reconciled, whether local changes can be pushed back, or the contents of the linked local development documentation. No independent testing was performed.

## Sources

- [1] developers.cloudflare.com: Changelog
  https://developers.cloudflare.com/changelog/post/2026-11-02-local-flag-store/
  Retrieved: 2026-11-02T12:17:27.379Z

## Claim references

- Flagship bindings now evaluate flags against a local flag store during local development instead of calling the remote app. [source 1]
- The change applies to wrangler dev, the Cloudflare Vite plugin, the test integration and cf dev. [source 1]
- The local store starts empty, so evaluations return the default value passed in code. [source 1]
- Adding --local to wrangler flagship flags commands such as create, update and evaluate manages local flags. [source 1]
- Running npx wrangler flagship flags pull <APP_ID> copies all flags from the remote app. [source 1]
- Setting remote: true on the binding keeps evaluation against the remote app. [source 1]
- The local flag store requires Wrangler v4.135.0 or @cloudflare/vite-plugin v1.56.0 or later, while Local Explorer support requires Wrangler v4.148.0 or @cloudflare/vite-plugin v1.63.0 or later. [source 1]