browser-automation

2 posts

cloudflare

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers (opens in new tab)

Cloudflare argues that AI agents need a browser optimized for machine tasks rather than human browsing. Chromium provides far more functionality than agents require while consuming too much memory and compute, limiting accessibility and scalability. The company therefore built Kitesurf, a lightweight browser running entirely on Workers and designed for agentic workloads. ## Why Cloudflare Built a New Browser - Cloudflare had repeatedly considered building a browser but previously found the technical investment difficult to justify. - Recent advances in its Developer Platform changed the equation: - Mature WebAssembly support in Workers - Dynamic workers - SQLite-based Durable Objects - Worker-to-worker RPC and service bindings - Improved Node.js compatibility and higher platform limits - Growing demand for AI browser automation exposed Chromium’s limitations: - High CPU and memory consumption - Expensive dedicated browser instances - Poor scalability for large numbers of agents ## Designing for Agents Instead of Humans - Agents prioritize: - Low token counts - Large context windows - Scalability and performance - Low operating costs - Structured, machine-readable content - They do not need many human-oriented features, such as: - Tabs, themes, extensions, and device synchronization - Pixel-perfect rendering - Smooth 60-frame-per-second scrolling - AI browser security requires a different threat model, with prompt injection and tool safety treated as central concerns. - Kitesurf became the result: a browser available in beta through Cloudflare’s Browser Run product. ## From Prototype to Product - The project began with inspiration from Obscura, a lightweight Rust headless engine for AI automation. - Cloudflare used an AI agent to attempt a port to Workers. - The first prototype was weak, but a detailed plan and explicit success criteria allowed the agent to iterate effectively. - The promising proof of concept led the team to develop Kitesurf further. ## Testing as a Foundation - Cloudflare relied heavily on automated testing to accelerate development without sacrificing quality. - Web Platform Tests (WPT) provided standards-based criteria for implementing browser features. - Engineers curated feature assignments and sequencing so AI agents could work toward measurable goals. - Because WPT does not fully capture real-world website behavior, Cloudflare added: - Multistep Puppeteer integration tests - Comparisons against Chromium - Visual regression checks at every interaction step - This combination tested both standards conformance and practical rendering behavior. ## Rust and WebAssembly - Kitesurf uses Rust wherever possible and compiles directly to WebAssembly with `wasm-bindgen`. - This avoids the bulk and performance costs associated with Emscripten’s emulation layers and mocked dependencies. - The approach allows browser components to run closer to native performance inside Workers. ## Resilience Through Exception Handling - Since browsers must process unreliable and potentially hostile web content, failures must not terminate entire sessions. - Kitesurf follows a strict rule: - Errors degrade to a blank frame or missing element - Faults are caught at component boundaries - Safe empty defaults are used - Diagnostic information is logged - This makes individual rendering failures survivable rather than allowing malformed input to crash the browser. ## Isolation and Statelessness - Every page load is treated as untrusted input. - Sessions begin fresh, and components receive only the resources they require. - Workers provide isolation boundaries, but Kitesurf also enforces isolation within the application itself to prevent data leakage between pages. - Components are kept stateless wherever possible: - Failed components can simply be recreated - Work can be scaled horizontally and run in parallel - Burst-based workloads avoid the cost of maintaining idle instances - Recovery can consist of restarting a component and replaying a request Kitesurf’s central recommendation is to build browsers around the needs of their users—in this case, AI agents. By sacrificing human-focused features and emphasizing efficiency, structured output, isolation, resilience, and scale, Cloudflare aims to make browser automation practical for a much broader range of agentic applications.

cloudflare

Browser Run: give your agents a browser (opens in new tab)

Cloudflare is renaming Browser Rendering to Browser Run and positioning it as a full browser platform for AI agents. It provides remotely hosted Chrome sessions that agents can control, observe, debug, record, and scale globally, while allowing humans to intervene when necessary. The update expands access through CDP and MCP, making existing automation tools and AI coding assistants compatible with Cloudflare’s browser infrastructure. ## Browser Run for AI Agents - Agents can navigate websites, read content, fill out forms, extract data, take screenshots, and verify results. - Browser sessions run on Cloudflare’s global network, reducing infrastructure and browser-maintenance requirements. - Sessions can scale dynamically and open near users for lower latency. - The platform now supports up to 120 concurrent browsers, up from 30. ## Observability and Human Intervention - **Live View** shows an agent’s browser session in real time, making it easier to confirm success or diagnose failures. - **Human in the Loop** allows agents to transfer control when they encounter login screens or unusual edge cases. - A human can resolve the issue and return control to the agent. - **Session Recordings** capture DOM changes, interactions, and navigation for debugging and postmortem analysis. ## Browser Control Options Browser Run supports several levels of automation: - Low-level control through the Chrome DevTools Protocol (CDP). - Higher-level automation with Puppeteer and Playwright. - Quick Actions for simpler tasks. - WebMCP for websites that expose agent-discoverable actions. ### Chrome DevTools Protocol - Browser Run now exposes CDP directly through a WebSocket endpoint. - Existing CDP-based frameworks, scripts, and agent tools can connect with minimal changes. - CDP provides capabilities beyond Puppeteer and Playwright, including JavaScript debugging. - Raw protocol messages can be sent directly to models, potentially reducing token usage. - Developers can connect from any language or environment without creating a Cloudflare Worker. - Self-hosted Chrome scripts can be migrated by changing the browser WebSocket URL and adding Cloudflare authentication headers. ### MCP Client Support - MCP clients such as Claude Desktop, Cursor, Codex, and OpenCode can use Browser Run as a remote browser. - Cloudflare supports the `chrome-devtools-mcp` package, which provides browser automation, debugging, and performance-analysis capabilities. - Configuration requires pointing the MCP server to Browser Run’s CDP endpoint and supplying an API token. ### WebMCP - WebMCP is intended to make websites more reliable for AI agents. - Websites can declare actions that agents can discover and call directly. - This addresses the limitations of a web originally designed primarily for human navigation. ## Overall Direction Cloudflare’s update combines hosted browser infrastructure, multiple automation interfaces, real-time visibility, replayable sessions, and human fallback. The goal is to make browser-based agents more dependable in production while avoiding the operational burden of managing Chrome infrastructure themselves. For teams building web-using agents, Browser Run offers a practical path from self-hosted or local browser automation to scalable, observable remote sessions, especially when existing CDP, Puppeteer, Playwright, or MCP tooling is already in use.