Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- wrangler dev, the Cloudflare Vite plugin, the Vitest integration, and cf dev use a local flag store by default; an empty store returns the default passed at the call site.
- Remote flags are not copied automatically. When needed, run npx wrangler flagship flags pull <APP_ID> explicitly.
- Setting remote: true on a binding makes local evaluations use the remote app. That is different from copying remote flags into the local store.
- cf has its own default local data directory. Use --persist-to to point it at the directory used by your dev server; cf cannot pull remote flags.
- Local stores require Wrangler 4.135.0 or later, or Cloudflare Vite plugin 1.56.0 or later. Local Explorer support needs later versions.
Why does a local evaluation return only the default?
In its November 2, 2026 update, Cloudflare says Flagship bindings use a local flag store by default during development with wrangler dev, the Cloudflare Vite plugin, the Vitest integration, and cf dev. A flag controls a feature or behavior; the local flag store holds those flags for development.
A new local store starts empty. Until a flag is written there, its evaluation returns the code default passed to the method. This does not mean the remote app lacks that flag or that its remote value was changed.
Local evaluation does not read flags from the remote app automatically. This lets you develop without silently replacing local edits, and it avoids a remote fetch just to start the dev server when local data is already available.
Pull remote flags into the local store when needed
If local development needs flags already defined in a remote app, first confirm the app ID and the directory used by your dev server, then run Wrangler's pull command explicitly: npx wrangler flagship flags pull <APP_ID>. Replace the placeholder with the intended app ID.
Pull copies remote flags into the default local directory, .wrangler/state. It does not run automatically; wrangler dev does not pull on each start or overwrite flags you changed locally.
If the dev server uses another directory, pass the same --persist-to <DIRECTORY> path to pull. For example, Cloudflare Vite plugin 2.0 beta uses .cloudflare/state; check the directory for your installed version and point both operations to the same location.
Pull copies remote flags into local development state; it does not deploy local changes to the remote app.
Local flags and remote evaluation are different choices
To evaluate Flagship against the remote app during local development, set remote: true on the binding. This changes the binding's evaluation target; it does not populate the local store with remote flags.
Also distinguish binding evaluation from CLI management: Flagship flag-management commands target the remote app by default. Add --local to manage the local store; a command cannot use --local and --remote together.
For repeatable local development data, use the local store and pull explicitly when needed. If you intend to evaluate remotely, set the binding clearly. Do not infer the dev server's evaluation mode from the CLI's default target.
Make cf and the dev server use the same directory
cf dev also uses a local Flagship store, but cf keeps local data in its own directory by default. Wrangler dev and the Cloudflare Vite plugin do not read that separate directory, so the tools can appear to have different flags.
Cloudflare's documented local-list example is cf flagship apps flags list --app-id <APP_ID> --local --persist-to .wrangler/state. That .wrangler/state path matches the default for wrangler dev and Vite plugin 1.x.
Cloudflare Vite plugin 2.0 beta uses .cloudflare/state by default. Check the directory your dev server actually uses, then configure cf and Wrangler operations to share that path; do not assume the tools share their defaults.
cf cannot copy flags from a remote app. To seed the local store, use npx wrangler flagship flags pull <APP_ID> and pass the same --persist-to value when you have configured a custom directory.
Check versions and data paths in order
Local-store support requires Wrangler v4.135.0 or later, or @cloudflare/vite-plugin v1.56.0 or later. Flagship support in Local Explorer requires Wrangler v4.148.0 or later, or plugin v1.63.0 or later.
For troubleshooting, check in order: whether the binding has remote: true; whether you explicitly pulled the intended app's flags; whether pull and the dev server use the same data directory; and whether cf has a --persist-to path pointing to that directory.
Local flags represent local development state, not production state. Offline use only means there is no automatic remote flag pull; it does not mean every application dependency works offline. Local edits or pulls do not deploy to or change the remote app.
Sources
Frequently Asked Questions
Does pull delete flags that exist only in the local store?
No. The current configuration documentation says local-only flags are left untouched. That does not mean all local values match the remote app; still check the intended flags and data directory.
Does every cf Flagship command support --local?
No. Only the listed commands have local support. For example, cf flagship apps get, cf flagship apps definitions get, and cf flagship apps flags changelog have no local equivalent and return This command has no local equivalent. Check command support first; removing --local targets the remote app.