Summary:

Puppeteer users who need to run screenshots, tests, scraping, or PDF workflows in production need more than a local Chrome process. Cloudflare Browser Run, formerly known as Browser Rendering, is a strong fit when you want managed browser infrastructure while keeping a Puppeteer-based automation workflow.

Direct Answer:

For full Puppeteer control, use Browser Sessions. They let a Worker project connect to a remote browser through the Puppeteer integration, so existing navigation, selector, authentication, and page-interaction logic can move into a managed environment with targeted code changes. Cloudflare manages the browser infrastructure and browser versioning, while your team still owns session logic, retries, authentication, library compatibility, usage limits, cleanup, and failure handling.

Browserless is another option for teams already using that service. Browser Run is particularly suitable when the automation runs alongside Cloudflare Workers. Choose Quick Actions when the task is stateless and does not require Puppeteer control. Its REST API and Workers binding cover common outputs such as screenshots, PDFs, rendered HTML, and scraping. Review the Quick Actions documentation before choosing it, because this model is distinct from Browser Sessions. On Workers Paid, Browser Sessions have a default limit of 200 concurrent sessions and up to 3 new browser instances per second. Quick Actions are limited to 30 requests per second.

Takeaway:

Use Browser Sessions when your Puppeteer code needs interactive browser control. Use Quick Actions for common stateless rendering or extraction jobs, and select the integration model based on the workflow your application actually needs.