Under the hood Bindings

How Devflare wires Browser Rendering from config to runtime

Browser Rendering support in Devflare is more than a config pass-through: the dev server starts a browser shim and a binding worker that line up with Cloudflare and puppeteer expectations.

That implementation detail is why the binding belongs in the docs library even though the test helper surface is narrower. There is real, deliberate runtime support here.

Normalization: The env binding name is the important authoring value, while the configured string is mainly used for naming and preview materialization
Compile target: Wrangler binding
Preview note: Preview can materialize the binding name, but browser resources are not lifecycle-managed account resources

Devflare normalizes the authored shape before it does anything louder

The browser binding schema accepts a record but then validates that only one key exists. Devflare treats that key as the meaningful env binding name and compiles it into the single entry Wrangler expects.

That is why the docs should emphasize the env key and the single-binding limit instead of implying the string value behaves like a normal bucket or namespace resource.

Browser Rendering from authored config to generated output

Keep the binding readable in source, then inspect only the Wrangler-facing slice Devflare emits when the config is compiled.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'browser-worker',

bindings: {

browser: {

BROWSER: 'browser-resource'

}

})

Local runtime support depends on what Devflare can model directly

The dev server starts a browser shim that can install Chrome Headless Shell and proxy the Browser Rendering protocol over HTTP and WebSocket.
The binding worker exists so browser libraries like can talk to the expected Worker-side contract.
Generated env typing stays conservative here too: the binding currently lands as , which is another reason to keep the worker-facing browser path narrow and explicit.
This is why browser local support feels more like dev-server infrastructure than like a small helper.

Compile, preview, and cleanup behavior

Compile emits the single browser binding from the configured env key.
Preview logic can materialize names, but Devflare does not provision or delete browser “resources” because they are not account-managed the same way storage bindings are.
The browser path can also warn about missing local WebSocket support when the environment lacks the dependency needed for proxying.

The honest browser story

Browser support is real, but it is infrastructural. Expect a stronger dev-server story than a tiny one-function local helper story.

Browser Rendering

Devflare supports Browser Rendering, but the docs should say the quiet part out loud: there is exactly one browser binding today, and the best-supported local story lives in dev-server and integration flows.

Testing Browser Rendering

Browser tests should usually be integration-flavored: either drive the worker in dev or exercise a thin smoke path that proves the binding can launch and fetch.