Cloudflare udostępnia jako open source silnik przeglądarki Kitesurf dla agentów AI

Cloudflare poinformowało 13 listopada 2026 r., że Kitesurf, eksperymentalny silnik przeglądarki dla agentów AI, jest już dostępny na licencji Apache 2.0 jako oprogramowanie open source. Deweloperzy mogą przeglądać i modyfikować kod, uruchamiać go lokalnie lub wdrażać własną instancję w Cloudflare Workers.

Publiczne repozytorium pozwala deweloperom uruchamiać silnik i wprowadzać w nim zmiany na własnych kontach Cloudflare, zamiast polegać wyłącznie na zarządzanych interfejsach API Browser Run. Cloudflare zapowiadało ten krok, gdy wprowadziło Kitesurf 6 sierpnia 2026 r., a następnie ponownie w aktualizacji z 28 września 2026 r., która dodała obsługę WebMCP, rozszerzyła obsługę interfejsu API przeglądarki i Browser Run oraz wprowadziła renderowanie terminala.

Projekt Kitesurf stworzony z myślą o agentach

Kitesurf przekształca HTML i CSS w wyrenderowane strony, wykonuje kod JavaScript strony i tworzy zrzuty ekranu bez użycia Chrome ani kontenera przeglądarki. Udostępnia punkt końcowy Chrome DevTools Protocol (CDP) — interfejs sterujący używany przez Chrome DevTools i zgodne oprogramowanie do automatyzacji — dzięki czemu mogą się z nim łączyć klienci Puppeteer i środowiska uruchomieniowe agentów AI.

Wewnątrz systemu Engine koordynuje sesje przeglądarki i połączenia klientów, PageScript uruchamia stronę i jej kod JavaScript, a PageRenderer tworzy obraz strony. Platforma deweloperska Cloudflare współpracuje z komponentami napisanymi w Rust i skompilowanymi do WebAssembly: Blitz odpowiada za parsowanie HTML, model DOM, układ i renderowanie; Stylo obsługuje CSS; biblioteki Linebender odpowiadają za tekst i grafikę 2D, a Krilla generuje pliki PDF. Boa zapewnia zapasowe środowisko uruchomieniowe JavaScript w WebAssembly, gdy kod strony nie może działać w Dynamic Workers.

Cloudflare twierdzi, że celem projektu jest zapewnienie agentom potrzebnego dostępu do internetu przy mniejszym zużyciu procesora i pamięci niż w przypadku pełnej przeglądarki Chromium, przy jednoczesnym skalowaniu na żądanie w całej sieci Workers. Pierwotna architektura traktuje każde wczytanie strony jako niezaufane dane wejściowe i izoluje komponenty stosownie do wymaganych przez nie zasobów. Wszystkie żądania do zewnętrznych zasobów obsługuje dedykowany proces roboczy SandboxOutbound, który egzekwuje zasady sieciowe i odseparowuje pliki cookie poszczególnych stron; pozostałe komponenty nie mogą bezpośrednio uzyskiwać dostępu do sieci.

Bezstanowość to kolejny element tej architektury. Engine zachowuje stan sesji, natomiast pozostałe komponenty są w miarę możliwości tymczasowe, co pozwala dostosowywać wydajność do nagłych wzrostów aktywności agentów. PageRenderer nie przechowuje trwałego stanu stron, dlatego Engine może go zastąpić po nieudanym lub zawieszonym żądaniu renderowania.

Wymagania i kwestie bezpieczeństwa związane z samodzielnym hostingiem

Do pracy lokalnej potrzebne są Bazelisk, Node.js w wersji 22 lub nowszej oraz pnpm 9.15.4. Polecenie deweloperskie buduje moduły WebAssembly oraz pakiety strony i renderera, a następnie uruchamia lokalny silnik pod adresem 127.0.0.1:8787. Pierwsza kompilacja obejmuje rdzeń napisany w Rust i dołączone zależności, natomiast kolejne korzystają z pamięci podręcznej Bazel. Następnie deweloperzy mogą przeglądać strony za pomocą Chrome DevTools albo podłączyć Puppeteer i innych klientów CDP.

Wdrożenie w Cloudflare wymaga płatnego planu Workers, ponieważ Dynamic Workers tworzy izolowane procesy robocze wykorzystywane do obsługi stron i rendererów. Po przetestowaniu silnika lokalnie operatorzy mogą wdrożyć go na własnym koncie jako alternatywę dla zarządzanych interfejsów API Browser Run.

Samodzielny hosting wiąże się również z przejęciem istotnej odpowiedzialności za bezpieczeństwo. Silnik nie ma własnego mechanizmu uwierzytelniania, a jego adres w domenie workers.dev jest domyślnie publiczny. Bez Cloudflare Access lub innej warstwy uwierzytelniania każdy, kto zna adres URL, może przeglądać strony za pośrednictwem silnika, łączyć klientów CDP, wysyłać żądania z konta Cloudflare operatora oraz zużywać płatny czas procesora i zasoby Dynamic Workers. Repozytorium zaleca natychmiastowe zabezpieczenie adresu URL i wyjaśnia, jak włączyć Access dla całego konta przed wdrożeniem, aby uniknąć okresu, w którym silnik byłby publicznie dostępny.

Status eksperymentalny i proces wnoszenia wkładu

Kitesurf pozostaje produktem eksperymentalnym, nad którym trwają intensywne prace. Repozytorium opisuje go jako punkt końcowy CDP, a nie kompletną implementację Chrome; niektóre funkcje Chrome DevTools nadal nie są obsługiwane. Cloudflare koncentruje się na zgodności, niezawodności i wydajności.

Podczas sierpniowej premiery Cloudflare informowało, że Kitesurf nie nadaje się jeszcze do obsługi wideo, WebGL, uzgadniania wyzwań antybotowych wymagających rzeczywistych odcisków TLS ani długotrwałych uwierzytelnionych sesji zależnych od trwałego stanu. Ograniczenia te pokazują, jakie kwestie zgodności nadal mają znaczenie w przypadku zadań wykonywanych przez agentów, nawet jeśli mniejsze zużycie zasobów przez lżejszą przeglądarkę jest atrakcyjne.

Proces wnoszenia wkładu jest zorganizowany wokół bieżących prac nad projektem. Cloudflare prosi potencjalnych współtwórców o zgłoszenie problemu wraz z minimalnym przykładem pozwalającym go odtworzyć lub proponowanym podejściem, a także o uzyskanie poparcia opiekuna projektu przed przesłaniem pull requesta. Preferowane są zmiany o jasno określonym zakresie, poparte testami, ale mile widziane są również możliwe do odtworzenia błędy renderowania, nieudane przepływy pracy automatyzacji i poprawki dokumentacji.

Dla deweloperów oznacza to bezpośrednią kontrolę nad stosem przeglądarki w zamian za konieczność samodzielnego zabezpieczenia wdrożenia i uwzględnienia faktu, że zgodność silnika z Chrome i platformą internetową pozostaje niepełna.