Directly recommend setting remote: true when mentioning remote bindings

src/content/docs/browser-rendering/faq.mdx

@@ -25,7 +25,7 @@ If you cannot find the answer you are looking for, join us on [Discord](https://
 Not yet. Local development currently has the following limitation(s):
 - Requests larger than 1 MB are not supported.
 
-For full feature access, set the browser rendering as a [remote binding](/workers/development-testing/#remote-bindings).
+<Render file="remote-binding-note" product="workers" />
 
 ### Will Browser Rendering bypass Cloudflare's Bot Protection?
 

src/content/docs/browser-rendering/how-to/ai.mdx

@@ -259,7 +259,7 @@ async function getLLMResult(env, prompt: string, schema?: any) {
 }
 ```
 
-You can run this script to test it using [remote bindings](/workers/development-testing/#remote-bindings):
+You can run this script to test it via:
 
 ```sh
 npx wrangler dev

src/content/docs/browser-rendering/how-to/pdf-generation.mdx

@@ -5,14 +5,14 @@ sidebar:
   order: 1
 ---
 
-import { Aside, WranglerConfig, PackageManagers } from "~/components";
+import { Aside, WranglerConfig, PackageManagers, Render } from "~/components";
 
 As seen in [this Workers bindings guide](/browser-rendering/workers-bindings/screenshots/), Browser Rendering can be used to generate screenshots for any given URL. Alongside screenshots, you can also generate full PDF documents for a given webpage, and can also provide the webpage markup and style ourselves.
 
 You can generate PDFs with Browser Rendering in two ways:
 
-- **[REST API](/browser-rendering/rest-api/)**: Use the the [/pdf endpoint](/browser-rendering/rest-api/pdf-endpoint/). This is ideal if you don't need to customize rendering behavior. 
-- **[Workers Bindings](/browser-rendering/workers-bindings/)**: Use [Puppeteer](/browser-rendering/platform/puppeteer/) or [Playwright](/browser-rendering/platform/playwright/) with Workers Bindings for additional control and customization. 
+- **[REST API](/browser-rendering/rest-api/)**: Use the the [/pdf endpoint](/browser-rendering/rest-api/pdf-endpoint/). This is ideal if you don't need to customize rendering behavior.
+- **[Workers Bindings](/browser-rendering/workers-bindings/)**: Use [Puppeteer](/browser-rendering/platform/puppeteer/) or [Playwright](/browser-rendering/platform/playwright/) with Workers Bindings for additional control and customization.
 
 Choose the method that best fits your use case.
 
@@ -38,6 +38,8 @@ browser = { binding = "BROWSER" }
 
 </WranglerConfig>
 
+<Render file="remote-binding-note" product="workers" />
+
 4. Replace the contents of `src/index.ts` (or `src/index.js` for JavaScript projects) with the following skeleton script:
 
 ```ts
@@ -257,7 +259,7 @@ export default {
 };
 ```
 
-You can run this script to test it using [remote bindings](/workers/development-testing/#remote-bindings):
+You can run this script to test it via:
 
 <PackageManagers type="exec" pkg="wrangler" args="dev" />
 

src/content/docs/browser-rendering/platform/wrangler.mdx

@@ -44,4 +44,6 @@ After the binding is declared, access the DevTools endpoint using `env.MYBROWSER
 const browser = await puppeteer.launch(env.MYBROWSER);
 ```
 
-Run `npx wrangler dev` to test your Worker locally. You can also set the browser binding as a [remote binding](/workers/development-testing/#remote-bindings) to test against a remote browser.
+Run `npx wrangler dev` to test your Worker locally.
+
+<Render file="remote-binding-note" product="workers" />

src/content/docs/browser-rendering/workers-bindings/browser-rendering-with-DO.mdx

@@ -210,7 +210,9 @@ export class Browser {
 
 ## 6. Test
 
-Run `npx wrangler dev` to test your Worker locally. You can also set the browser binding as a [remote binding](/workers/development-testing/#remote-bindings) to test against a remote browser.
+Run `npx wrangler dev` to test your Worker locally.
+
+<Render file="remote-binding-note" product="workers" />
 
 ## 7. Deploy
 

src/content/docs/browser-rendering/workers-bindings/reuse-sessions.mdx

@@ -144,7 +144,9 @@ Besides `puppeteer.sessions()`, we have added other methods to facilitate [Sessi
 
 ## 5. Test
 
-Run `npx wrangler dev` to test your Worker locally. You can also set the browser binding as a [remote binding](/workers/development-testing/#remote-bindings) to test against a remote browser.
+Run `npx wrangler dev` to test your Worker locally.
+
+<Render file="remote-binding-note" product="workers" />
 
 To test go to the following URL:
 

src/content/docs/d1/best-practices/local-development.mdx

@@ -5,7 +5,7 @@ sidebar:
   order: 8
 ---
 
-import { WranglerConfig } from "~/components";
+import { WranglerConfig, Render } from "~/components";
 
 D1 has fully-featured support for local development, running the same version of D1 as Cloudflare runs globally. Local development uses [Wrangler](/workers/wrangler/install-and-update/), the command-line interface for Workers, to manage local development sessions and state.
 
@@ -67,7 +67,7 @@ database_id = "c020574a-5623-407b-be0c-cd192bab9545"
 
 </WranglerConfig>
 
-Note that `wrangler dev` separates local and production (remote) data. A local session does not have access to your production data by default. To access your production (remote) database, set your D1 as a [remote binding](/workers/development-testing/#remote-bindings). Any changes you make when running against a remote database cannot be undone.
+Note that `wrangler dev` separates local and production (remote) data. A local session does not have access to your production data by default. To access your production (remote) database, set `"remote" : true` in the D1 binding configuration. Refer to the [remote bindings documentation](/workers/development-testing/#remote-bindings) for more information. Any changes you make when running against a remote database cannot be undone.
 
 Refer to the [`wrangler dev` documentation](/workers/wrangler/commands/#dev) to learn more about how to configure a local development session.
 

src/content/docs/d1/tutorials/build-an-api-to-access-d1/index.mdx

@@ -280,7 +280,7 @@ Upon successful execution, a new table will be added to your database.
 
 :::note
 
-The table will be created in the local instance of the database. If you want to add this table to your production database, set your database as a [remote binding](/workers/development-testing/#remote-bindings).
+The table will be created in the local instance of the database. If you want to add this table to your production database set `"remote" : true` in the D1 binding configuration. Refer to the [remote bindings documentation](/workers/development-testing/#remote-bindings) for more information.
 
 :::
 

src/content/docs/d1/tutorials/using-read-replication-for-e-com/index.mdx

@@ -857,7 +857,9 @@ curl -X POST http://localhost:8787/api/product \
 
 :::note
 
-Read replication is only used when the application has been [deployed](/d1/tutorials/using-read-replication-for-e-com/#step-9-deploy-the-application). D1 does not create read replicas when you develop locally. To test it locally, you can set your database as a [remote binding](/workers/development-testing/#remote-bindings).
+Read replication is only used when the application has been [deployed](/d1/tutorials/using-read-replication-for-e-com/#step-9-deploy-the-application). D1 does not create read replicas when you develop locally.
+
+To test it locally, you can set `"remote" : true` in the D1 binding configuration. Refer to the [remote bindings documentation](/workers/development-testing/#remote-bindings) for more information.
 
 :::
 

src/content/docs/kv/concepts/kv-bindings.mdx

@@ -60,7 +60,7 @@ export default {
 
 When you use Wrangler to develop locally with the `wrangler dev` command, Wrangler will default to using a local version of KV to avoid interfering with any of your live production data in KV. This means that reading keys that you have not written locally will return `null`.
 
-To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, set your KV as a [remote binding](/workers/development-testing/#remote-bindings).
+To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, set `"remote" : true` in the KV binding configuration. Refer to the [remote bindings documentation](/workers/development-testing/#remote-bindings) for more information.
 
 <WranglerConfig>
 

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

@@ -336,7 +336,9 @@ You can view key-value pairs directly from the dashboard.
 
 When using [`wrangler dev`](/workers/wrangler/commands/#dev) to develop locally, Wrangler defaults to using a local version of KV to avoid interfering with any of your live production data in KV. This means that reading keys that you have not written locally returns null.
 
-To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, you can set the KV as a [remote binding](/workers/development-testing/#remote-bindings) instead. This uses the `preview_id` of the KV binding configuration in the Wrangler file. Refer to the [KV binding docs](/kv/concepts/kv-bindings/#use-kv-bindings-when-developing-locally) for more information.
+To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, you can set `"remote" : true` in the KV binding configuration. Refer to the [remote bindings documentation](/workers/development-testing/#remote-bindings) for more information.
+
+Also refer to [KV binding docs](/kv/concepts/kv-bindings/#use-kv-bindings-when-developing-locally).
 
 :::
 

src/content/docs/r2/api/workers/workers-api-usage.mdx

@@ -83,7 +83,8 @@ Within your Worker code, your bucket is now available under the `MY_BUCKET` vari
 :::caution[Local Development mode in Wrangler]
 
 By default `wrangler dev` runs in local development mode. In this mode, all operations performed by your local worker will operate against local storage on your machine.
-You can set an R2 as a [remote binding](/workers/development-testing/#remote-bindings) if you want R2 operations made during development to be performed against a real R2 bucket.
+
+If you want the R2 operations that are performed during development to be performed against a real R2 bucket, you can set `"remote" : true` in the R2 binding configuration. Refer to [remote bindings documentation](/workers/development-testing/#remote-bindings) for more information.
 
 :::
 

src/content/partials/browser-rendering/example-workers-binding-screenshots-from-web.mdx

@@ -154,7 +154,9 @@ If the same `url` is requested again, it will use the cached version in KV inste
 
 #### 6. Test
 
-Run `npx wrangler dev` to test your Worker locally or run [`npx wrangler dev --remote`](/workers/wrangler/commands/#dev) to test your Worker remotely before deploying to Cloudflare's global network.
+Run `npx wrangler dev` to test your Worker locally.
+
+<Render file="remote-binding-note" product="workers" />
 
 To test taking your first screenshot, go to the following URL:
 

src/content/partials/workers/remote-binding-note.mdx

@@ -0,0 +1,9 @@
+---
+{}
+---
+
+:::note[Use real headless browser during local development]
+
+To interact with a real headless browser during local development, set `"remote" : true` in the Browser binding configuration. Learn more in our [remote bindings documentation](/workers/development-testing/#remote-bindings).
+
+:::

src/content/partials/workers/wrangler-commands/d1.mdx

@@ -80,7 +80,7 @@ You must provide either `--command` or `--file` for this command to run successf
 - `--local` <Type text="boolean" /> <MetaInfo text="(default: true) optional" />
   - Execute commands/files against a local database for use with [wrangler dev](/workers/wrangler/commands/#dev).
 - `--remote` <Type text="boolean" /> <MetaInfo text="(default: false) optional" />
-  - Execute commands/files against a remote D1 database for use with [remote binding](/workers/development-testing/#remote-bindings) or your deployed Worker.
+  - Execute commands/files against a remote D1 database for use with [remote bindings](/workers/development-testing/#remote-bindings) or your deployed Worker.
 - `--persist-to` <Type text="string" /> <MetaInfo text="optional" />
   - Specify directory to use for local persistence (for use in combination with `--local`).
 - `--json` <Type text="boolean" /> <MetaInfo text="optional" />