एआई मॉडल और प्लेटफ़ॉर्म
AI एजेंटों के लिए Kitesurf ब्राउज़र इंजन का सोर्स कोड सार्वजनिक किया Cloudflare ने
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
मुख्य बिंदुKitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript…
और देखें
- Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript for AI agents.
- Self-hosting shifts security to operators because the engine ships without authentication and exposes a public URL.
- Kitesurf remains experimental with incomplete Chrome compatibility despite its efficiency gains for agent workloads.
Cloudflare ने 13 नवंबर 2026 को घोषणा की कि Kitesurf, AI एजेंटों के लिए उसका प्रायोगिक ब्राउज़र इंजन, अब Apache 2.0 लाइसेंस के तहत ओपन सोर्स के रूप में उपलब्ध है। डेवलपर कोड का निरीक्षण और उसमें संशोधन कर सकते हैं, इसे स्थानीय रूप से चला सकते हैं या Cloudflare Workers पर अपना इंस्टेंस तैनात कर सकते हैं।
सार्वजनिक रिपॉज़िटरी डेवलपरों को केवल इसकी प्रबंधित Browser Run API पर निर्भर रहने के बजाय अपने Cloudflare खातों में इंजन चलाने और उसमें बदलाव करने का विकल्प देती है। Cloudflare ने 6 अगस्त, 2026 को Kitesurf पेश करते समय इस कदम का वादा किया था। उसने 28 सितंबर, 2026 के अपडेट में भी यह वादा दोहराया था; उस अपडेट में WebMCP सपोर्ट जोड़ा गया, ब्राउज़र API और Browser Run का दायरा बढ़ाया गया तथा टर्मिनल रेंडरिंग पेश की गई।
एजेंटों को ध्यान में रखकर बनाया गया Kitesurf
Kitesurf, Chrome या ब्राउज़र कंटेनर के बिना, HTML और CSS को रेंडर किए गए पेजों में बदलता है, पेज का JavaScript चलाता है और स्क्रीनशॉट बनाता है। यह Chrome DevTools Protocol (CDP) एंडपॉइंट उपलब्ध कराता है—यह वह नियंत्रण इंटरफ़ेस है जिसका इस्तेमाल Chrome DevTools और इसके अनुकूल ऑटोमेशन सॉफ़्टवेयर करते हैं। इससे Puppeteer क्लाइंट और AI एजेंट हार्नेस इससे जुड़ सकते हैं।
आंतरिक रूप से, Engine ब्राउज़र सत्रों और क्लाइंट कनेक्शनों का समन्वय करता है, PageScript पेज और उसके JavaScript को चलाता है, जबकि PageRenderer दृश्य परिणाम तैयार करता है। Cloudflare का Developer Platform, WebAssembly में कंपाइल किए गए Rust घटकों के साथ मिलकर काम करता है: Blitz HTML पार्सिंग, DOM, लेआउट और पेंटिंग उपलब्ध कराता है; Stylo CSS को संभालता है; Linebender लाइब्रेरी टेक्स्ट और 2D ग्राफ़िक्स का काम करती हैं; और Krilla PDF आउटपुट तैयार करता है। जब पेज का कोड Dynamic Workers में नहीं चल पाता, तब Boa WebAssembly के भीतर वैकल्पिक JavaScript रनटाइम उपलब्ध कराता है।
Cloudflare के अनुसार, उसके डिज़ाइन का लक्ष्य एजेंटों को उनकी ज़रूरत के मुताबिक वेब तक पहुँच देना है, जबकि पूरी Chromium ब्राउज़र की तुलना में CPU और मेमोरी का कम इस्तेमाल हो। साथ ही, Workers नेटवर्क पर माँग के अनुसार क्षमता बढ़ाई जा सकती है। मूल आर्किटेक्चर में हर पेज लोड को अविश्वसनीय इनपुट माना जाता है और घटकों को उनकी ज़रूरत के संसाधनों के आधार पर अलग-अलग रखा जाता है। एक समर्पित SandboxOutbound वर्कर बाहरी स्रोतों से डेटा लाने के सभी अनुरोध संभालता है, नेटवर्क नीतियों को लागू करता है और हर पेज की कुकीज़ को अलग रखता है; अन्य घटक सीधे नेटवर्क तक नहीं पहुँच सकते।
इस डिज़ाइन का एक और हिस्सा स्टेटलेस होना है। 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 Paid प्लान ज़रूरी है, क्योंकि Dynamic Workers पेजों और रेंडरर के लिए इस्तेमाल होने वाले पृथक वर्कर बनाते हैं। स्थानीय स्तर पर परीक्षण करने के बाद, ऑपरेटर Browser Run की प्रबंधित API के विकल्प के रूप में अपने खाते में इंजन तैनात कर सकते हैं।
इंजन को स्वयं होस्ट करने पर सुरक्षा की एक अहम ज़िम्मेदारी भी ऑपरेटर पर आ जाती है। इंजन में अपना कोई प्रमाणीकरण तंत्र नहीं है और उसका workers.dev पता डिफ़ॉल्ट रूप से सार्वजनिक होता है। Cloudflare Access या प्रमाणीकरण की किसी अन्य परत के बिना, URL जानने वाला कोई भी व्यक्ति इंजन के ज़रिए वेब ब्राउज़ कर सकता है, CDP क्लाइंट जोड़ सकता है, ऑपरेटर के Cloudflare खाते से अनुरोध भेज सकता है और भुगतान वाले CPU समय तथा Dynamic Workers का इस्तेमाल कर सकता है। रिपॉज़िटरी ऑपरेटरों को URL की तुरंत सुरक्षा करने का निर्देश देती है और बताती है कि सार्वजनिक रूप से उपलब्ध रहने की अवधि से बचने के लिए तैनाती से पहले पूरे खाते में Access कैसे चालू करें।
प्रायोगिक स्थिति और योगदान की प्रक्रिया
Kitesurf अभी भी प्रायोगिक है और इस पर तेज़ी से काम चल रहा है। रिपॉज़िटरी इसे Chrome के पूर्ण कार्यान्वयन के बजाय CDP एंडपॉइंट बताती है; Chrome DevTools की कुछ सुविधाएँ अभी समर्थित नहीं हैं। Cloudflare की प्राथमिकताएँ अनुकूलता, विश्वसनीयता और दक्षता हैं।
अगस्त में लॉन्च के समय Cloudflare ने कहा था कि Kitesurf अभी वीडियो, WebGL, TLS के वास्तविक फ़िंगरप्रिंट की ज़रूरत वाले बॉट-चुनौती हैंडशेक या स्थायी स्थिति पर निर्भर लंबे प्रमाणित सत्रों के लिए उपयुक्त नहीं है। ये सीमाएँ दिखाती हैं कि एजेंट के वर्कलोड के लिए अनुकूलता की जाँच अब भी क्यों ज़रूरी है, भले ही हल्के ब्राउज़र का संसाधन इस्तेमाल आकर्षक हो।
योगदान की प्रक्रिया इस जारी काम को ध्यान में रखकर बनाई गई है। Cloudflare संभावित योगदानकर्ताओं से कहता है कि वे न्यूनतम उदाहरण के साथ कोई समस्या दर्ज करें या अपना प्रस्तावित तरीका बताएँ और पुल रिक्वेस्ट भेजने से पहले अनुरक्षकों की अनुशंसा प्राप्त करें। परीक्षणों और स्पष्ट दायरे वाले केंद्रित बदलावों को प्राथमिकता दी जाती है, हालाँकि दोबारा उत्पन्न की जा सकने वाली रेंडरिंग समस्याएँ, विफल ऑटोमेशन वर्कफ़्लो और दस्तावेज़ीकरण में सुधार के सुझाव भी स्वागत योग्य हैं।
डेवलपरों के लिए इसका मतलब है कि ब्राउज़र स्टैक पर सीधा नियंत्रण मिलता है, लेकिन तैनाती को सुरक्षित रखने की ज़िम्मेदारी उन्हें खुद उठानी होगी और ऐसे इंजन के साथ काम करना होगा जिसकी Chrome तथा वेब प्लेटफ़ॉर्म के साथ अनुकूलता अभी अधूरी है।
