Cloudflare maakt Kitesurf-browserengine voor AI-agenten opensource

Cloudflare kondigde op 13 november 2026 aan dat Kitesurf, de experimentele browserengine voor AI-agenten, nu als opensource beschikbaar is onder de Apache 2.0-licentie. Ontwikkelaars kunnen de code bekijken en aanpassen, de engine lokaal uitvoeren of hun eigen instantie implementeren op Cloudflare Workers.

De openbare repository biedt ontwikkelaars de mogelijkheid om de engine in hun eigen Cloudflare-accounts te gebruiken en aan te passen, in plaats van uitsluitend te vertrouwen op de beheerde Browser Run-API’s. Cloudflare had deze stap al toegezegd toen het bedrijf Kitesurf op 6 augustus 2026 introduceerde, en herhaalde die toezegging in een update van 28 september 2026, waarin ondersteuning voor WebMCP werd toegevoegd, de ondersteuning voor browser-API’s en Browser Run werd uitgebreid en terminalweergave werd geïntroduceerd.

Achter het agentgerichte ontwerp van Kitesurf

Kitesurf zet HTML en CSS om in weergegeven pagina’s, voert JavaScript op de pagina uit en maakt schermafbeeldingen, zonder Chrome of een browsercontainer. De engine biedt een Chrome DevTools Protocol (CDP)-endpoint: de bedieningsinterface die wordt gebruikt door Chrome DevTools en compatibele automatiseringssoftware. Hierdoor kunnen Puppeteer-clients en omgevingen voor AI-agenten verbinding maken.

Intern coördineert de Engine browsersessies en clientverbindingen, voert PageScript de pagina en de bijbehorende JavaScript uit en genereert PageRenderer de visuele weergave. Het Developer Platform van Cloudflare wordt gecombineerd met in Rust geschreven componenten die naar WebAssembly zijn gecompileerd: Blitz verzorgt het parsen van HTML, de DOM, de lay-out en het tekenen; Stylo verwerkt CSS; bibliotheken van Linebender verzorgen tekst en 2D-graphics; en Krilla genereert PDF-uitvoer. Boa biedt binnen WebAssembly een alternatieve JavaScript-runtime wanneer de code van de pagina niet in Dynamic Workers kan worden uitgevoerd.

Cloudflare zegt dat het ontwerp agenten toegang tot het web moet bieden met minder CPU- en geheugengebruik dan een volledige Chromium-browser, terwijl de capaciteit op aanvraag kan worden opgeschaald over het Workers-netwerk. De oorspronkelijke architectuur behandelt elke paginalading als niet-vertrouwde invoer en isoleert componenten op basis van de resources die ze nodig hebben. Een afzonderlijke SandboxOutbound-worker verzorgt alle externe verzoeken, dwingt het netwerkbeleid af en houdt de cookies van elke pagina gescheiden; andere componenten hebben niet rechtstreeks toegang tot het netwerk.

Ook stateloosheid maakt deel uit van dat ontwerp. De Engine bewaart de sessiestatus, terwijl andere componenten waar mogelijk vervangbaar zijn. Zo kan de capaciteit worden afgestemd op pieken in de activiteit van agenten. PageRenderer bewaart geen blijvende paginastatus, zodat de Engine deze kan vervangen nadat een renderverzoek is mislukt of vastgelopen.

Vereisten en beveiliging voor zelfhosting

Voor lokale ontwikkeling zijn Bazelisk, Node.js 22 of hoger en pnpm 9.15.4 vereist. De ontwikkelopdracht bouwt de WebAssembly-modules en de bundels voor pagina’s en de renderer en start vervolgens een lokale engine op 127.0.0.1:8787. Bij de eerste build worden de Rust-kern en de meegeleverde afhankelijkheden gecompileerd; latere builds maken opnieuw gebruik van de cache van Bazel. Ontwikkelaars kunnen pagina’s daarna bekijken via Chrome DevTools of Puppeteer en andere CDP-clients koppelen.

Voor implementatie op Cloudflare is een Workers Paid-abonnement vereist, omdat Dynamic Workers de geïsoleerde workers aanmaken die voor pagina’s en renderers worden gebruikt. Na lokaal testen kunnen beheerders de engine in hun eigen account implementeren als alternatief voor de beheerde API’s van Browser Run.

Zelfhosting brengt ook een belangrijke beveiligingsverantwoordelijkheid met zich mee. De engine heeft geen eigen authenticatie en het workers.dev-adres is standaard openbaar. Zonder Cloudflare Access of een andere authenticatielaag kan iedereen met de URL via de engine browsen, CDP-clients verbinden, verzoeken versturen vanuit het Cloudflare-account van de beheerder en betaalde CPU-tijd en Dynamic Workers verbruiken. De repository draagt beheerders op de URL onmiddellijk te beveiligen en legt uit hoe ze Access voor het hele account kunnen inschakelen voordat ze de engine implementeren, om te voorkomen dat de URL tijdelijk openbaar is.

Experimentele status en bijdragen

Kitesurf is nog experimenteel en wordt volop ontwikkeld. De repository omschrijft het als een CDP-endpoint en niet als een volledige Chrome-implementatie; sommige functies van Chrome DevTools worden nog niet ondersteund. Cloudflare geeft prioriteit aan compatibiliteit, betrouwbaarheid en efficiëntie.

Bij de lancering in augustus zei Cloudflare dat Kitesurf nog niet geschikt was voor video, WebGL, handshakes bij botuitdagingen waarvoor echte TLS-fingerprints nodig zijn, of lange geauthenticeerde sessies die afhankelijk zijn van een blijvende status. Die beperkingen laten zien welke compatibiliteitscontroles nog steeds van belang zijn voor toepassingen met agenten, ook wanneer het lagere resourcegebruik van een lichtere browser aantrekkelijk is.

Het proces voor bijdragen is afgestemd op dit doorlopende ontwikkelwerk. Cloudflare vraagt potentiële bijdragers om een issue te openen met een minimale reproductie of voorgestelde aanpak en vooraf de steun van een maintainer te krijgen voordat ze een pull request indienen. Kleine, gerichte wijzigingen met tests en een duidelijk afgebakende reikwijdte hebben de voorkeur, maar reproduceerbare renderproblemen, mislukte automatiseringsworkflows en correcties van documentatie zijn ook welkom.

Voor ontwikkelaars betekent dit dat ze rechtstreeks controle krijgen over de browserstack, maar zelf de implementatie moeten beveiligen en rekening moeten houden met een engine die nog niet volledig compatibel is met Chrome en webplatformstandaarden.