Cloudflare ha abierto el código de Kitesurf, su motor de navegador para agentes de inteligencia artificial, en GitHub bajo la licencia Apache 2.0. Los desarrolladores pueden inspeccionarlo, ejecutarlo en local, modificarlo y desplegar una instancia propia sobre Cloudflare Workers.
Un navegador sin contenedor de navegador
Kitesurf funciona íntegramente sobre Cloudflare Workers: analiza HTML, aplica CSS, ejecuta JavaScript de las páginas y genera capturas de pantalla sin recurrir a un contenedor de navegador. También implementa Chrome DevTools Protocol (CDP), por lo que puede conectarse a herramientas compatibles como Puppeteer.
Cloudflare lo plantea como una alternativa ligera para agentes que necesitan cargar sitios, ejecutar código de página e interactuar con ellos. La empresa afirma que busca usar menos CPU y memoria que un navegador completo como Chromium, además de escalar bajo demanda a través de su red global de Workers. No publica en el anuncio de código abierto una nueva medición de rendimiento.
El motor se integra con Browser Run, las API gestionadas de Cloudflare, pero el repositorio permite que cada equipo ejecute su propia instancia. En agosto, cuando presentó Kitesurf, la compañía dijo que el servicio estaba disponible gratis durante la beta y que, en tareas habituales de agentes —como capturar pantallas y extraer HTML—, consumía entre tres y siete veces menos CPU y memoria que Chromium. Esa comparación corresponde al anuncio inicial.
De la beta al repositorio público
Cloudflare presentó Kitesurf en agosto como un navegador sin estado, escalable y diseñado primero para agentes. En septiembre añadió compatibilidad con WebMCP y nuevas API, además de mejoras de compatibilidad. La compañía había anunciado entonces su intención de permitir que los desarrolladores ejecutaran el motor en sus propias cuentas; ahora ha publicado el repositorio con licencia Apache 2.0.
La apertura habilita lectura, cambios y despliegues propios, pero no convierte el proyecto en un navegador terminado. Cloudflare lo describe como experimental y bajo desarrollo intenso. La documentación señala que el equipo trabaja en compatibilidad con estándares web, fidelidad de renderizado y rendimiento; el blog también menciona fiabilidad como objetivo.
El repositorio acumula 892 estrellas y 35 forks en GitHub, según la página consultada. Esos datos describen la actividad visible del proyecto y no una evaluación de su madurez ni de su compatibilidad con sitios concretos.
Rust, WebAssembly y tres piezas principales
La implementación combina la plataforma de desarrollo de Cloudflare con proyectos de Rust compilados a WebAssembly. Blitz se ocupa del análisis HTML, el DOM, el diseño y la pintura; Stylo procesa CSS, su cascada y los estilos calculados. Boa ejecuta JavaScript en WebAssembly como último recurso cuando no es posible usar JavaScript en Dynamic Workers.
Para texto y gráficos 2D, Kitesurf utiliza bibliotecas de Linebender; Krilla genera salida PDF. Esos proyectos conservan sus propias licencias, y el archivo NOTICE del repositorio reúne los avisos de terceros. La licencia del proyecto principal es Apache 2.0, pero los componentes incluidos no pasan por ello a tener todos la misma licencia.
En el nivel del motor, Engine, PageScript y PageRenderer forman sus tres partes principales. Engine administra las sesiones del navegador y las conexiones de clientes; PageScript ejecuta la página y su JavaScript; PageRenderer dibuja el resultado. El repositorio distribuye estos componentes y otros paquetes —como el núcleo Rust, las capas DOM y la interfaz de terminal— en carpetas separadas.
Ejecutarlo en local y conectarlo con Puppeteer
Para probar Kitesurf en local, Cloudflare indica que hay que cumplir primero los requisitos de compilación, clonar el repositorio e instalar las dependencias. Después, pnpm run dev construye el motor e inicia Wrangler. La primera compilación tarda más porque compila el núcleo Rust y sus dependencias; las siguientes reutilizan la caché.
El servidor local escucha por defecto en 127.0.0.1:8787. Desde Chrome DevTools se puede abrir una página para inspeccionarla, o un cliente puede conectarse al endpoint CDP. GitHub documenta también una comprobación de estado en /health y permite cambiar el puerto mediante la variable KITESURF_PORT si el predeterminado ya está ocupado.
Puppeteer se conecta mediante un WebSocket CDP. Una vez conectado, el cliente puede abrir una página, navegar a una dirección y solicitar una captura de pantalla. La compatibilidad con CDP no equivale a una implementación completa de Chrome: el repositorio advierte que algunas funciones de Chrome DevTools todavía no funcionan.
La documentación de GitHub detalla requisitos para compilar: Bazelisk instalado como bazel, Node.js 22 o posterior y pnpm 9.15.4, versión fijada por el repositorio. En macOS hace falta GNU tar. Rust mediante rustup solo se necesita para editar los parches de dependencias vendorizadas. Bazel descarga por su cuenta las versiones fijadas de Bazel, Rust, wasm-bindgen y Binaryen.
El despliegue exige proteger la instancia
Para desplegar Kitesurf en una cuenta propia se ejecuta pnpm run deploy desde la raíz del repositorio. La operación necesita un plan Workers Paid: el motor usa Dynamic Workers para crear instancias aisladas destinadas a las páginas. El despliegue construye el motor con Bazel y lo sube mediante Wrangler.
La advertencia más importante es de seguridad operativa: Kitesurf no incorpora autenticación. Cloudflare recomienda proteger la URL con Cloudflare Access u otra capa de autenticación. La dirección workers.dev es pública por defecto y sigue un patrón predecible: kitesurf.<subdominio>.workers.dev.
Sin protección, cualquiera que conozca la dirección puede abrir DevTools y navegar a través del motor, conectarse con Puppeteer u otros clientes CDP, emitir solicitudes salientes desde la cuenta de Cloudflare y consumir CPU y Dynamic Workers facturados a esa cuenta. Además, entre la publicación del Worker y la activación de Access puede existir un intervalo público; la documentación recomienda habilitar Access para todos los Workers de la cuenta antes del despliegue para evitarlo.
Access también afecta a las conexiones automatizadas. Para que Puppeteer se conecte a través de esa capa, la documentación indica crear un token de servicio, autorizarlo con una política Service Auth y enviar sus cabeceras en la conexión WebSocket. Cloudflare advierte que el token debe mantenerse secreto porque concede el mismo acceso que un usuario autenticado.
Contribuciones con cambios acotados
Cloudflare invita a enviar contribuciones, pero avisa de que la capacidad de revisión es limitada. Pide leer las pautas, abrir primero un issue y conseguir el aval de una persona mantenedora antes de presentar un pull request. El equipo considera más fáciles de revisar los arreglos enfocados, con pruebas, evidencias claras y un alcance definido.
No todo tiene que ser código: la compañía propone también aportar una página mínima que reproduzca un fallo de renderizado, un flujo de automatización que falle o una corrección clara de documentación. Para seguir el trabajo, remite a Web Platform Tests y los benchmarks, además de la web y el changelog oficiales. La compatibilidad, la fiabilidad y el rendimiento siguen siendo las áreas de trabajo declaradas.
Cloudflare no anuncia en esta publicación una fecha para salir de la fase experimental. Por ahora, Kitesurf está disponible en GitHub para quien quiera probarlo, modificarlo o desplegarlo, siempre con la autenticación configurada antes de exponer su Worker.
Fuentes: Cloudflare Blog, Cloudflare Docs, GitHub, Cloudflare Docs
