AI-modeller og platforme
Cloudflare gør Kitesurf-browsermotoren til open source for AI-agenter

NøglepunkterKitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript…
Vis mere
- Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript for AI agents.
- Self-hosting shifts security to operators because the engine ships without authentication and exposes a public URL.
- Kitesurf remains experimental with incomplete Chrome compatibility despite its efficiency gains for agent workloads.
Cloudflare meddelte den 13. november 2026, at Kitesurf, virksomhedens eksperimentelle browsermotor til AI-agenter, nu er tilgængelig som open source under Apache 2.0-licensen. Udviklere kan gennemgå og ændre koden, køre den lokalt eller udrulle deres egen instans på Cloudflare Workers.
Det offentlige kodearkiv giver udviklere mulighed for at drive og ændre motoren på deres egne Cloudflare-konti i stedet for udelukkende at være afhængige af virksomhedens administrerede Browser Run-API’er. Cloudflare havde lovet dette skridt, da virksomheden introducerede Kitesurf den 6. august 2026, og igen i en opdatering den 28. september 2026, hvor der blev tilføjet understøttelse af WebMCP, udvidet dækning af browser-API’er og Browser Run samt introduceret terminalgengivelse.
Indblik i Kitesurfs design til agenter
Kitesurf omdanner HTML og CSS til gengivne sider, afvikler sidernes JavaScript og tager skærmbilleder uden Chrome eller en browsercontainer. Motoren stiller et Chrome DevTools Protocol (CDP)-slutpunkt til rådighed, dvs. den kontrolgrænseflade, som Chrome DevTools og kompatible automatiseringsprogrammer bruger, så Puppeteer-klienter og AI-agentmiljøer kan oprette forbindelse.
Internt koordinerer Engine browsersessioner og klientforbindelser, PageScript kører siden og dens JavaScript, og PageRenderer skaber det visuelle resultat. Cloudflares Developer Platform kombineres med Rust-komponenter, der er kompileret til WebAssembly: Blitz står for HTML-parsing, DOM, layout og tegning; Stylo håndterer CSS; Linebender-bibliotekerne tager sig af tekst og 2D-grafik; og Krilla opretter PDF-output. Boa leverer et reservekørselsmiljø til JavaScript i WebAssembly, når sidens kode ikke kan køre i Dynamic Workers.
Cloudflare siger, at målet med designet er at give agenter den nødvendige adgang til internettet med et lavere CPU- og hukommelsesforbrug end en komplet Chromium-browser, samtidig med at kapaciteten kan skaleres efter behov på tværs af virksomhedens Workers-netværk. Den oprindelige arkitektur behandler hver sideindlæsning som upålidelig input og isolerer komponenterne efter de ressourcer, de kræver. En dedikeret SandboxOutbound-worker håndterer al ekstern hentning, håndhæver netværkspolitikken og holder hver sides cookies adskilt; andre komponenter kan ikke tilgå netværket direkte.
Tilstandsløshed er en anden del af designet. Engine bevarer sessionstilstanden, mens andre komponenter så vidt muligt kan kasseres, så kapaciteten kan følge med udsving i agentaktiviteten. PageRenderer gemmer ingen vedvarende sidetilstand, så Engine kan udskifte den efter en mislykket eller fastlåst gengivelsesanmodning.
Krav til selvhosting og sikkerhed
Lokal udvikling kræver Bazelisk, Node.js 22 eller nyere samt pnpm 9.15.4. Udviklingskommandoen bygger WebAssembly-modulerne samt pakkerne til siden og rendereren og starter derefter en lokal motor på 127.0.0.1:8787. Den første bygning kompilerer Rust-kernen og de medfølgende afhængigheder, mens senere bygninger genbruger Bazels cache. Udviklere kan derefter undersøge sider via Chrome DevTools eller tilslutte Puppeteer og andre CDP-klienter.
Udrulning på Cloudflare kræver et betalt Workers-abonnement, fordi Dynamic Workers opretter de isolerede workers, der bruges til sider og renderere. Efter lokal afprøvning kan operatører udrulle motoren på deres egen konto som et alternativ til Browser Runs administrerede API’er.
Selvhosting medfører også et vigtigt sikkerhedsansvar. Motoren har ikke sin egen godkendelsesmekanisme, og dens workers.dev-adresse er som standard offentlig. Uden Cloudflare Access eller et andet godkendelseslag kan enhver med URL’en surfe via motoren, tilslutte CDP-klienter, sende anmodninger fra operatørens Cloudflare-konto og bruge betalt CPU-tid og Dynamic Workers. Kodearkivet instruerer operatører i straks at beskytte URL’en og forklarer, hvordan Access aktiveres for hele kontoen før udrulning, så man undgår en periode, hvor den er offentligt tilgængelig.
Eksperimentel status og bidragsproces
Kitesurf er fortsat eksperimentel og under intensiv udvikling. Kodearkivet beskriver den som et CDP-slutpunkt snarere end en komplet Chrome-implementering, og nogle funktioner i Chrome DevTools understøttes stadig ikke. Cloudflare prioriterer kompatibilitet, pålidelighed og effektivitet.
Ved lanceringen i august sagde Cloudflare, at Kitesurf endnu ikke var egnet til video, WebGL, handshakes ved botudfordringer, der kræver ægte TLS-fingeraftryk, eller lange godkendte sessioner, som afhænger af vedvarende tilstand. Disse begrænsninger viser, hvilke kompatibilitetskontroller der stadig er vigtige for agentarbejdsbelastninger, selv når en lettere browsers ressourceforbrug er attraktivt.
Bidragsprocessen er tilrettelagt med henblik på dette løbende arbejde. Cloudflare beder potentielle bidragydere om at oprette en sag med en minimal reproduktion eller en foreslået tilgang og få en vedligeholder til at godkende bidraget, før de indsender en pull-anmodning. Afgrænsede ændringer med tests og et klart defineret omfang foretrækkes, men reproducerbare gengivelsesfejl, automatiseringsarbejdsgange, der fejler, og rettelser af dokumentation er også velkomne.
For udviklere er afvejningen direkte kontrol over browserstakken til gengæld for selv at sikre udrulningen og forholde sig til en motor, hvis kompatibilitet med Chrome og webplatformen stadig er ufuldstændig.












