Browser Rendering API moves to open beta

Cloudflare has opened up its Workers Browser Rendering API to the public beta. The service lets developers drive a headless Chromium browser programmatically from a Worker script, opening the door to automation flows such as page scraping, screenshot generation, and testing without running a browser locally.

Access is being granted in batches to customers on the wait list. Developers can sign up starting today.

Command-line support and bindings

A key update in this release is Wrangler support for the Browser Rendering API bindings. The beta Wrangler release is available via npm:

npm install wrangler --save-dev

Once the service is enabled on an account, a Worker only needs a binding defined in wrangler.toml:

browser = { binding = "MYBROWSER", type = "browser" }

The binding gives the Worker a WebSocket endpoint that speaks the Chrome DevTools Protocol. This is the same protocol Chrome uses locally when a user inspects a page, and it allows the Worker to instrument a Chromium instance running on Cloudflare's network.

A patched Puppeteer

Rather than speak DevTools directly, most developers will use Puppeteer, the popular high-level library for automating Chrome and Chromium. Cloudflare has published a fork of Puppeteer that connects to the Browser Rendering API instead of a local browser. The changes are minimal, and after connecting, the full Puppeteer API is available as usual.

The fork is open source and installable as @cloudflare/puppeteer:

import puppeteer from "@cloudflare/puppeteer";

Launching a browser from a Worker script looks like this:

const browser = await puppeteer.launch(env.MYBROWSER);

Cloudflare plans to keep the fork aligned with the version of Chromium running in its infrastructure over time.

Screenshot example in minutes

A screenshot-taking Worker is a straightforward way to see the pieces fit together.

Start a project with the relevant dependencies:

npm init -f
npm install wrangler -save-dev
npm install @cloudflare/puppeteer -save-dev

Add the binding to the configuration:

name = "browser-worker"
main = "src/index.ts"
compatibility_date = "2023-03-14"
node_compat = true
workers_dev = true

browser = { binding = "MYBROWSER", type = "browser" }

Then implement the Worker:

import puppeteer from "@cloudflare/puppeteer";

export default {
    async fetch(request: Request, env: Env): Promise<Response> {
        const { searchParams } = new URL(request.url);
        let url = searchParams.get("url");
        let img: Buffer;
        if (url) {
            const browser = await puppeteer.launch(env.MYBROWSER);
            const page = await browser.newPage();
            await page.goto(url);
            img = (await page.screenshot()) as Buffer;
            await browser.close();
            return new Response(img, {
                headers: {
                    "content-type": "image/jpeg",
                },
            });
        } else {
            return new Response(
                "Please add the ?url=https://example.com/ parameter"
            );
        }
    },
};

The Worker launches a browser, opens a page at the url provided in the request, captures a JPEG screenshot, closes the browser, and returns the image. Running npx wrangler dev --remote tests it locally against the remote service; npx wrangler publish deploys it.

From there, the full Puppeteer API is available, and since the service is built on Workers, other Cloudflare developer products can be mixed in. Cloudflare points to D1 or KV for caching screenshots, R2 for archiving crawled assets, Durable Objects to share a browser instance across requests, and Queues for asynchronous job handling.

Scaling with Radar URL Scanner

Cloudflare says its own Radar URL Scanner has been a major stress test for the API. The scanner, which builds detailed technical, performance, privacy, and security reports for any submitted URL, processes thousands of scans per day. It uses the Browser Rendering API with Puppeteer to produce enriched HAR archives and screenshots, Durable Objects to reuse browsers, Queues for asynchronous job processing, and R2 for report storage.

What comes next

Several items are on the roadmap. Cloudflare is exploring upstreaming the Puppeteer fork changes so the official library can work with the Browser Rendering API via a configuration option. The DevTools-exposing design is intended to accommodate other automation libraries such as Playwright. The team is also tracking WebDriver BiDi, the emerging standard automation protocol.

Documentation, API details, limits, and starter templates are available in the dedicated Browser Rendering section of the Cloudflare Developers site.