Cloudflare rende open source il motore browser Kitesurf per gli agenti IA

Il 13 novembre 2026, Cloudflare ha annunciato che Kitesurf, il suo motore browser sperimentale per agenti IA, è ora disponibile come open source con licenza Apache 2.0. Gli sviluppatori possono esaminare e modificare il codice, eseguirlo in locale oppure distribuire una propria istanza su Cloudflare Workers.

Il repository pubblico offre agli sviluppatori la possibilità di utilizzare e modificare il motore nei propri account Cloudflare, invece di affidarsi esclusivamente alle API gestite di Browser Run. Cloudflare aveva promesso questo passaggio quando ha presentato Kitesurf il 6 agosto 2026 e, di nuovo, in un aggiornamento del 28 settembre 2026 che ha aggiunto il supporto a WebMCP, ampliato la copertura delle API del browser e di Browser Run e introdotto il rendering del terminale.

Il design di Kitesurf, pensato per gli agenti

Kitesurf trasforma HTML e CSS in pagine renderizzate, esegue il JavaScript delle pagine e produce screenshot senza Chrome né un container browser. Espone un endpoint Chrome DevTools Protocol (CDP), l’interfaccia di controllo utilizzata da Chrome DevTools e dai software di automazione compatibili, a cui possono collegarsi i client Puppeteer e gli ambienti di esecuzione degli agenti IA.

Al suo interno, Engine coordina le sessioni browser e le connessioni dei client, PageScript esegue la pagina e il relativo JavaScript, mentre PageRenderer produce il risultato visivo. La Developer Platform di Cloudflare si combina con componenti Rust compilati in WebAssembly: Blitz si occupa dell’analisi HTML, del DOM, del layout e del disegno; Stylo gestisce i CSS; le librerie Linebender si occupano di testo e grafica 2D; Krilla genera l’output PDF. Boa fornisce un ambiente di esecuzione JavaScript di riserva all’interno di WebAssembly quando il codice della pagina non può essere eseguito in Dynamic Workers.

Cloudflare afferma che l’obiettivo del progetto è offrire agli agenti l’accesso al web di cui hanno bisogno consumando meno CPU e memoria rispetto a un browser Chromium completo, con la possibilità di scalare su richiesta attraverso la rete Workers. L’architettura originale considera ogni caricamento di pagina come input non attendibile e isola i componenti in base alle risorse di cui necessitano. Un worker dedicato, SandboxOutbound, gestisce tutte le richieste verso l’esterno, applica le policy di rete e mantiene separati i cookie di ogni pagina; gli altri componenti non possono accedere direttamente alla rete.

L’assenza di stato è un altro elemento di questo progetto. Engine conserva lo stato della sessione, mentre gli altri componenti, ove possibile, sono sacrificabili, così da consentire alla capacità di adeguarsi ai picchi di attività degli agenti. PageRenderer non conserva alcuno stato persistente delle pagine, perciò Engine può sostituirlo dopo una richiesta di rendering non riuscita o bloccata.

Requisiti e sicurezza per l’hosting autonomo

Per lo sviluppo locale servono Bazelisk, Node.js 22 o versioni successive e pnpm 9.15.4. Il comando di sviluppo compila i moduli WebAssembly e i bundle della pagina e del renderer, quindi avvia un motore locale su 127.0.0.1:8787. La compilazione iniziale compila il core Rust e le dipendenze incluse nel repository; quelle successive riutilizzano la cache di Bazel. Gli sviluppatori possono quindi esaminare le pagine tramite Chrome DevTools oppure collegare Puppeteer e altri client CDP.

La distribuzione su Cloudflare richiede un piano Workers a pagamento, poiché Dynamic Workers crea i worker isolati utilizzati per le pagine e i renderer. Dopo aver effettuato i test in locale, gli operatori possono distribuire il motore nel proprio account, come alternativa alle API gestite di Browser Run.

L’hosting autonomo comporta anche una significativa responsabilità in materia di sicurezza. Il motore non dispone di un sistema di autenticazione proprio e, per impostazione predefinita, il suo indirizzo workers.dev è pubblico. Senza Cloudflare Access o un altro livello di autenticazione, chiunque disponga dell’URL potrebbe navigare tramite il motore, collegare client CDP, inviare richieste dall’account Cloudflare dell’operatore e consumare CPU a pagamento e Dynamic Workers. Il repository raccomanda agli operatori di proteggere subito l’URL e spiega come attivare Access sull’intero account prima della distribuzione, così da evitare che l’indirizzo rimanga temporaneamente esposto al pubblico.

Stato sperimentale e procedura per contribuire

Kitesurf è ancora sperimentale e in pieno sviluppo. Il repository lo descrive come un endpoint CDP, non come un’implementazione completa di Chrome, e alcune funzionalità di Chrome DevTools non sono ancora supportate. Cloudflare sta dando priorità a compatibilità, affidabilità ed efficienza.

Al momento del lancio, in agosto, Cloudflare ha dichiarato che Kitesurf non era ancora adatto ai video, a WebGL, alle procedure di handshake delle sfide anti-bot che richiedono impronte TLS reali o alle sessioni autenticate prolungate che dipendono da uno stato persistente. Queste limitazioni mostrano quali verifiche di compatibilità restano importanti per i carichi di lavoro degli agenti, anche quando il minore consumo di risorse di un browser più leggero è un vantaggio.

La procedura per contribuire è strutturata in funzione di questo lavoro ancora in corso. Cloudflare chiede a chi intende contribuire di aprire una segnalazione con una riproduzione minima del problema o un approccio proposto e di ottenere l’avallo di un maintainer prima di inviare una pull request. Sono preferite modifiche mirate, corredate di test e con un ambito ben definito; sono comunque benvenute anche segnalazioni di bug di rendering riproducibili, problemi nei flussi di automazione e correzioni alla documentazione.

Per gli sviluppatori, il compromesso consiste nell’ottenere il controllo diretto dello stack del browser, assumendosi in cambio la responsabilità di proteggere la propria distribuzione e di adattarsi a un motore la cui compatibilità con Chrome e con la piattaforma web è ancora incompleta.