19 पॉइंट द्वारा GN⁺ 2026-01-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenWorkers एक open source runtime है जो V8-आधारित वातावरण में JavaScript चलाता है, जिससे edge computing को अपनी infrastructure पर लागू किया जा सकता है
  • यह KV storage, PostgreSQL, S3/R2-compatible storage, service bindings, environment variables और secrets को support करता है
  • fetch, ReadableStream, crypto.subtle जैसे प्रमुख Web API शामिल हैं, जिससे Cloudflare Workers के साथ उच्च compatibility बनी रहती है
  • V8 Isolate sandbox, cron scheduling, और Docker Compose-आधारित deployment के जरिए आसान self-hosting संभव है
  • लगभग 7 वर्षों में विकसित हुआ यह प्रोजेक्ट vendor lock-in के बिना JavaScript execution environment बनाने का लक्ष्य रखता है

OpenWorkers परिचय

  • OpenWorkers एक Rust में लिखा गया Cloudflare Workers-compatible runtime है, जो V8 Isolate का उपयोग करके JavaScript चलाता है
    • edge computing के फायदे अपनी server environment में भी लिए जा सकते हैं
    • open source होने के कारण इसे स्वतंत्र रूप से deploy और modify किया जा सकता है

मुख्य विशेषताएँ

  • Bindings फीचर के जरिए विभिन्न external resources के साथ integration
    • KV storage: get, put, delete, list support
    • PostgreSQL database integration
    • S3/R2-compatible storage support
    • service bindings, environment variables और secret management शामिल
  • Web API support
    • fetch, Request, Response, ReadableStream जैसे standard API उपलब्ध
    • crypto.subtle, TextEncoder/Decoder, Blob, setTimeout, AbortController शामिल

आर्किटेक्चर

  • सिस्टम nginx proxy, dashboard, API, log service, runner, PostgreSQL, NATS, scheduler आदि से मिलकर बना है
    • हर runner V8 Isolate के भीतर code चलाता है, और CPU 100ms, memory 128MB limits लागू होती हैं
    • 5~6-field cron syntax को support करने वाला built-in scheduler शामिल है
    • Cloudflare Workers के साथ syntax compatibility बनी रहती है

Self-hosting

  • deployment केवल एक PostgreSQL database और Docker Compose file से संभव है
    • git clone, .env configuration, और docker compose up command से इसे आसानी से चलाया जा सकता है
    • migration और token generation प्रक्रिया भी शामिल है

विकास पृष्ठभूमि

  • यह प्रोजेक्ट लगभग 7 साल की development process के बाद तैयार हुआ है
    • शुरुआत में vm2 के साथ JS sandboxing का प्रयोग किया गया, फिर Cloudflare Workers मॉडल से प्रेरित होकर यह आगे विकसित हुआ
    • Deno-core से गुजरते हुए अब इसे rusty_v8 पर फिर से लिखा गया है
  • लक्ष्य है Cloudflare Workers-स्तर का developer experience (DX) देना, साथ ही vendor lock-in हटाकर self-hosted server execution environment बनाना
  • भविष्य में execution history और replay feature के जरिए deterministic debugging जोड़ने की योजना है

1 टिप्पणियां

 
GN⁺ 2026-01-02
Hacker News की राय
  • edge computing की ताकत को अपनी infrastructure पर लाने का कॉन्सेप्ट दिलचस्प है
    लेकिन self-hosting कुछ हद तक edge computing की मूल भावना के उलट भी लगता है
    यह मॉडल Cloudflare जैसे बड़े vendor के लिए संभव है, जिनके दुनिया भर में 300 से ज़्यादा PoP (Point of Presence) हैं
    बेशक, छोटे और ज़्यादा ethical vendors को जोड़कर ऐसा मिलता-जुलता ढांचा बनाया जा सकता है, लेकिन इसमें काफ़ी ज़्यादा मेहनत और risk है

    • मुझे शक है कि edge model के फ़ायदे लेने के लिए सच में 300 PoP चाहिए भी या नहीं
      शायद प्रमुख क्षेत्रों में लगभग 10 ही काफ़ी हों
    • सोच रहा हूँ कि Cloudflare के एकाधिकार को तोड़ने के लिए क्या distributed host network के सहयोग वाला मॉडल संभव है
      लेकिन यह चिंता भी है कि उसे सुरक्षित और भरोसेमंद तरीके से coordinate करना कहीं बहुत मुश्किल न हो
  • sandbox solution की समस्या यह है कि इसमें यह मज़बूत गारंटी देनी पड़ती है कि code sandbox से बाहर नहीं निकल सकता
    इसे साबित करने के लिए अलग-अलग attack scenarios पर test results और विस्तार से documentation चाहिए
    लेकिन इस स्तर के दस्तावेज़ बहुत कम मिलते हैं, और वास्तव में भरोसेमंद उदाहरण ढूँढना मुश्किल है
    इसलिए मैं यह देखता हूँ कि क्या कोई ऐसा उदाहरण है जहाँ कोई बड़ी कंपनी इसे असली production environment में इस्तेमाल कर रही हो और security team उसकी maintenance कर रही हो

    • मैं भी सहमत हूँ। AI productivity बढ़ाता है, लेकिन high-security environment में “Claude की मदद से इसे rusty_v8 पर फिर से लिखा” जैसी बात उल्टा चिंता बढ़ाती है
    • Cloudflare Workers runtime सुरक्षित होने की एक वजह यह भी है कि वह V8 mainline के साथ synchronization बहुत आक्रामक तरीके से बनाए रखता है
      यहाँ तक कि कभी-कभी Chrome से पहले V8 release भी अपना लेता है
    • V8 isolate memory isolation देता है, और CPU (100ms) व memory (128MB) limits लगाता है
      हर worker अलग process के बजाय isolate में चलता है, इसलिए यह Cloudflare model जैसा है
      लेकिन जब पूरी तरह untrusted third-party code चलाना हो, तो container या VM की एक अतिरिक्त layer बेहतर रहती है
      यह sandboxing security से ज़्यादा resource isolation पर केंद्रित है
    • मुझे लगता है ऐसी परफेक्ट गारंटी माँगना अव्यावहारिक है
      “हमने verify कर लिया है और यह सुरक्षित है, हम पर भरोसा कीजिए” स्तर का security audit काफ़ी नहीं है
    • Cloudflare में sandbox security ज़रूरी है क्योंकि user code malicious हो सकता है,
      लेकिन self-hosting environment में तो वैसे भी system access मौजूद होता है, इसलिए sandbox escape की चिंता तुलनात्मक रूप से कम है
  • मुझे यह एक शानदार project लगता है
    अगर workerd open source है, तो क्या OpenWorkers की खासियत यह है कि वह पूरा environment देता है?
    runtime के स्तर पर क्या फ़र्क है, और आगे managed service की कोई योजना भी है या नहीं, यह जानना चाहूँगा

    • तीन मुख्य फ़र्क हैं
      1️⃣ workerd सिर्फ runtime देता है, जबकि OpenWorkers एक पूरा platform है जिसमें dashboard, API, scheduler, logs, bindings (KV, S3/R2, Postgres) तक शामिल हैं
      2️⃣ workerd C++ आधारित है, OpenWorkers Rust + rusty_v8 आधारित है, इसलिए यह ज़्यादा सरल है और hack करना आसान है
      3️⃣ dash.openworkers.com पर managed version पहले से मौजूद है, और free tier भी है
      लेकिन self-hosting को first-class citizen की तरह डिज़ाइन किया गया है
  • Cloudflare Workers की असली ताकत function-level billing है, लेकिन self-hosting में तो आख़िरकार hardware पहले से रखना ही पड़ेगा

    • अभी भी बहुत-सी कंपनियाँ अपने data center servers चलाती हैं
      हर चीज़ outsource करना ज़रूरी नहीं है, और ऐसे समान विकल्पों का होना अच्छी बात है
      इससे adoption barrier कम करने में मदद मिलती है
  • पहले मैंने deno_core को अलग करने पर काफ़ी काम किया था, इसलिए raw rusty_v8 पर जाना समझ में आता है
    deno_core में काफ़ी legacy code है, इसलिए उसमें बदलाव करने पर tests अक्सर टूट जाते थे

    • धन्यवाद! deno_core अब भी एक बढ़िया codebase है, इसलिए हम उसे openworkers-runtime-deno के रूप में बनाए हुए हैं
      लेकिन runtime के अंदरूनी हिस्सों पर और बारीक control के लिए हमने rusty_v8 चुना,
      और बाद में deno runtime में छूटी हुई सुविधाएँ फिर से जोड़ने की योजना है
  • अगर कोई project vendor lock-in कम करने में मदद करता है, तो मैं उसके पक्ष में हूँ
    उम्मीद है इससे cloud services पर pricing को ज़्यादा यथार्थवादी रखने का दबाव पड़ेगा
    अभी NAT जैसी बुनियादी चीज़ों पर भी बहुत ज़्यादा शुल्क लिया जाता है
    बेशक cloud सुविधाजनक है, लेकिन DIY की तुलना में ऊँची लागत समस्या है

    • Cloudflare Workers runtime पहले से ही open source है: cloudflare/workerd
    • हाल में RAM की बढ़ती कीमतें self-hosting को और मुश्किल न बना दें, इसकी चिंता है
      अगर बड़ी कंपनियाँ resources पर कब्ज़ा जमा लें, तो व्यक्तियों के लिए खुद hosting करना कठिन हो सकता है
    • NAT cost को ‘free से भी महँगा’ कहना दिलचस्प है
      लेकिन वास्तव में कई देशों में खुद चलाने की लागत इससे भी ज़्यादा होती है
      सिर्फ install कर देना काफ़ी नहीं; maintenance staff और monitoring की लागत भी काफ़ी होती है
  • अच्छा होगा अगर documentation में यह साफ़ लिखा जाए कि अभी कौन-सी सुविधाएँ काम नहीं करतीं और roadmap क्या है

    • बढ़िया सुझाव! जो features अभी implement नहीं हुए हैं, वे हैं Durable Objects, WebSockets, HTMLRewriter, cache API
      अगली प्राथमिकता debugging के लिए execution record/replay feature है, और documentation में roadmap section जोड़ने वाले हैं
  • Pixel + Firefox पर ASCII architecture diagram टूटा हुआ दिखता है
    text-based diagrams आकर्षक होते हैं, लेकिन व्यवहार में image में compile किया हुआ version प्रकाशित करना ज़्यादा व्यावहारिक है

    • बताने के लिए धन्यवाद! हमने mobile के लिए सरल किया हुआ ASCII version जोड़कर इसे ठीक कर दिया है
    • मेरे iPhone 11 Safari पर यह पूरी तरह render हो रहा है
  • तकनीकी और संरचनात्मक, दोनों नज़रिए से यह शानदार product idea है
    खासकर बड़े vendor के open source project को उल्टा open source से जवाब देने वाला मॉडल मुझे पसंद आया
    यानी, वे open source लेकर उसे commercialize करते हैं, जबकि हम उनके model को open source के रूप में वापस लाते हैं — मुझे लगता है यही सही दिशा है

  • ऐसा लगता है कि “क्यों न cloud को अपने ही कंप्यूटर पर host करें?” वाला विचार फिर लौट आया है
    हाल में यह self-hosting trend कई जगह दिख रहा है
    इससे जुड़ा प्रेज़ेंटेशन वीडियो भी दिलचस्प है

    • लेकिन तब उसे ‘cloud’ कहना मुश्किल हो जाता है
      cloud की असली पहचान elasticity है
      ज़रूरत के हिसाब से instances बढ़ाना-घटाना और जितना इस्तेमाल हो उतना ही भुगतान करना
      self-hosting में deployment tools सुविधाजनक हो सकते हैं, लेकिन आख़िर में पूरे server की लागत आपको ही उठानी पड़ती है
      load स्थिर हो या अनुमानित हो, तो यह ठीक है, लेकिन नहीं तो यह अलाभकारी हो सकता है
      (उदाहरण के लिए, यह बस में सफ़र करने और अपनी van रखने के फ़र्क जैसा है)
    • FaaS (Function-as-a-Service) की असली उपयोगिता ‘cloud’ शब्द से ज़्यादा event-driven framework देने में है
      developer event handler implementation पर ध्यान दे सकता है, और अगर queue या durable execution भी हो तो यह और शक्तिशाली बन जाता है
      आख़िरकार FaaS एक ऐसा high-level tool है जो boilerplate code को abstract कर देता है