Cloudflare ha reso open source Kitesurf, il suo motore browser per agenti di intelligenza artificiale, su GitHub con licenza Apache 2.0. Gli sviluppatori possono esaminarlo, eseguirlo in locale, modificarlo e distribuire una propria istanza su Cloudflare Workers.
Un browser senza container browser
Kitesurf funziona interamente su Cloudflare Workers: analizza l’HTML, applica i CSS, esegue il JavaScript delle pagine e genera screenshot senza ricorrere a un container browser. Implementa inoltre Chrome DevTools Protocol (CDP), quindi può connettersi a strumenti compatibili come Puppeteer.
Cloudflare lo propone come un’alternativa leggera per gli agenti che devono caricare siti, eseguire il codice delle pagine e interagire con esse. L’azienda afferma che punta a usare meno CPU e memoria rispetto a un browser completo come Chromium, oltre a scalare su richiesta attraverso la rete globale di Workers. Nell’annuncio open source non pubblica nuove misurazioni delle prestazioni.
Il motore si integra con Browser Run, le API gestite di Cloudflare, ma il repository consente a ogni team di eseguire una propria istanza. Ad agosto, quando ha presentato Kitesurf, l’azienda ha dichiarato che il servizio era disponibile gratuitamente durante la beta e che, nelle attività tipiche degli agenti — come acquisire screenshot ed estrarre HTML — consumava da tre a sette volte meno CPU e memoria di Chromium. Il confronto si riferisce all’annuncio iniziale.
Dalla beta al repository pubblico
Cloudflare ha presentato Kitesurf ad agosto come un browser stateless, scalabile e progettato innanzitutto per gli agenti. A settembre ha aggiunto il supporto a WebMCP e nuove API, oltre a miglioramenti della compatibilità. All’epoca l’azienda aveva annunciato l’intenzione di consentire agli sviluppatori di eseguire il motore nei propri account; ora ha pubblicato il repository con licenza Apache 2.0.
L’apertura consente di consultare il codice, apportare modifiche e distribuire istanze proprie, ma non trasforma il progetto in un browser finito. Cloudflare lo descrive come sperimentale e in intenso sviluppo. La documentazione segnala che il team sta lavorando alla compatibilità con gli standard web, alla fedeltà del rendering e alle prestazioni; il blog indica anche l’affidabilità tra gli obiettivi.
Secondo la pagina consultata, il repository ha raccolto 892 stelle e 35 fork su GitHub. Questi dati descrivono l’attività visibile del progetto, non una valutazione del suo grado di maturità o della compatibilità con siti specifici.
Rust, WebAssembly e tre componenti principali
L’implementazione combina la piattaforma di sviluppo di Cloudflare con progetti Rust compilati in WebAssembly. Blitz si occupa dell’analisi HTML, del DOM, del layout e del rendering; Stylo elabora i CSS, la cascata e gli stili calcolati. Boa esegue JavaScript in WebAssembly come ultima risorsa quando non è possibile usare JavaScript in Dynamic Workers.
Per il testo e la grafica 2D, Kitesurf utilizza librerie di Linebender; Krilla genera l’output PDF. Questi progetti mantengono le proprie licenze e il file NOTICE del repository raccoglie gli avvisi relativi a terze parti. Il progetto principale è rilasciato con licenza Apache 2.0, ma ciò non significa che tutti i componenti inclusi abbiano la stessa licenza.
Al livello del motore, Engine, PageScript e PageRenderer ne costituiscono i tre componenti principali. Engine gestisce le sessioni del browser e le connessioni dei client; PageScript esegue la pagina e il relativo JavaScript; PageRenderer disegna il risultato. Il repository distribuisce questi componenti e altri pacchetti — come il core Rust, i livelli DOM e l’interfaccia terminale — in cartelle separate.
Eseguirlo in locale e collegarlo a Puppeteer
Per provare Kitesurf in locale, Cloudflare indica di soddisfare prima i requisiti di compilazione, clonare il repository e installare le dipendenze. In seguito, pnpm run dev compila il motore e avvia Wrangler. La prima compilazione richiede più tempo perché compila il core Rust e le sue dipendenze; quelle successive riutilizzano la cache.
Per impostazione predefinita, il server locale è in ascolto su 127.0.0.1:8787. Da Chrome DevTools è possibile aprire una pagina per ispezionarla oppure un client può connettersi all’endpoint CDP. GitHub documenta anche un controllo dello stato all’indirizzo /health e consente di cambiare porta tramite la variabile KITESURF_PORT se quella predefinita è già occupata.
Puppeteer si connette tramite un WebSocket CDP. Una volta stabilita la connessione, il client può aprire una pagina, navigare verso un indirizzo e richiedere uno screenshot. Il supporto a CDP non equivale a un’implementazione completa di Chrome: il repository avverte che alcune funzionalità di Chrome DevTools non sono ancora disponibili.
La documentazione su GitHub specifica i requisiti di compilazione: Bazelisk installato come bazel, Node.js 22 o versioni successive e pnpm 9.15.4, la versione fissata dal repository. Su macOS è necessario GNU tar. Rust tramite rustup serve solo per modificare le patch delle dipendenze vendorizzate. Bazel scarica autonomamente le versioni fissate di Bazel, Rust, wasm-bindgen e Binaryen.
La distribuzione richiede di proteggere l’istanza
Per distribuire Kitesurf in un proprio account, eseguire pnpm run deploy dalla radice del repository. L’operazione richiede un piano Workers Paid: il motore utilizza Dynamic Workers per creare istanze isolate destinate alle pagine. La distribuzione compila il motore con Bazel e lo carica tramite Wrangler.
L’avvertenza più importante riguarda la sicurezza operativa: Kitesurf non include l’autenticazione. Cloudflare consiglia di proteggere l’URL con Cloudflare Access o un altro livello di autenticazione. L’indirizzo workers.dev è pubblico per impostazione predefinita e segue uno schema prevedibile: kitesurf.<subdominio>.workers.dev.
Senza protezione, chiunque conosca l’indirizzo può aprire DevTools e navigare tramite il motore, connettersi con Puppeteer o altri client CDP, inviare richieste in uscita dall’account Cloudflare e consumare CPU e Dynamic Workers addebitati a quell’account. Inoltre, tra la pubblicazione del Worker e l’attivazione di Access può esserci un intervallo in cui è pubblico; la documentazione consiglia di abilitare Access per tutti i Worker dell’account prima della distribuzione, per evitarlo.
Access influisce anche sulle connessioni automatizzate. Per consentire a Puppeteer di connettersi attraverso questo livello, la documentazione indica di creare un token di servizio, autorizzarlo con una policy Service Auth e inviarne le intestazioni nella connessione WebSocket. Cloudflare avverte che il token deve rimanere segreto, perché concede lo stesso accesso di un utente autenticato.
Contributi con modifiche circoscritte
Cloudflare invita a contribuire, ma avverte che la capacità di revisione è limitata. Chiede di leggere le linee guida, aprire prima una issue e ottenere l’approvazione di una persona che mantiene il progetto prima di inviare una pull request. Il team ritiene più facili da esaminare le correzioni mirate, corredate da test, prove chiare e un ambito ben definito.
Non è necessario contribuire solo con codice: l’azienda propone anche di fornire una pagina minima che riproduca un problema di rendering, un flusso di automazione che non funziona o una correzione chiara della documentazione. Per seguire il lavoro, rimanda a Web Platform Tests e ai benchmark, oltre che al sito web e al changelog ufficiali. Compatibilità, affidabilità e prestazioni restano le aree di lavoro dichiarate.
In questa pubblicazione Cloudflare non annuncia una data per l’uscita dalla fase sperimentale. Per ora, Kitesurf è disponibile su GitHub per chi vuole provarlo, modificarlo o distribuirlo, a condizione di configurare l’autenticazione prima di esporre il proprio Worker.
Fonti: Cloudflare Blog, Cloudflare Docs, GitHub, Cloudflare Docs
