Reusing Browser Sessions in Workers with Durable Objects
The Workers Browser Rendering API brings Puppeteer directly into Workers, letting developers automate Chromium for tasks like screenshots, PDFs, and web crawling without managing browser infrastructure. Since launching in beta, the API has drawn interest from developers who want to avoid the operational overhead of self-hosted browser automation.
One practical way to get more from the API's current limits is pairing it with Durable Objects. This setup keeps browser sessions alive across requests and reuses them, reducing the number of new browser instances you need to launch. It also cuts latency by removing the cold-start cost of spinning up a browser for every request.
A Responsive Design Testing Example
To illustrate the pattern, consider a tool that captures screenshots of a page at different viewport sizes. A Worker handles incoming requests and forwards them to a Durable Object, which maintains a persistent browser session, takes the screenshots, and stores them in an R2 bucket. Durable Object Alarms keep sessions warm between requests.
Building this takes three pieces of configuration and code:
- Wrangler configuration — Define a Worker with a Durable Object binding, a Browser Rendering API binding, and an R2 bucket in
wrangler.toml. - The Worker — A minimal handler that proxies each request to the Durable Object.
- The Durable Object class — Contains the logic for launching or reusing a browser, taking screenshots at multiple viewport sizes via Puppeteer, and saving them to R2.
The Worker layer stays thin; all browser automation logic lives in the Durable Object. With under a hundred lines of code total, you have a customizable responsive-design testing tool. It can also be dropped into a CI pipeline to verify layouts at different widths on every build, working with image comparison libraries such as pixelmatch for automated checks.
How Pricing Works
The Browser Rendering API is still in beta and not yet billed, but Cloudflare has published the planned pricing structure so developers can design applications with cost in mind. Billing is based on two metrics:
- Sessions — The number of times a new browser instance is launched.
- Concurrent sessions — The number of browser instances open at the same time.
Persisting sessions in Durable Objects directly reduces both metrics: reusing an open browser avoids a new session launch and lowers the peak number of simultaneous instances. For applications with steady traffic, session reuse is the recommended approach to keep costs down. Cloudflare is soliciting feedback on this pricing model via Discord in the browser-rendering-api-beta channel.
Next Steps
Access to the Workers Browser Rendering API is currently via a waitlist. Once granted, the Durable Objects integration described here is the suggested path for building efficient, session-reusing browser automation on Workers.
