[Flagship] Document the local flag store for wrangler dev

src/content/changelog/flagship/2026-08-28-local-flag-store.mdx

@@ -0,0 +1,29 @@
+---
+title: Evaluate Flagship flags locally in wrangler dev
+description: Flagship bindings now use a local flag store during wrangler dev, so local development works offline and does not change production flags.
+products:
+  - flagship
+date: 2026-08-28
+---
+
+**[Wrangler](/workers/wrangler/)** now evaluates [Flagship](/flagship/) bindings against a local flag store during [`wrangler dev`](/workers/wrangler/commands/general/#dev). The store starts empty, so flags fall back to the default you pass at the call site until you populate it.
+
+Copy flags from your remote app:
+
+```sh
+npx wrangler flagship flags pull <APP_ID>
+```
+
+`create`, `get`, `list`, `update`, `delete`, `enable`, `disable`, `set`, `rollout`, `split`, `evaluate`, and the `rules` commands accept `--local` to read and write that store. They still default to the remote app.
+
+To keep using the remote app during local development, set `remote: true` on the binding:
+
+```jsonc
+{
+	"flagship": [{ "binding": "FLAGS", "app_id": "my-app", "remote": true }],
+}
+```
+
+When [Local Explorer](/workers/local-development/local-explorer/) is open, bound Flagship apps appear in the sidebar. You can list, create, edit, toggle, and evaluate flags against the same local store.
+
+Refer to [Flagship local development](/flagship/configuration/#local-development) for details.

src/content/docs/flagship/configuration.mdx

@@ -93,4 +93,41 @@ Refer to the [binding API reference](/flagship/binding/) for the full list of me
 
 ## Local development
 
-Flagship bindings work with `wrangler dev`. Local Workers use the live Flagship app configured by `app_id`. There is no local flag store. Make sure your local Wrangler configuration points to a valid Flagship app before testing evaluations.
+During [`wrangler dev`](/workers/wrangler/commands/general/#dev), Flagship bindings use a local flag store by default. The store starts empty, so evaluations return the default value you pass at the call site until you add flags.
+
+To copy flags from your remote app into the local store:
+
+```sh
+npx wrangler flagship flags pull <APP_ID>
+```
+
+`pull` also seeds the account tag used for [percentage rollout](/flagship/targeting/percentage-rollouts/) bucketing, so local buckets match the remote app. Flags that exist only in the local store are left untouched.
+
+To create or change flags without affecting the remote app, pass `--local` to the flag commands:
+
+```sh
+npx wrangler flagship flags create <APP_ID> new-checkout --local
+npx wrangler flagship flags list <APP_ID> --local
+```
+
+Flag commands still default to the remote app. You cannot pass `--local` and `--remote` together.
+
+To evaluate against the remote app during local development, set `remote` to `true` on the binding:
+
+<WranglerConfig>
+
+```jsonc
+{
+	"flagship": [
+		{
+			"binding": "FLAGS",
+			"app_id": "<APP_ID>",
+			"remote": true,
+		},
+	],
+}
+```
+
+</WranglerConfig>
+
+You can also inspect and edit the local store in [Local Explorer](/workers/local-development/local-explorer/).

src/content/docs/flagship/get-started.mdx

@@ -83,6 +83,17 @@ export default {
 
 The third argument to `getBooleanValue` is the [evaluation context](/flagship/concepts/#evaluation-context). Flagship uses the context attributes to match targeting rules. In this example, the `userId` attribute is passed so that percentage rollouts and user-specific targeting work correctly.
 
+## Test locally
+
+Copy the flag into the local store, then start a local session:
+
+```sh
+npx wrangler flagship flags pull <APP_ID>
+npx wrangler dev
+```
+
+Without `pull`, the local store is empty and evaluations return the default you pass in code. Refer to [Local development](/flagship/configuration/#local-development) for `--local` flag commands and `remote: true`.
+
 ## Deploy and test
 
 Deploy your Worker:
@@ -180,6 +191,7 @@ Refer to the [SDK documentation](/flagship/sdk/) for detailed setup instructions
 ## Next steps
 
 - Manage flags from the command line with the [`wrangler flagship` commands](/flagship/reference/wrangler-commands/).
+- Test against a [local flag store](/flagship/configuration/#local-development) during `wrangler dev`.
 - Learn about [targeting rules](/flagship/targeting/) to serve different values based on user attributes.
 - Explore the full [binding API reference](/flagship/binding/) for all evaluation methods.
 - Read about [percentage rollouts](/flagship/targeting/percentage-rollouts/) for gradual feature releases.

src/content/docs/flagship/reference/wrangler-commands.mdx

@@ -16,7 +16,7 @@ Use `wrangler flagship` to manage Flagship apps and feature flags from the comma
 
 ### Authenticate Wrangler
 
-`wrangler flagship` calls the Cloudflare API. Authenticate Wrangler before running commands:
+Commands that target the remote app call the Cloudflare API. Authenticate Wrangler before running them:
 
 ```sh
 wrangler login
@@ -51,6 +51,29 @@ This binding is only used by your Worker's runtime code (`env.FLAGS`). `wrangler
 
 </Aside>
 
+## Local flag store
+
+[`wrangler dev`](/workers/wrangler/commands/general/#dev) evaluates Flagship bindings against a local flag store. The store starts empty.
+
+Copy flags from the remote app into that store:
+
+```sh
+wrangler flagship flags pull <APP_ID>
+```
+
+`pull` requires authentication because it reads the remote app. Matching keys are overwritten. Flags that exist only locally are reported, not deleted.
+
+`create`, `get`, `list`, `update`, `delete`, `enable`, `disable`, `set`, `rollout`, `split`, `evaluate`, and the `rules` commands accept `--local` to read and write the local store. They still default to the remote app.
+
+```sh
+wrangler flagship flags list <APP_ID> --local
+wrangler flagship flags create <APP_ID> new-checkout --local
+```
+
+You cannot pass `--local` and `--remote` together. `--persist-to` requires `--local`.
+
+For binding configuration, including `remote: true`, refer to [Local development](/flagship/configuration/#local-development).
+
 ## Quick start
 
 Create a boolean flag, evaluate it for a user, and disable it as a kill switch:

src/content/docs/workers/local-development/local-data.mdx

@@ -79,6 +79,24 @@ You may also include [other metadata](/workers/wrangler/commands/r2/#r2-object-p
 	args="d1 execute <DATABASE_NAME> --file=./schema.sql --local"
 />
 
+### Flagship apps
+
+#### [Copy flags from a remote app](/flagship/configuration/#local-development)
+
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="flagship flags pull <APP_ID>"
+/>
+
+#### [Create a flag in the local store](/flagship/reference/wrangler-commands/#local-flag-store)
+
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="flagship flags create <APP_ID> new-checkout --local"
+/>
+
 ### Durable Objects
 
 For Durable Objects, unlike KV, D1, and R2, there are no CLI commands to populate them with local data. To add data to Durable Objects during local development, you must write application code that creates Durable Object instances and [calls methods on them that store state](/durable-objects/best-practices/access-durable-objects-storage/). This typically involves creating development endpoints or test routes that initialize your Durable Objects with the desired data.

src/content/docs/workers/local-development/local-explorer.mdx

@@ -46,6 +46,7 @@ Local Explorer supports the following binding types:
 | [D1](/d1/)                                            | Browse tables and rows, run SQL queries        | Insert, update, and delete rows through SQL |
 | [Durable Objects](/durable-objects/) (SQLite storage) | Browse SQLite tables and rows, run SQL queries | Insert, update, and delete rows through SQL |
 | [Workflows](/workflows/)                              | List instances, view status and step history   | Trigger new runs, retry failed instances    |
+| [Flagship](/flagship/)                                | List flags, view variants and targeting rules  | Create, edit, toggle, delete, and evaluate flags |
 
 ### D1 and Durable Objects SQL Studio
 

src/content/docs/workers/wrangler/commands/flagship.mdx

@@ -12,6 +12,14 @@ Use `wrangler flagship` to manage [Flagship](/flagship/) apps and feature flags
 
 `wrangler flagship` is available in Wrangler v4.107.0 and later.
 
+:::note[`--local` option]
+Most `wrangler flagship flags` commands accept `--local` to read and write the local flag store used by [`wrangler dev`](/workers/wrangler/commands/general/#dev). They still default to the remote app.
+
+`wrangler flagship flags pull <APP_ID>` copies remote flags into that store.
+
+For more information, refer to [Flagship local development](/flagship/configuration/#local-development).
+:::
+
 ## Authentication
 
 Run `wrangler login`, or set [`CLOUDFLARE_API_TOKEN`](/workers/wrangler/system-environment-variables/) to an API token with Flagship permissions.

src/content/docs/workers/wrangler/configuration.mdx

@@ -259,6 +259,9 @@ Non-inheritable keys are configurable at the top-level, but cannot be inherited
 - `secrets_store_secrets` <Type text="object" /> <MetaInfo text="optional" />
   - A list of Secrets Store bindings that your worker should be bound to. Refer to [Secrets Store](/secrets-store/).
 
+- `flagship` <Type text="object" /> <MetaInfo text="optional" />
+  - A list of Flagship apps that your Worker should be bound to. Refer to [Flagship](#flagship).
+
 ## Types of routes
 
 There are three types of [routes](/workers/configuration/routing/): [Custom Domains](/workers/configuration/routing/custom-domains/), [routes](/workers/configuration/routing/routes/), and [`workers.dev`](/workers/configuration/routing/workers-dev/).
@@ -749,6 +752,36 @@ Example:
 
 <Render file="envvar-example" product="workers" />
 
+### Flagship
+
+[Flagship](/flagship/) is Cloudflare's feature flag service. Bind a Flagship app to evaluate flags from your Worker.
+
+- `binding` <Type text="string" /> <MetaInfo text="required" />
+  - The binding name used to refer to the Flagship app. The binding must be [a valid JavaScript variable name](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#variables).
+
+- `app_id` <Type text="string" /> <MetaInfo text="optional" />
+  - The ID of the Flagship app.
+
+- `remote` <Type text="boolean" /> <MetaInfo text="optional" />
+  - During local development, Flagship bindings use a [local flag store](/flagship/configuration/#local-development) by default. Set `remote` to `true` to evaluate against the remote app instead.
+
+Example:
+
+<WranglerConfig>
+
+```jsonc
+{
+	"flagship": [
+		{
+			"binding": "FLAGS",
+			"app_id": "<APP_ID>",
+		},
+	],
+}
+```
+
+</WranglerConfig>
+
 ### Hyperdrive
 
 [Hyperdrive](/hyperdrive/) bindings allow you to interact with and query any Postgres database from within a Worker.

src/content/partials/workers/bindings_per_env.mdx

@@ -18,6 +18,7 @@
 | **Durable Objects**                     |        ✅         |          ❌ [^1]           |
 | **Containers**                          |        ✅         |             ❌             |
 | **Email Bindings**                      |        ✅         |             ✅             |
+| **Flagship**                            |        ✅         |             ✅             |
 | **Hyperdrive**                          |        ✅         |             ❌             |
 | **Images**                              |        ✅         |             ✅             |
 | **KV**                                  |        ✅         |             ✅             |
@@ -48,6 +49,7 @@ Supported only in [`wrangler dev --remote`](/workers/wrangler/commands/general/#
 | **Durable Objects**                     |         ✅         |
 | **Containers**                          |         ❌         |
 | **Email Bindings**                      |         ✅         |
+| **Flagship**                            |         ✅         |
 | **Hyperdrive**                          |         ✅         |
 | **Images**                              |         ✅         |
 | **KV**                                  |         ✅         |