If you’ve ever tried running a headless browser in production, you know the story. You spin up a VPS, install Chromium, wrestle with dependency trees, wire up Puppeteer, and then spend the next month babysitting a process that eats RAM and crashes the moment a page does something unexpected. The browser was never the hard part — hosting the browser was.
Cloudflare just reframed the whole problem. Browser Run (formerly Browser Rendering) runs headless Chrome across Cloudflare’s global network, and the interesting part isn’t that it exists — there are plenty of “browser-as-a-service” products out there. The interesting part is the approach: for the most common tasks, the browser becomes a single HTTP request. No Worker to deploy, no Chromium to install, no infra to babysit.
Quick Actions: a screenshot is just one HTTP call
The flagship feature is Quick Actions — stateless endpoints for the browser tasks you do every day. Hit a URL, get a result. No code deployment.
The current lineup:
/screenshot— capture a screenshot of any page or raw HTML/pdf— render a page to PDF/markdown— extract clean Markdown from a webpage/content— get fully rendered HTML/scrape— extract specific HTML elements/json— extract structured data with AI from a natural language prompt/links— retrieve all links from a page/snapshot— capture multiple page formats at once/crawl(beta) — multi-page content extraction with async results
That /markdown endpoint alone is worth it if you’re building anything that feeds web content to an LLM — it’s the “fetch and clean” step you’ve probably written by hand three times. And /json is the quiet ambitious one: you describe the data you want in natural language and it returns structured output, no selector wrestling.
Runs on Free and Paid plans, which matters: you can prototype everything before spending a dime.
When you need the real browser: Sessions
Quick Actions cover the 80% stateless use cases. For the rest — login flows, multi-step automation, anything that needs to maintain state — there are Browser Sessions, full browser control via the libraries you already know: Puppeteer, Playwright, or raw CDP (Chrome DevTools Protocol). If you have existing scripts, porting them is more of a connection string change than a rewrite.
This is where Browser Run stops being a utility and becomes infrastructure.
The part that makes this a 2026 story: the agent angle
Here’s the shift. Cloudflare didn’t just rebrand the product — they’re stacking agent-oriented features on top. Recent beta additions tell you exactly where this is going:
- Playwright MCP and CDP with MCP clients — let an LLM control the browser through the Model Context Protocol
- WebMCP — expose browser capabilities to agents
- Stagehand — resilient, AI-assisted scraping that doesn’t break when a page’s markup changes
- Live View and Human in the Loop — watch an agent’s session in real time, and step in when it needs a human (think: solving an auth challenge mid-flow)
Read together, the picture is clear: this is a browser built for your AI agent to operate, with the human in the loop where it matters. The headless Chrome that used to be a scraping tool is becoming the hands an agent uses to touch the web.
Why this matters for your stack
The pitch is the same whether you’re a solo dev or running platform infra: you save yourself an entire category of operational pain. The self-hosted browser problem — the VPS, the Chromium build, the memory leaks, the 3 a.m. restarts — simply stops being yours. For a quick screenshot or PDF it’s one HTTP call; for real automation it’s the same Puppeteer/Playwright code you’d write anyway, minus the server.
And because Quick Actions are model-agnostic and the Sessions layer speaks standard protocols, none of this locks you into the broader Cloudflare ecosystem for it to be useful. You can use exactly the piece you need.
If you’re self-hosting your own browser, this is the week to ask yourself why.