Cloudflare Browser Rendering and Browser Run: sessions, limits, and automation architecture

Cloudflare Browser Run provides access to a managed Chrome browser without requiring you to configure your own server. It is used to render JavaScript pages, take screenshots, generate PDFs, test interfaces, and run browser workflows with AI agents.

You can still find information about this product under the Cloudflare Browser Rendering name, but Browser Run is its current name as of 2026. It works well for one-off page rendering and permitted data collection tasks, while long-running authenticated sessions need a separate approach to state persistence. If anti-bot checks are the main challenge, first understand how Cloudflare works for web scraping, then choose a browser runtime.

In practice, the choice comes down to three architectural approaches:

• Browser Run as a cloud renderer for pages that can be processed legally without a persistent user profile
• local or server-hosted Playwright, Puppeteer, or Selenium when full control over the environment is required
• profile infrastructure where cookies, localStorage, proxies, browser fingerprints, and account settings persist in a consistent environment

For processes that do not require code, visual automation workflows may be useful.

How the Browser Rendering and Browser Run names relate

Cloudflare Browser Rendering is the product's former name, while Browser Run is its current name. Cloudflare's documentation explicitly states that Browser Run was formerly called Browser Rendering, so both names may appear in search results and articles.

In practice, use Browser Run as your reference point. Current pages about Quick Actions, Playwright, Puppeteer, CDP, limits, and pricing use this name. If an older article or code sample still contains browser-rendering, that does not necessarily mean the API is obsolete. Check the route, SDK, and documentation date separately.

If your team plans to control browser tasks through AI agents, assess Afina MCP for AI agents separately. This keeps the choice of a cloud runtime distinct from the choice of orchestration tool.

For SEO and technical searches, account for both names:

• cloudflare browser rendering as the older high-volume query
• cloudflare browser run as the current product name
• browser run limits for queries about quotas and 429 errors
• browser run sessions for queries about browser reuse
• cloudflare headless chrome for queries about runtime mechanics

This distinction saves time during troubleshooting. A team searching for a Browser time limit exceeded error needs the Browser Run limits page. If it is reading an older Browser Rendering review, it should check whether the limit values changed after the rename.

Which browser launch and control methods are available now

Browser Run offers two main ways to work: simple Quick Actions and full Browser Sessions. The first suits one-off requests. The second is for workflows where code controls tabs, events, the DOM, and the browser lifecycle.

Quick Actions work as ready-made HTTP operations. They can retrieve HTML, take a screenshot, generate a PDF, return Markdown, collect links, or run a page-crawling task. This is useful when you do not need to build a complex Playwright workflow. For example, a monitoring service can take an hourly screenshot of its own page after a deployment or verify that SSR works correctly on a JavaScript-heavy page.

Browser Sessions provide more detailed browser control. In this mode, you can use Puppeteer, Playwright, and CDP for workflows in which code opens pages, waits for elements, clicks buttons, reads localStorage, or operates several tabs in one browser. For teams already using Playwright or Puppeteer, this is one of the simplest migration paths: the connection changes, while most test or crawling logic can remain intact.

You can use a minimal Playwright example to test the connection. Here, BROWSER_CDP_URL is the CDP connection address issued for your browser session. The exact way to obtain it depends on how you launch Browser Run.

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(process.env.BROWSER_CDP_URL);
try {
  const context = browser.contexts()[0] ?? await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  console.log(await page.title());
} finally {
  await browser.close();
}

This example controls an available CDP session; it is not a complete guide to creating one in Cloudflare. Add error handling and execution time controls for production use.

Browser Run is not a universal replacement for every browser tool. It is a cloud runtime for a particular class of tasks. If a task takes about a minute and does not need a persistent user profile, Browser Run is a logical choice. If you must return to a site in the same profile, you need a saved profile rather than another fresh headless Chrome instance.

Not every workflow fits only one of these options. A product will often combine short page-processing and rendering tasks for technical checks with separate profile infrastructure for operator work.

How to check session, launch, and concurrent browser limits

Browser Run limits depend on the Cloudflare Workers plan and the type of usage. The Free plan includes 10 minutes of browser time per day, 3 concurrent Browser Sessions, 1 new browser every 20 seconds, a 60-second idle timeout, and 1 Quick Actions request every 10 seconds.

Workers Paid uses a different model. Cloudflare's limits page lists no daily cap on browser hours, 200 concurrent Browser Sessions by default, 3 new browsers per second, a 60-second idle timeout, and 30 Quick Actions requests per second. The pricing page lists 10 browser hours per month as included, $0.09 for each additional browser hour, 10 concurrent browsers included for Browser Sessions, and $2.00 for each additional concurrent browser based on a monthly average calculation.

Do not confuse two different figures. The limit of 200 concurrent browsers in the limits documentation is the default technical ceiling for Paid. The 10 concurrent browsers on the pricing page are the amount included in the plan before monthly average peak concurrency incurs extra charges. This is why a team may be technically able to launch more browsers than its base plan includes.

Start with a short test rather than a production workload:

1. record the Cloudflare Workers plan and the date of the test
2. run one Quick Action and save X-Browser-Ms-Used
3. start one Browser Session and close it with browser.close()
4. repeat launches in a series and watch for HTTP 429 responses
5. test the idle timeout by sending no commands for 60 seconds
6. repeat the test with keep_alive if the workflow pauses between actions
7. compare the result with the Browser Run dashboard

During this check, the problem often turns out to be a code error rather than a Cloudflare limit. For example, the browser may not close in the finally block, leaving the session active until timeout while browser time continues to accrue. That bug can lead to unexpected costs.

After this test, the team can see its own workload pattern instead of an abstract pricing model. That is a better basis for a budget than third-party test results produced with different pages and code.

How to estimate costs for a typical production workflow

Browser Run pricing is based on browser time and, for Browser Sessions, monthly average concurrency rather than page count. Two workflows that each process 100,000 URLs can therefore cost different amounts. Lightweight pages handled through Quick Actions consume little time, while complex single-page applications with scripts, media, and a long networkidle2 wait consume more.

Failed requests and timeouts deserve separate attention. Cloudflare states that Quick Actions with waitForTimeout do not add billable browser hours, but that is no reason to allow unlimited retries. Retries consume request limits faster, grow the task queue, and make logs harder to analyze.

First, reduce page weight and block resources that the workflow does not need, when the use case permits it. Set waitForSelector precisely and avoid waiting for all network activity to stop on pages that keep analytics or a websocket connection active.

Consider a simplified Workers Paid calculation where a team uses 50 browser hours per month. The first 10 hours are included, so the remaining 40 hours are multiplied by $0.09. Browser time adds $3.60 above the base plan. If Browser Sessions average 15 concurrent browsers over the month, 10 are included and the other 5 are multiplied by $2.00. That adds $10.00 for concurrency. Total additional cost is $13.60, excluding the Workers Paid plan itself.

Use this simple formula for your own workflow:

1. measure average browser time per page
2. multiply it by the monthly number of pages
3. convert seconds to hours
4. subtract the 10 hours included with Workers Paid
5. multiply the remainder by $0.09
6. separately calculate monthly average daily peak concurrent browsers
7. add the charge for concurrent browsers above the included amount

After calculating, build a cost comparison table with one column for Quick Actions, another for Browser Sessions, and a third for your own infrastructure. It immediately shows whether the team is paying for real rendering or for idle time, retries, and excessive concurrency.

Browser Run is generally easier to launch, while your own infrastructure offers more flexibility. The right choice depends on which costs your team more: infrastructure or the constraints of a managed environment.

Quick Actions costs are usually easier to estimate when a workflow consists of short, independent actions. If you need a session, tabs, and CDP, the bill depends on whether the browser closes as soon as the task finishes. For automation outside Cloudflare, compare this model with the cost of servers, a task queue, browser updates, monitoring, and maintaining the Playwright stack. Depending on load and infrastructure requirements, Cloudflare may be either less or more expensive.

When to use a managed cloud browser or your own profiles

A managed cloud browser is best for tasks where the browser is a disposable worker rather than a persistent user profile. Examples include screenshots, PDFs, QA checks, crawling your own pages, preview generation, and rendering content for a system authorized to access those pages.

Separate profiles are necessary when state must persist across runs. An authenticated account, cookies, local storage, session history, a stable proxy, time zone, language, WebGL, Canvas, and User-Agent should remain consistent. If every run starts in a clean environment, the site may see each one as a new browser environment. For tasks involving browser fingerprints and headless-browser indicators, read the guide to headless browser detection. The problem is often not the code but how the environment appears to the site.

The comparison below helps rule out the wrong architecture quickly:

For one-off rendering tasks, start by considering Browser Run. If you need full control over the code and environment, your own Playwright setup is more suitable. Isolated browser profiles are a better fit for long-term work with authenticated accounts and persistent state.

Afina is useful here beyond taking a simple screenshot. It brings together separate browser profiles, local automation, an API, proxies, and environment controls for workflows where state must persist between runs. If you need to control workflows programmatically, see the guide to the Afina API. This does not replace Browser Run for quick page rendering; it covers a different class of tasks.

This material is provided solely for informational and educational purposes. For scraping and automation, check the platform's rules, robots.txt, data access terms, and legal restrictions in your jurisdiction. Browser Run is best reserved for permitted, short, and measurable browser actions. Profiles and Afina fit workflows that depend on stable state, account isolation, and controlled automation rather than a one-off headless Chrome launch.