Cloudflare gör webbläsarmotorn Kitesurf för AI-agenter till öppen källkod

Cloudflare meddelade den 13 november 2026 att Kitesurf, företagets experimentella webbläsarmotor för AI-agenter, nu finns tillgänglig som öppen källkod under Apache 2.0-licensen. Utvecklare kan granska och ändra koden, köra den lokalt eller driftsätta en egen instans på Cloudflare Workers.

Det offentliga kodförrådet ger utvecklare möjlighet att köra och ändra motorn i sina egna Cloudflare-konton i stället för att enbart förlita sig på de hanterade API:erna i Browser Run. Cloudflare hade utlovat detta steg när företaget presenterade Kitesurf den 6 augusti 2026, och återigen i en uppdatering den 28 september 2026 som lade till stöd för WebMCP, utökade stödet för webbläsar-API:er och Browser Run samt introducerade terminalrendering.

Så är Kitesurf utformat för AI-agenter

Kitesurf omvandlar HTML och CSS till renderade sidor, kör sidornas JavaScript och skapar skärmbilder utan Chrome eller en webbläsarkontainer. Motorn tillhandahåller en slutpunkt för Chrome DevTools Protocol (CDP), det kontrollgränssnitt som används av Chrome DevTools och kompatibel automatiseringsprogramvara, så att Puppeteer-klienter och AI-agentramverk kan ansluta.

Internt samordnar Engine webbläsarsessioner och klientanslutningar, PageScript kör sidan och dess JavaScript, och PageRenderer skapar det visuella resultatet. Cloudflares utvecklarplattform kombineras med Rust-komponenter som kompilerats till WebAssembly: Blitz hanterar HTML-tolkning, DOM, layout och ritning; Stylo hanterar CSS; Linebender-biblioteken står för text och 2D-grafik; och Krilla skapar PDF-utdata. Boa tillhandahåller en reservkörmiljö för JavaScript i WebAssembly när sidans kod inte kan köras i Dynamic Workers.

Cloudflare uppger att målet med utformningen är att ge agenter den webbåtkomst de behöver med lägre CPU- och minnesförbrukning än en fullständig Chromium-webbläsare, samtidigt som kapaciteten skalas efter behov i företagets Workers-nätverk. Den ursprungliga arkitekturen behandlar varje sidladdning som otillförlitlig indata och isolerar komponenterna utifrån vilka resurser de behöver. En särskild SandboxOutbound-worker hanterar all extern hämtning, tillämpar nätverkspolicy och håller varje sidas cookies åtskilda. Övriga komponenter kan inte komma åt nätverket direkt.

Tillståndslöshet är ytterligare en del av utformningen. Engine behåller sessionstillståndet, medan andra komponenter kan tas bort och ersättas när det är möjligt. Därmed kan kapaciteten anpassas efter perioder med hög aktivitet bland agenterna. PageRenderer lagrar inget beständigt sidtillstånd, så Engine kan ersätta den efter en misslyckad eller avstannad renderingsbegäran.

Krav och säkerhet vid egen drift

För lokal utveckling krävs Bazelisk, Node.js 22 eller senare och pnpm 9.15.4. Utvecklingskommandot bygger WebAssembly-modulerna samt sid- och renderarpaketen och startar sedan en lokal motor på 127.0.0.1:8787. Den första byggningen kompilerar Rust-kärnan och de medföljande beroendena, medan senare byggningar återanvänder Bazels cache. Därefter kan utvecklare granska sidor via Chrome DevTools eller ansluta Puppeteer och andra CDP-klienter.

Driftsättning på Cloudflare kräver en Workers Paid-plan eftersom Dynamic Workers skapar de isolerade workers som används för sidor och renderare. Efter lokala tester kan operatörer driftsätta motorn på sitt eget konto som ett alternativ till de hanterade API:erna i Browser Run.

Egen drift innebär också att ett viktigt säkerhetsansvar övergår till operatören. Motorn har ingen egen autentisering, och dess workers.dev-adress är som standard offentlig. Utan Cloudflare Access eller ett annat autentiseringslager kan vem som helst som har URL:en surfa via motorn, ansluta CDP-klienter, skicka förfrågningar från operatörens Cloudflare-konto och förbruka betald CPU-tid och Dynamic Workers. Kodförrådet instruerar operatörer att omedelbart skydda URL:en och beskriver hur Access aktiveras för hela kontot före driftsättning, så att adressen inte hinner vara offentlig.

Experimentell status och bidragsprocess

Kitesurf är fortfarande experimentellt och under intensiv utveckling. Kodförrådet beskriver det som en CDP-slutpunkt snarare än en fullständig Chrome-implementering, och vissa funktioner i Chrome DevTools stöds fortfarande inte. Cloudflare prioriterar kompatibilitet, tillförlitlighet och effektivitet.

Vid lanseringen i augusti uppgav Cloudflare att Kitesurf ännu inte lämpade sig för video, WebGL, handskakningar vid botutmaningar som kräver verkliga TLS-fingeravtryck eller långa autentiserade sessioner som är beroende av beständigt tillstånd. Dessa begränsningar visar vilka kompatibilitetskontroller som fortfarande är viktiga för agentarbetslaster, även när en lättare webbläsares resursförbrukning är attraktiv.

Bidragsprocessen är utformad för att stödja det pågående arbetet. Cloudflare ber blivande bidragsgivare att öppna ett ärende med en minimal reproduktion eller ett föreslaget tillvägagångssätt och få en rekommendation från en underhållare innan de skickar in en pull-begäran. Avgränsade ändringar med tester och tydligt definierad omfattning föredras, men även reproducerbara renderingsfel, automatiserade arbetsflöden som inte fungerar och korrigeringar av dokumentationen välkomnas.

För utvecklare innebär avvägningen direkt kontroll över webbläsarstacken, mot att de själva ansvarar för att säkra driftsättningen och måste hantera att motorns kompatibilitet med Chrome och webbplattformen fortfarande är ofullständig.