Cloudflare rebuilt Browser Run on its own Containers. Concurrency went from 30 to 120.

Cloudflare moved Browser Run, its headless-Chrome-as-a-service product, off shared Browser Isolation containers and onto its own Containers platform on May 13. Customers got four times the concurrent-browser ceiling, half the response time on Quick Actions, and zero migration work. The team buried the change inside a normal product blog post.

The motivation, per the Cloudflare engineering writeup, is the AI coding agents that have been pounding the API since the start of the year. Browser Run sat on shared infrastructure originally built for the company’s enterprise Browser Isolation product, where a small number of human users drive long-lived sessions. Agents drive short, bursty sessions in much larger fan-out patterns, and the old plumbing started dropping requests under that load. The fix was a full underlying-platform swap.

What changed in the plumbing

Ruskin Constant, Rui Figueira, and Sofia Cardita wrote the post. The before-and-after they describe is concrete. The old system shared one BISO container across multiple tenants, with state held in Workers KV. The new system gives each customer dedicated Cloudflare Containers under Durable Objects, with state in D1 and a Queues-based dispatch loop.

The headline numbers from the post: 60 browsers per minute via the Workers binding, up to 120 concurrent (up from 30), batch-write P95 of 0.1ms against the new D1 state, queue lag under 2 seconds. Quick Actions, the high-frequency “navigate, click, screenshot, snippet” endpoints, dropped more than 50% in p95. “You don’t need to change anything: these improvements are live today,” the team wrote.

WebGL support came along for the ride. Browser Run can now render canvas-heavy pages, which matters for any agent reading Figma, Tableau, Three.js scenes, or the half-dozen JavaScript fingerprinting probes that load detection sites use. WebMCP, the Model Context Protocol binding for web actions, also shipped, letting any MCP-aware client point a Browser Run instance at a page and get back structured DOM and accessibility data without writing CDP plumbing.

Why it’s the last piece of a six-month buildout

Cloudflare has been assembling agent infrastructure in public since February. InfoQ’s roundup reads the May 13 rebuild as the sixth and last layer: compute (Dynamic Workers and Sandboxes), orchestration (Dynamic Workflows), memory (Agent Memory), browsing (Browser Run), and commerce (Stripe Projects). Each launch landed in its own blog post, none as a single product event. Browser Run was the laggard layer because the old infrastructure couldn’t scale.

The competitive cut is straightforward. BrowserBase, the closest VC-funded competitor raised at a $250 million valuation in March on the bet that headless-browser-as-a-service for agents is a standalone category. Cloudflare’s pitch is that the category is a feature of the agent platform, and that the headless browser should live one Workers RPC call away from the agent loop, not behind a separate API key on a different cloud. With 4x the ceiling and WebGL, the platform argument gets meaningfully sharper.

What we don’t know

• The full pricing curve at 120 concurrent. The May 13 post says “no pricing changes,” but the docs still cap free-tier at 10 concurrent and the paid tier at 60 unless you ask. The 120 ceiling is described as available but not as a self-serve default.
• The WebGL substrate. Cloudflare didn’t say whether the rendering is software-backed or runs on real GPUs in its Workers fleet. For agents that screenshot and OCR, software WebGL is fine; for agents driving real-time 3D, the answer matters.
• Whether the dedicated-container model raises the long-tail latency floor. The post claims median improvements but doesn’t publish p99. Agent workloads often live or die on tail behavior, not on median.

What this means for you

If you’re already on Browser Run, the upgrade is free and automatic. The only thing worth doing is testing the new ceilings against your real workload. If you’ve been queueing 31st-and-up sessions waiting for a slot, the queue should be empty now.

If you’re shipping an agent on Vercel, Fly, or AWS Lambda and proxying to BrowserBase, the math just changed. A platform whose Workers compute, KV store, queue, and headless browser all live one binding call apart matters more for agent latency than any single per-feature comparison. Run a real workload through both stacks. The Anthropic-Cloudflare playbook around Managed Agents and the wider agentic-coding tooling shift point at the same direction: agent infrastructure is converging on whichever platform owns the most layers natively. The Browser Run rebuild closes Cloudflare’s gap on the browsing layer.