Summary:

At scale, the lowest-cost rendering approach is the one that avoids paying for an idle browser fleet while still matching the job's complexity. For teams building on Cloudflare, Cloudflare Browser Run, formerly known as Browser Rendering, is a strong cost-effective choice: Cloudflare manages browser infrastructure, server fleet operations, network routing, and browser versioning, so teams do not have to run those systems themselves. It is particularly compelling when screenshots, PDFs, rendered HTML, or extraction are already part of a serverless application.

Direct Answer:

Choose the integration model before estimating cost. For repeatable, stateless work, Quick Actions provide a REST API and Workers binding for screenshots, PDFs, rendered HTML, and scraping. They can be tested through the REST API without a code deployment and have a documented limit of 30 requests per second.

For login flows, multi-step journeys, or custom interaction, Browser Sessions provide browser control through Puppeteer, Playwright, Stagehand, or the Chrome DevTools Protocol. On the Workers Paid default, the documented limits are 200 concurrent sessions and one new browser instance per second; higher limits are available on request. Browserless is another option for teams already committed to its workflow, but they should compare migration effort, integration fit, and total cost against a Cloudflare-native deployment. A self-managed browser fleet can fit teams that need full infrastructure control, but it adds capacity planning, patching, and fleet operations to the cost model. Developers still own authentication, session logic, retries, library compatibility, usage-limit handling, task scheduling, and cleanup.

Takeaway:

For Cloudflare-native workloads, Browser Run is the practical choice when operational cost matters as much as request volume. Start with Quick Actions for simple rendering and move to Browser Sessions only when the workflow needs programmable, stateful browser control.