Cloudflare Kitesurf Open Source: Deploy an Agent Browser on Workers

Cloudflare open-sourced Kitesurf, its agent-first browser engine, on November 13, 2026 under the Apache 2.0 license, publishing the Rust and WebAssembly stack on GitHub as cloudflare/kitesurf. Kitesurf parses HTML, applies CSS, executes page JavaScript and renders screenshots inside Cloudflare Workers without Chrome or a browser container, and exposes a Chrome DevTools Protocol endpoint at ws://127.0.0.1:8787/devtools/browser for Puppeteer clients; Cloudflare's benchmarks put it at roughly three to seven times less memory and CPU than headless Chromium, with higher wall-clock latency on some real pages. Running it in production requires Workers Paid for Dynamic Workers and Cloudflare Access before exposing a deploy URL, and Cloudflare offers its managed Browser Run APIs as an alternative.

Cloudflare open-sourced Kitesurf https://github.com/cloudflare/kitesurf?ref=explainx on November 13, 2026 , fulfilling a promise it made when the agent-first browser engine debuted during Agents Week in August https://explainx.ai/blog/cloudflare-kitesurf-agent-browser-v8-isolates-august-2026 . You can now clone the Rust and WebAssembly stack, run it on 127.0.0.1:8787 , and pnpm run deploy it to your own Workers account under Apache 2.0 . The release matters because many agent harnesses still default to headless Chromium , which is heavy on memory and hard to colocate with cheap inference. Kitesurf keeps HTML parsing, CSS, JavaScript, and screenshots inside Workers , speaks Chrome DevTools Protocol CDP , and pairs naturally with Puppeteer or any CDP client your coding agent already drives. TL;DR: what changed on November 13 | Question | Answer | |---|---| | What shipped? | Public GitHub repo cloudflare/kitesurf , Apache 2.0 , with engine, renderer, DOM shims, and CLI packages | | Why now? | Cloudflare said it always intended to open the engine so builders could audit, patch, and self-host on their accounts | | Local URL | http://127.0.0.1:8787 after pnpm run dev ; health check at /health | | CDP endpoint | ws://127.0.0.1:8787/devtools/browser for Puppeteer-core | | Production gate | Workers Paid for Dynamic Workers; Cloudflare Access mandatory before exposing a deploy URL | | Managed alternative | Browser Run https://developers.cloudflare.com/browser-rendering/?ref=explainx APIs if you do not want to operate Workers | What Kitesurf is and is not Kitesurf is not a Chromium fork. According to the November 13 announcement https://blog.cloudflare.com/kitesurf-open-source/?ref=explainx and the repository README https://github.com/cloudflare/kitesurf?ref=explainx , it parses HTML, applies CSS, executes page JavaScript, and renders screenshots without Chrome or a browser container . It exposes CDP so tools built for Puppeteer can attach. That design trades site compatibility for density . Our August coverage noted Kitesurf often used roughly three to seven times less memory and CPU than headless Chromium in Cloudflare benchmarks, with higher wall-clock latency on some real pages. Open source does not change those trade-offs; it lets you measure them on your workloads and contribute fixes. Kitesurf open source agent browser architecture diagram on Cloudflare Workers Image: Cloudflare https://blog.cloudflare.com/kitesurf-open-source/?ref=explainx Stack inside the repository The blog post and README credit several Rust projects compiled to WebAssembly: | Component | Role | |---|---| | Blitz | HTML parsing, DOM, layout, painting | | Stylo | CSS parsing, cascade, computed styles | | Boa | JavaScript in Wasm when Dynamic Workers cannot run it natively | | Linebender / Krilla | Text layout, 2D graphics, PDF output | Engine , page-script , page-renderer , dom-shim , core , and kitesurf-cli live under packages/ , which is the layout Cloudflare expects contributors to extend. Kitesurf open source repository packages layout for agent browser engine Image: Cloudflare https://blog.cloudflare.com/kitesurf-open-source/?ref=explainx How to run Kitesurf locally today Cloudflare documents a Bazel-first workflow on the README. Requirements include Bazelisk , Node.js 22+ , pinned pnpm 9.15.4 , and on macOS GNU tar . From a clean clone: git clone https://github.com/cloudflare/kitesurf.git cd kitesurf pnpm install --frozen-lockfile pnpm run dev The first compile builds Rust core and vendored crates, so expect a long initial build. Later runs reuse Bazel cache. The engine listens on port 8787 unless you set KITESURF PORT . Puppeteer smoke test The announcement shows puppeteer-core connecting to the local WebSocket: python import puppeteer from "puppeteer-core"; const browser = await puppeteer.connect { browserWSEndpoint: "ws://127.0.0.1:8787/devtools/browser", } ; try { const page = await browser.newPage ; await page.goto "https://example.com/" ; await page.screenshot { path: "page.png" } ; } finally { await browser.disconnect ; } For agent builders, the important line is the CDP endpoint . Harnesses like Chrome DevTools MCP https://explainx.ai/blog/chrome-devtools-mcp-chrome-devtools-for-agents-55k-stars-setup-skills-guide-2026 or custom LangGraph tools can swap the browser URL without rewriting task logic, as long as your pages fit Kitesurf compatibility limits. Chrome DevTools in a tab With pnpm run dev , open http://127.0.0.1:8787/ in Chrome to load the landing UI, paste a URL, and inspect through DevTools. The README also documents chrome://inspect discovery on 127.0.0.1:8787 . Bundled DevTools --config=devtools removes Google's hosted frontend limits but downloads about 250 MB on first build. Deploying to your Cloudflare account From the repository root: pnpm run deploy Wrangler uploads the Worker built by Bazel. The README is blunt: do not leave the Worker public . Without Cloudflare Access Zero Trust or equivalent, anyone who discovers the predictable kitesurf.<subdomain .workers.dev pattern can: - Browse the web through your account egress - Burn Dynamic Workers and CPU you pay for - Attach Puppeteer or other CDP clients Cloudflare recommends enabling Access before deploy, or immediately after step one. For CDP automation behind Access, create a service token and pass CF-Access-Client-Id and CF-Access-Client-Secret headers in puppeteer.connect , per the README. That security model intersects with Cloudflare's modern security write-up for agent pentest orchestrators https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026 : browser automation is outbound attack surface . Treat a Kitesurf Worker like an open proxy unless Access policies wrap it. What developers are saying The Hacker News thread https://news.ycombinator.com/item?id=50489156&ref=explainx was still thin at publish time, with early comments pointing readers to the GitHub repo. Broader agent-browser discourse this week focused on compatibility testing versus cost per session . If you try Kitesurf on production targets, record pass or fail per domain the same way you would for any non-Chromium engine, and share minimal reproductions in GitHub issues as Cloudflare's contribution guide requests. Kitesurf vs managed Browser Run vs Chromium | Option | Best when | Watch out for | |---|---|---| | Managed Browser Run | You want APIs without operating Workers | Less control over patches and release cadence | | Self-hosted Kitesurf | You need custom rendering fixes or air-gapped deploy patterns | You own Access, Dynamic Workers cost, and compatibility | | Headless Chromium | You need maximum site fidelity today | Memory, cold start, and container ops | If your agent only needs structured fetches without full layout, a plain HTTP client plus readability passes may still beat any browser. Kitesurf wins when JavaScript execution or faithful screenshots are required and Workers locality matters. Compatibility and contribution expectations Cloudflare states Kitesurf is experimental and under heavy development . The blog focuses on Web Platform Test progress and reliability. CONTRIBUTING.md requires maintainer vouching before large pull requests, and favors minimal reproductions over sweeping rewrites. For teams comparing agent infra, read Cloudflare's September update chain on WebMCP in the August launch companion https://explainx.ai/blog/cloudflare-kitesurf-agent-browser-v8-isolates-august-2026 and watch whether your harness expects full Chrome APIs that Kitesurf does not implement yet. Bazel, Dynamic Workers, and the page lifecycle The README is explicit that Bazel builds everything : toolchains, wasm-bindgen, and binaryen downloads are pinned so contributors get reproducible artifacts. That choice trades setup time for hermetic builds — reasonable for a browser engine that must ship the same Wasm bits to local wrangler and remote Workers . Each browsing session spins Dynamic Workers for isolated page and renderer instances. That pattern mirrors how Cloudflare described PageScript isolates at launch: JavaScript and layout stay compartmentalized instead of sharing one long-lived Chromium process. The cost is plan gating : teams on free tiers should assume they can develop locally but cannot honestly load-test production traffic without budgeting Workers Paid pricing docs linked from the repository. Understanding the three-package split helps when you debug agent failures: | Package | Failure symptom | Typical fix path | |---|---|---| | engine | CDP disconnects, 5xx from Worker | Check wrangler logs, Access headers | | page-script | JS exceptions, missing APIs | File minimal HTML repro in GitHub | | page-renderer | Blank screenshots, font gaps | Compare against WPT progress notes | Security checklist before you point agents at the internet The README warning block is unusually strong for Cloudflare. Treat it as a pre-deploy gate , not boilerplate: 1. Enable Cloudflare Access on the Worker hostname before sharing URLs in Slack. 2. Rotate service tokens used by Puppeteer the same way you rotate API keys. 3. Log outbound fetches your agents trigger; a compromised prompt can turn Kitesurf into a open relay . 4. Segment accounts so a dev deploy cannot touch production DNS or billing. 5. Re-read SECURITY.md before exposing internal staging sites that lack auth. Agent teams already running Chrome DevTools MCP https://explainx.ai/blog/chrome-devtools-mcp-chrome-devtools-for-agents-55k-stars-setup-skills-guide-2026 should decide whether Kitesurf replaces Chromium for a subset of tasks structured scraping, screenshot regression while keeping Chromium for fallback fidelity . When to stay on Browser Run or Chromium Browser Run remains the lowest-friction path if you only need managed scale and accept Cloudflare's compatibility roadmap. Self-hosting wins when you must: - Patch layout or CDP behavior and ship the patch before the next managed release. - Run browsers inside the same account as custom Workers AI routes for latency experiments. - Audit Wasm sources for compliance reviews that block opaque containers. Against Browserbase skills for Claude Code , Kitesurf is lighter but less mature . Our Browserbase comparison post https://explainx.ai/blog/browserbase-skills-claude-code-browsing-2026 is the right anchor when your harness already expects hosted Chromium . A green cursor following a curved path across blank browser tab outlines, illustrating multi-tab agent browsing What people ask before adopting Kitesurf | Question | Practical answer | |---|---| | Does open source change benchmarks? | No — it changes who can reproduce them on your pages. | | Can I run without Bazel? | Not per current README; pnpm run dev wraps Bazel targets. | | Will my login flows work? | Unknown until you test; plan fallback to Chromium for OAuth quirks. | | Does CDP parity equal Chrome? | No — README warns some DevTools features are incomplete. | | Can agents run headless in CI? | Yes locally; protect CI secrets because CDP is a powerful primitive. | What this means for agent builders 1. Fork budget — Apache 2.0 lets you patch layout or CDP handlers without renegotiating a vendor contract. 2. Colocation — Running beside Workers AI or Vercel-class edge compute https://explainx.ai/blog/vercel-labs-ui-sdk-behaviors-for-agents-react-vue-svelte-beta-2026 is closer when the browser itself is a Worker. 3. Security default — Plan Access on day one ; do not treat open source as safer than managed APIs. 4. Eval loop — Re-run your internal site smoke suite before migrating production agents off Chromium. Related reading - Cloudflare Kitesurf launch architecture https://explainx.ai/blog/cloudflare-kitesurf-agent-browser-v8-isolates-august-2026 — August 2026 benchmarks and V8 isolate design - Chrome DevTools MCP setup guide https://explainx.ai/blog/chrome-devtools-mcp-chrome-devtools-for-agents-55k-stars-setup-skills-guide-2026 — CDP clients agents already use - AWS Bedrock AgentCore runtime https://explainx.ai/blog/aws-bedrock-agentcore-runtime-next-generation-november-2026 — another pattern for hosting agent tools at scale - Ramp Inspect cloud coding agent https://explainx.ai/blog/ramp-inspect-cloud-coding-agent-launch-74-percent-merged-code-2026 — how one team operationalized always-on agent sandboxes - Sparseread token-efficient agent reading https://explainx.ai/blog/sparseread-token-efficient-agent-reading-layer-2026 — when you might skip a browser entirely - Cloudflare security model for agent orchestrators https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026 — threat model for outbound agent traffic Repository structure, pricing, and compatibility statements reflect Cloudflare's November 13, 2026 announcement and README as we fetched them.