Binding reference Bindings

Use Browser Rendering when the worker really needs a headless browser path

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.

That is still useful. It means browser work can live in the same docs library as every other binding, just with honest caveats about limits and testing style.

Config key: bindings.browser
Authoring shape: Record<string, string> with exactly one entry
Best for: PDF generation, screenshots, and other worker-side headless browser tasks

Author it in the simplest shape that still says what you mean

Browser Rendering looks a little unusual in config because the current contract is a named map with exactly one entry. The env key matters more than the configured string value that appears beside it.

That is also why generated env typing stays conservative today: can model the binding as , while the richer browser behavior comes from the dev server shim and browser-aware libraries.

That single-binding constraint is not a Devflare whim. It reflects the current Wrangler and platform support Devflare is choosing to expose honestly.

Browser binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'browser-worker',

bindings: {

browser: {

BROWSER: 'browser-resource'

}

})

When this binding fits best

Use Browser Rendering when the worker truly needs a browser — for PDF generation, screenshots, or browser-like page evaluation.
Keep browser usage narrow and explicit because browser work is usually heavier than normal request handling.
If a feature can be expressed as a plain fetch or HTML transform, it probably should be.

Notes worth keeping visible

Only one browser binding is currently supported.
The strongest local story lives in dev-server and integration flows, not in a rich browser-specific test helper API.
Preview naming exists, but browser resources are not provisioned or deleted like account-managed storage resources.

Exactly one really means one

If you configure more than one browser binding, schema validation rejects it because the underlying Wrangler contract only supports one.

Cloudflare docs vs the Devflare layer

Cloudflare Browser Rendering docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

Reference

Cloudflare Browser Rendering docs

Cloudflare Docs

Platform reference for browser sessions, quick actions, automation limits, and integration methods.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for browser sessions, quick actions, automation limits, and integration methods.	How to author , what the runtime surface looks like, and how Browser Rendering fits a Devflare project.
Testing and runtime lens	Cloudflare’s docs focus on the raw binding API, product semantics, and platform limits for the binding itself.	Supported, but the strongest story is dev server and integration rather than a dedicated test helper. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape.
When to open it	When you need the platform contract, limits, APIs, or account-level product details.	When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app.

Go deeper only if this one-page guide stops being enough

Subpage

Browser Rendering internals

Internals

See normalization, Wrangler binding, and the preview or runtime details behind the authored shape.

Subpage

Testing Browser Rendering

Testing

Start from A narrow browser route exercised through the dev server, a preview URL, or another integration-style path and only escalate when the binding or deployment model genuinely needs it.

Subpage

Browser Rendering example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.