Cloudflare Flagship now supports evaluating feature flags against a local store when you run development tools such as wrangler dev, the Vite plugin, Vitest integration, or cf dev. The store starts empty, so any flag lookup falls back to the default value supplied in code unless you populate it locally.
What Changed
All supported local development commands can be instructed to operate on a local flag database by adding the --local flag to the respective flagship sub‑commands. You can also push the current remote flag set into the local store with npx wrangler flagship flags pull <APP_ID>. The Local Explorer UI now mirrors this capability, allowing you to create, edit, toggle, and evaluate flags while the dev server runs.
Why It Matters to Practitioners
- AI and cloud engineers: Feature‑flag driven model toggles can be exercised in isolation, enabling rapid iteration on inference pipelines without risking production traffic.
- DevOps / SRE: Offline flag evaluation reduces external dependencies during CI pipelines, leading to more deterministic test runs and faster feedback loops.
- Security engineers: Testing flag changes locally prevents accidental exposure of experimental controls to live users, limiting attack surface during development.
Operational and Security Considerations
- The local store is empty by default; any missing flag returns the code‑provided default, which may differ from the remote configuration. Verify that defaults align with intended behavior before promoting changes.
- To continue using the remote flag service, set
remote: trueon the binding configuration. - Local flag support requires Wrangler v4.135.0 or
@cloudflare/vite-pluginv1.56.0+. The Local Explorer UI adds a higher requirement: Wrangler v4.148.0 or@cloudflare/vite-pluginv1.63.0+. - Because flag state is stored locally, it is not shared across developer machines. Teams should coordinate pulls or manual syncs to keep local flag sets consistent.
Next Steps and Evaluation
- Confirm your toolchain meets the minimum version thresholds before enabling
--localworkflows. - In CI, add a step that pulls the current remote flag set into the local store to ensure tests run against the latest production configuration.
- Monitor the Flagship documentation for any changes to the local‑development API or version requirements.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopting the local flag store lets you decouple feature‑flag testing from network availability and production state, improving development speed and reducing accidental exposure. Ensure your tooling is up‑to‑date, align default values with production expectations, and incorporate a pull step in automated pipelines to keep local flag data current.