What is a cloud browser?

A cloud browser is a browser instance running on remote infrastructure that your code drives over a network connection, usually the Chrome DevTools Protocol. Your Puppeteer or Playwright script connects to it instead of launching a browser locally, and everything else about the code stays the same.

Why not just run your own

Running one headless browser is easy. Running many is an infrastructure project, and the costs arrive in a predictable order.

Memory. A Chromium instance with a real page loaded consumes hundreds of megabytes. Fifty concurrent sessions is a large machine doing nothing but hosting browsers.

Crash recovery. Browsers hang, leak and die. Something has to notice and replace them, and that something is code you now maintain.

Version drift. Chromium updates frequently, and each update can change behaviour your automation depended on. Pinning a version means running an increasingly conspicuous old browser.

Addresses. A browser on a cloud server has a datacenter IP. Combined with a default automation fingerprint, that is the pairing anti-bot systems look for first, so the browser works and the pages refuse it.

The last one is the reason cloud browsers exist as a category rather than as a convenience. Solving memory and crashes is ordinary infrastructure work. Solving addresses and fingerprints is a continuing effort against a moving target.

What to look for

Sessions that start quickly, since a cold start on every task destroys throughput. Control over geography, because a page served to a visitor in Madrid differs from the one served to Chicago. A session lifetime that matches your work, long enough to finish a flow and short enough not to pay for idle time. And residential routing, without which most of the advantage disappears.

Where Zenrows fits

Zenrows Browser Sessions is a cloud browser reached over CDP, so connecting is a one-line change to existing Puppeteer or Playwright code rather than a rewrite. Sessions route through residential IPs with country and world-region targeting, and session TTL is configurable from one to fifteen minutes so a session lasts as long as the flow it is running.

Worth saying plainly: a browser is the expensive option. If a page returns its content to a plain request, Fetch is faster and cheaper, and a cloud browser is what you escalate to when the page genuinely needs interaction.