Cloudflare відкрила вихідний код рушія браузера Kitesurf для ШІ-агентів

13 листопада 2026 року Cloudflare оголосила, що Kitesurf — експериментальний рушій браузера для ШІ-агентів — тепер доступний із відкритим вихідним кодом за ліцензією Apache 2.0. Розробники можуть переглядати й змінювати код, запускати його локально або розгортати власний екземпляр на Cloudflare Workers.

Загальнодоступний репозиторій дає розробникам змогу запускати й змінювати рушій у власних облікових записах Cloudflare, а не покладатися винятково на керовані API Browser Run. Cloudflare обіцяла зробити цей крок, коли представила Kitesurf 6 серпня 2026 року, а також у оновленні від 28 вересня 2026 року, яке додало підтримку WebMCP, розширило підтримку API браузера й Browser Run та запровадило рендеринг термінала.

Архітектура Kitesurf, орієнтована на агентів

Kitesurf перетворює HTML і CSS на відрендерені сторінки, виконує JavaScript сторінок і створює знімки екрана без Chrome чи контейнера браузера. Він надає кінцеву точку Chrome DevTools Protocol (CDP) — інтерфейс керування, який використовують Chrome DevTools і сумісне програмне забезпечення для автоматизації, — до якої можуть підключатися клієнти Puppeteer і середовища для ШІ-агентів.

Усередині рушій Engine координує сеанси браузера та підключення клієнтів, PageScript запускає сторінку та її JavaScript, а PageRenderer створює візуальне представлення. Платформа розробників Cloudflare поєднується з компонентами Rust, скомпільованими у WebAssembly: Blitz забезпечує розбір HTML, роботу з DOM, компонування та відтворення; Stylo відповідає за CSS; бібліотеки Linebender працюють із текстом і двовимірною графікою; а Krilla створює PDF-файли. Якщо код сторінки не може виконуватися в Dynamic Workers, Boa надає резервне середовище виконання JavaScript у WebAssembly.

За словами Cloudflare, мета проєкту — надати агентам потрібний доступ до вебу, використовуючи менше ресурсів CPU та пам’яті, ніж повноцінний браузер Chromium, і водночас масштабуватися на вимогу в мережі Workers. Початкова архітектура вважає кожне завантаження сторінки недовіреним введенням і ізолює компоненти відповідно до потрібних їм ресурсів. Усі зовнішні запити обробляє окремий воркер SandboxOutbound, який забезпечує дотримання мережевих політик і зберігає файли cookie кожної сторінки окремо; інші компоненти не можуть безпосередньо виходити в мережу.

Ще одна складова цієї архітектури — відсутність збереження стану. Engine зберігає стан сеансу, тоді як інші компоненти, де можливо, можна відкидати, завдяки чому ресурси масштабуються відповідно до сплесків активності агентів. PageRenderer не зберігає стан сторінки постійно, тому Engine може замінити його, якщо запит на рендеринг завершився помилкою або завис.

Вимоги до самостійного розгортання та безпека

Для локальної розробки потрібні Bazelisk, Node.js версії 22 або новішої та pnpm 9.15.4. Команда розробки збирає модулі WebAssembly, а також пакети сторінки й засобу рендерингу, після чого запускає локальний рушій за адресою 127.0.0.1:8787. Під час першої збірки компілюються ядро Rust і залежності, що входять до репозиторію, а в наступних збірках повторно використовується кеш Bazel. Після цього розробники можуть переглядати сторінки в Chrome DevTools або підключати Puppeteer та інші клієнти CDP.

Для розгортання на Cloudflare потрібен платний план Workers, оскільки Dynamic Workers створюють ізольовані воркери, які використовуються для сторінок і засобів рендерингу. Після локального тестування оператори можуть розгорнути рушій у власному обліковому записі як альтернативу керованим API Browser Run.

Самостійне розгортання також покладає на операторів важливу відповідальність за безпеку. Сам рушій не має засобів автентифікації, а його адреса workers.dev за замовчуванням загальнодоступна. Якщо не налаштувати Cloudflare Access чи інший рівень автентифікації, будь-хто, хто має URL-адресу, зможе переглядати вебсторінки через рушій, підключати клієнти CDP, надсилати запити від імені облікового запису Cloudflare оператора та витрачати платний процесорний час і ресурси Dynamic Workers. У репозиторії операторів закликають негайно захистити URL-адресу та пояснюють, як увімкнути Access для всього облікового запису ще до розгортання, щоб уникнути періоду відкритого доступу.

Експериментальний статус і процес участі в розробці

Kitesurf залишається експериментальним продуктом, який активно розробляють. У репозиторії його описано як кінцеву точку CDP, а не повноцінну реалізацію Chrome; деякі можливості Chrome DevTools поки не підтримуються. Cloudflare зосереджується на сумісності, надійності та ефективності.

Під час запуску в серпні Cloudflare повідомила, що Kitesurf іще не підходить для роботи з відео та WebGL, проходження перевірок ботів із рукостисканням, яке потребує справжніх TLS-відбитків, а також тривалих автентифікованих сеансів, що залежать від постійного збереження стану. Ці обмеження показують, які перевірки сумісності й надалі важливі для робочих навантажень агентів, навіть якщо легший браузер приваблює меншим споживанням ресурсів.

Процес участі в розробці організовано з огляду на цю роботу, що триває. Cloudflare просить потенційних учасників створити issue з мінімальним прикладом відтворення проблеми або запропонованим підходом і заручитися підтримкою супроводжувача проєкту, перш ніж надсилати pull request. Перевагу віддають точковим змінам із тестами та чітко визначеним обсягом, однак також вітаються помилки рендерингу, які можна відтворити, збої в робочих процесах автоматизації та виправлення документації.

Для розробників компроміс полягає в тому, що вони отримують безпосередній контроль над стеком браузера, але мають самостійно захищати розгортання й зважати на те, що сумісність рушія з Chrome і вебплатформою досі неповна.