This content is currently only available in Spanish. English translation is on the roadmap — in the meantime, here's the original.
Kitesurf ya es open source, pero sigue viviendo en casa de Cloudflare
Lo primero que hice al ver que Cloudflare había liberado Kitesurf fue abrir el README buscando una cosa: cómo se despliega. La respuesta está casi al principio. Para ejecutarlo en Cloudflare necesitas el plan Workers Paid, porque cada página se aísla en un Dynamic Worker.
Y ahí empezó mi pequeño debate interno.
Qué es Kitesurf
Kitesurf es un motor de navegador experimental pensado para agentes de IA, no para personas. Cloudflare lo presentó en agosto dentro de su servicio Browser Run y prometió abrir el código. Esta semana lo ha cumplido: el repositorio está en GitHub con licencia Apache 2.0.
No es un Chromium recortado. Está escrito en Rust y WebAssembly y se apoya en piezas abiertas que ya existían: Blitz para el HTML, el DOM y el layout, Stylo (el motor CSS que viene de Servo y Firefox) para los estilos, y Boa para ejecutar el JavaScript de las páginas dentro de WebAssembly. Por fuera expone un endpoint de Chrome DevTools Protocol, así que en teoría Puppeteer o Playwright pueden hablar con él. El propio README avisa de que es "un endpoint CDP, no una implementación completa de Chrome".
Según las cifras que Cloudflare dio en agosto, consume entre tres y siete veces menos CPU y memoria que Chromium en tareas típicas de agente como extraer HTML o hacer capturas, a cambio de ser algo más lento en tiempo total y de no renderizar al píxel. Son números del fabricante, con su propio banco de pruebas. No los he podido comprobar.
Mi lectura: código libre, casa ajena
Voy a mojarme: esto es open source de verdad, pero con domicilio fijo.
La licencia es impecable. Apache 2.0, dependencias con licencias permisivas o MPL, y un monorepo bien organizado que cualquiera puede leer, auditar y forkear. Eso tiene valor, y no poco. Ver cómo alguien encaja Stylo y Boa para montar un navegador sin interfaz es material de estudio de primera para quien, como yo, está aprendiendo cómo se construyen los sistemas que usan los agentes.
Pero el diseño está atado a Workers. Puedes desarrollarlo en local con wrangler dev, que es el entorno de pruebas de la propia Cloudflare, y para producción pasas por caja. Liberar el código no te libera del runtime.
El mejor argumento del otro lado es razonable: Cloudflare nunca prometió un navegador autoalojable, prometió el código, y lo ha dado. Además, las piezas de verdad interesantes (el layout, el CSS, el JavaScript en Wasm) son independientes de su plataforma, y nada impide que alguien las saque de ahí. Lo compro a medias. Que se pueda no significa que vaya a pasar, y un fork que tenga que reescribir la capa de ejecución entera ya es otro proyecto.
Lo que me llevo como técnico de sistemas
Hay una frase del README que subrayaría en fluorescente: no despliegues Kitesurf sin autenticación delante. El motor no trae autenticación propia, y las URL de workers.dev son públicas por defecto y siguen un patrón predecible. Traducido: si alguien lo prueba un viernes por la tarde y lo deja así, cualquiera puede navegar a través de su cuenta y gastarle recursos.
Me gusta que lo digan claro. Me preocupa lo de siempre: los avisos del README los lee quien ya iba a hacerlo bien. Cloudflare recomienda poner Cloudflare Access por delante, cosa sensata y, de paso, otro producto suyo.
Aun así, prefiero mil veces este escenario al de un navegador para agentes cerrado del todo. Con el código delante se puede ver qué hace con las cookies, cómo aísla cada página y qué partes del protocolo CDP faltan. Eso, para alguien que tiene que decidir si deja a un agente navegar desde su red, pesa más que cualquier benchmark.
Me quedo con una duda que no sé resolver todavía: ¿cuánto tardará alguien en sacar el núcleo de Kitesurf de Workers y hacerlo correr como un binario normal, y le dejará Cloudflare espacio para hacerlo?
