Microsandbox - एक virtual machine जो container जैसा महसूस होता है और वैसे ही काम करता है

 (github.com/microsandbox)
13 पॉइंट द्वारा GN⁺ 2025-05-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • microsandbox अविश्वसनीय user और AI code execution के लिए virtual machine-स्तर का isolation सुरक्षित रूप से प्रदान करता है
  • बेहद तेज boot (200ms से कम), OCI container compatibility, self-hosting आदि के जरिए यह पारंपरिक VM और container की कमियों को दूर करता है
  • अलग-अलग programming languages के लिए SDK और CLI tools के साथ developer और AI tool integration की दक्षता को अधिकतम करता है
  • code execution, development environment, data analysis, web automation, app hosting जैसे व्यापक AI और development use cases के लिए उपयुक्त है
  • सभी काम project-आधारित तरीके से manage किए जा सकते हैं, और system-wide install तथा session persistence/isolation execution environment को support करता है
  • microsandbox अविश्वसनीय user code या AI code (जैसे AI agent, user-submitted code, experimental code) के सुरक्षित execution के लिए बनाया गया एक open source self-hosting platform है
  • मौजूदा local execution में security vulnerabilities का जोखिम होता है, containers में kernel sharing की वजह से isolation अधूरा रहता है, traditional VM का boot धीमा होता है, और cloud में flexibility की कमी होती है
  • microsandbox microVM (अत्यंत हल्का virtual machine) आधारित वास्तविक process isolation को support करता है, और साथ ही container जैसी तेज startup speed और developer-friendly experience भी देता है
  • initial environment setup के बाद 200ms के भीतर boot, container image (OCI) compatibility, MCP-आधारित AI integration, और अपने infrastructure पर नियंत्रण जैसी खूबियों से यह अलग दिखता है

मुख्य विशेषताओं का सार

  • Bulletproof Security: microVM-आधारित virtual machine-स्तर की security प्रदान करता है, जो container की कमजोरियों (kernel escape) को मूल रूप से रोकता है
  • Instant Startup: initial boot time 200ms से कम है, जिससे VM की तुलना में code execution बहुत तेजी से शुरू होता है
  • Self-Hosting & Full Control: cloud पर निर्भर हुए बिना local या self-managed server पर सीधे deploy और operate किया जा सकता है
  • OCI संगत: standard container images को सीधे run किया जा सकता है, इसलिए मौजूदा Docker और container workflows के साथ compatible है
  • AI-Ready (MCP support) : Claude, Agno जैसे MCP-आधारित AI के साथ स्वाभाविक integration और extension संभव है

तेज development और execution workflow

1. server शुरू करना

  • केवल सरल commands से microsandbox server शुरू किया जा सकता है और development environment सेट किया जा सकता है
  • server, MCP server की भूमिका भी निभाता है, इसलिए Claude जैसे AI tools से इसे सीधे call किया जा सकता है

2. SDK install करना

  • Python, JavaScript, Rust जैसी प्रमुख languages के लिए microsandbox SDK उपलब्ध है
  • अतिरिक्त languages के support और SDK extensibility के कारण व्यापक developer और AI integration की संभावना मिलती है

3. code को सुरक्षित चलाना

  • Python, JavaScript, Rust आदि कई language sandbox environments को अलग-अलग चुनकर चलाया जा सकता है
  • हर sandbox एक independent execution environment है, इसलिए बाहरी code चलाने पर भी system safety बनी रहती है
  • SDK examples के जरिए asynchronous और automated safe code execution process को आसानी से लागू किया जा सकता है

project-आधारित environment management

  • project unit के आधार पर Sandboxfile (configuration file) बनाया और manage किया जाता है, जो developer-friendly package manager workflow जैसा है
  • कई sandbox environments (जैसे अलग-अलग languages या settings) को एक project में जोड़कर version और environment के हिसाब से manage किया जा सकता है
  • project sandbox चलाने पर file और install changes अपने-आप local directory (./menv) में सुरक्षित रहते हैं
  • temporary sandbox activation option भी है, जिसमें session खत्म होने पर सारा history और state पूरी तरह हट जाता है और isolation बना रहता है

system-wide sandbox install

  • अक्सर इस्तेमाल होने वाले environments या apps को अलग executable के रूप में install और register किया जा सकता है
  • terminal में project path के बिना भी एक line command से सीधे sandbox execution environment में प्रवेश किया जा सकता है
  • हर sandbox को नाम दिया जा सकता है, अलग settings के साथ कई configurations चलाई जा सकती हैं, और session state भी बनी रहती है

प्रमुख उपयोग के मामले

AI code execution और development environment

  • जब AI वास्तविक source code build, execution और debugging तक automate करता है, तब यह isolated और repeatable development environment तेजी से उपलब्ध कराता है
  • web app generation, bug fixing, prototype जैसे code automation use cases के लिए उपयुक्त है

data analysis

  • NumPy, Pandas, TensorFlow जैसी प्रमुख data science libraries को sandbox के भीतर सुरक्षित रूप से उपयोग किया जा सकता है
  • personal information और sensitive data जैसे protection की जरूरत वाले analysis workflows के लिए आदर्श है

web browsing agent

  • website navigation, form submission, login, data crawling जैसे automation tasks AI सुरक्षित रूप से कर सकता है
  • content collection, price comparison, automation testing आदि में उपयोगी है

instant app hosting

  • user द्वारा बनाए गए tools, demos, calculators, visualizations आदि को तुरंत service के रूप में share किया जा सकता है
  • हर app अलग isolated space में चलता है, और temporary environments को तेजी से create और terminate किया जा सकता है

system architecture

  • user अपनी business logic से microsandbox SDK को call करता है
  • server process (microsandbox server) को अविश्वसनीय code के transfer और execution का अनुरोध भेजा जाता है
  • server के भीतर हर execution request अलग microVM में चलती है, इसलिए वे एक-दूसरे से isolated रहती हैं
  • हर microVM में independent Python/Node environment configure किया जा सकता है

open source policy

  • Apache License 2.0 के तहत open source के रूप में वितरित

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-31
Hacker News की राय
  • मैं एक औपचारिक container security rating देखना चाहूँगा
    1. सभी ज्ञात container vulnerabilities की सूची तैयार की जाए
    2. हर vulnerability को permission-based, jail, Docker, emulator आदि जैसे अलग-अलग security environments में चलाया जाए
    3. और यह score दिया जाए कि कुल exploits में से कितने प्रतिशत रोके गए
      इस तरह शायद simple permission या jail-आधारित containers 0% के करीब, Docker 50% से ऊपर, और Microsandbox 100% के करीब आ सकता है
      इससे “सीधे jail ही क्यों नहीं इस्तेमाल करते?” जैसे सवालों पर होने वाली सहज जिज्ञासा भी शांत हो सकती है
      और open web पर honeypot containers चलाकर, hack करने में सफल होने पर cash या coin reward देने के तरीके से यह ‘साबित’ करना भी मज़ेदार हो सकता है कि कौन-सा container 100% तक पहुँचता है
      हाल के Rowhammer और Spectre जैसी vulnerabilities को देखते हुए पारंपरिक और cloud computing security को फिर से परिभाषित करने की ज़रूरत भी है
      आखिरकार मकसद यह समझ पाना है कि perfect emulation के बिना 100% secure container कैसे बनाया जा सकता है, और OS की बुनियादी services को कैसे सुरक्षित किया जाए
  • multi-tenant environment में “container vulnerability” असली समस्या नहीं है, बल्कि यह मूल संरचना है कि kernel shared होता है
    क्योंकि यदि kernel LPE(Local Privilege Escalation) vulnerability हो, तो वह सीधे container escape में बदल जाती है
    आमतौर पर इसे container escape के रूप में चिह्नित नहीं किया जाता, लेकिन उद्योग में अगर kernel LPE है, तो स्वाभाविक रूप से माना जाता है कि container security टूट चुकी है
  • malicious containers के मामले में Linux kernel-आधारित container runtime के साथ पूरी तरह सुरक्षित environment बनाना संभव नहीं है
    एक स्पष्ट विकल्प यह है कि sandbox के अंदर system call(API) के उपयोग पर भारी restrictions लगा दी जाएँ, लेकिन तब container एक general-purpose platform नहीं रह जाता, और हर case में अलग tuning करनी पड़ती है
    इसलिए यह दृष्टिकोण है कि virtualization ज़रूरी है
    जब तक कोई memory-safe और मज़बूत OS नहीं आता, यही एक रास्ता है; और ऐसा OS आ भी जाए, तब भी यह अभी स्पष्ट नहीं कि host Linux पर MicroVM चलाने से वह तेज़ होगा या नहीं
  • अच्छा होता अगर machine की configuration values भी साथ में दिखाई जातीं
    Docker या systemd में अलग-अलग settings के आधार पर security level बहुत बदल जाता है
    मुझे लगता है कि यह समझने के लिए बड़ा experimental dataset चाहिए कि कौन-सी setting किस risk/security level की ओर ले जाती है
  • असल में containers पहले से ही cash/coin bounty वाले honeypot की तरह चल रहे हैं
    व्यवहारिक रूप से वास्तविक production environments खुद ही अनगिनत hackers के हमले का लक्ष्य हैं
    ऐसा incentive model दिलचस्प हो सकता है, लेकिन वास्तविक hacking targets की प्रतिस्पर्धा और आर्थिक incentive की तुलना में यह काफी छोटा होगा
  • मुझे जिज्ञासा है कि पारंपरिक VM boot(start) होने में इतना समय क्यों लेते हैं
    उदाहरण के लिए Windows में VM चलाते समय, कुछ भी शुरू होने से पहले कई सेकंड इंतज़ार करना पड़ता है
    यहाँ “कुछ भी नहीं चल रहा” से मतलब है user program शुरू होने से पहले, firmware के पहले instruction के शुरू होने से भी पहले की स्थिति
    यहाँ तक कि virtual disk file को साफ़ करने से पहले, या VM window खुलने से पहले भी एक लंबा इंतज़ार होता है
    क्यों ऐसा होता है, जानना चाहूँगा
    • Linux kernel को 1 सेकंड से कम में boot करना optimization के ज़रिए पूरी तरह संभव है
      लेकिन standard kernel के मामले में timeout या polling जैसी कई चीज़ें समय लेती हैं
      UEFI/CSM systems में virtual hardware की तैयारी, system environment initialization आदि भी काफी समय लेते हैं
      लगता है WSL2 अनावश्यक overhead हटाने के लिए एक विशेष kernel इस्तेमाल करता है
      अलग-अलग OS services की startup, filesystem preparation, cache setup, network configuration आदि का भी असर पड़ता है
      पारंपरिक तरीका bootloader → initramfs → main OS को अलग-अलग load करता है
      boot time को बहुत कम करने के लिए Amazon Firecracker जैसे तरीके इस्तेमाल होते हैं, जहाँ पहले से initialized VM image को सीधे memory में चढ़ा दिया जाता है
      Firecracker MicroVM परिचय
      Windows में boot speed इस पर निर्भर करती है कि HyperV जैसे कौन-से hypervisor का उपयोग हो रहा है
      HyperV UEFI काफी धीमा है, और कई Linux distributions optimized minimal kernel नहीं देतीं
    • आप कौन-सा VM software इस्तेमाल कर रहे हैं, इस पर और जानकारी चाहिए
      VirtualBox में यह समस्या खास तौर पर साफ़ दिखती है, और पुराने versions में ऐसा delay नहीं था
      हो सकता है यह “पारंपरिक VM” की मूल सीमा न होकर केवल उसी software की समस्या हो
    • ऐसा हमेशा नहीं होता
      आम तौर पर VM इसलिए धीमे होते हैं क्योंकि वे अनावश्यक components तक emulate करते हैं
      अगर boot speed को प्राथमिकता देकर hypervisor बनाया जाए और legacy compatibility को नज़रअंदाज़ किया जा सके, तो Firecracker की तरह 125ms में boot करना संभव है
    • Linux में VM memory allocation धीमा होने का मुख्य कारण तब है जब 4KB pages में कई GB allocate किए जाते हैं
      अगर 1GB units में allocation हो, तो यह नाटकीय रूप से तेज़ हो सकता है
      शायद Windows में भी कुछ ऐसा ही तरीका होगा
    • संभव है यह VirtualBox की समस्या हो
      मैंने Hyper-V पर Ubuntu 22 GUI में XRDP के साथ 10 सेकंड में, और Ubuntu 22 server में SSH के साथ 3 सेकंड से कम समय में पहुँचने का अनुभव किया है
  • अविश्वसनीय code चलाने की ज़रूरत वाले परिदृश्य में “remote install script को सीधे Bash में pipe करें” जैसी installation instructions की विडंबना पर ध्यान दिलाया गया
    फिर भी, मूल विचार अपने आप में बेहद दिलचस्प है
    • पहले मैं भी बात नहीं समझ पाया था, लेकिन install script को अलग से download करके खुद verify करना भी संभव है
      जल्द ही एक आधिकारिक distribution method उपलब्ध कराने की योजना है
  • प्रोजेक्ट साझा करने के लिए धन्यवाद, और यह भी बताया कि वही microsandbox के निर्माता हैं
    लक्ष्य यह था कि Docker container की तरह MicroVM बनाना आसान हो
    कोई भी सवाल हो, कभी भी पूछ सकते हैं
    • मैं इसे अभी Python library के रूप में अच्छी तरह इस्तेमाल कर रहा हूँ, लेकिन sandbox को कई अलग calls के बीच लगातार चालू रखना चाहता हूँ
      “Sandbox is not started. Call start() first” जैसी errors कभी-कभी आती हैं
      आधिकारिक documentation का pattern “async with” है, लेकिन मेरा उपयोग ऐसा है कि हर class के लिए एक बार instantiate करूँ और फिर कई methods में उसे लगातार इस्तेमाल करूँ
      इसके लिए कोई recommended approach या best practice जानना चाहता हूँ
    • मैं distributed/decentralized software test network(Valet Network) बना रहा हूँ, और microsandbox इसमें बहुत उपयोगी लग रहा है
      networking कैसे काम करती है, यह जानना चाहता हूँ
      उदाहरण के लिए, क्या microvm को सिर्फ public IP तक पहुँच की अनुमति देकर सीमित किया जा सकता है?
      यानी क्या microvm को local network IPs तक पहुँचने से रोका जा सकता है?
    • वाकई बहुत शानदार project, appcypher को सलाम
      जानना चाहता हूँ कि क्या built-in MicroVM functionality OCI runtime interface देती है
      क्या इसे runc/crun की जगह Docker/Podman में भी इस्तेमाल किया जा सकता है?
    • मैंने readme को जल्दी से देखा, और कुछ सवाल हैं जिन पर और स्पष्टीकरण चाहिए
      यह इतना तेज़ कैसे हो सकता है?
      पारंपरिक VM के मुकाबले इसके trade-offs क्या हैं?
      क्या ऐसी कोई गुंजाइश है जिससे VM isolation कमज़ोर हो सकती है?
      क्या GUI चलाया जा सकता है?
      क्या आप इसे नए Vagrant की तरह देखते हैं?
      data input/output कैसे होता है?
    • यह बहुत साफ़-सुथरा दिखता है
      अगर मैंने सही समझा है, तो क्या इससे real-time में backend को server की तरह चलाया जा सकता है?
      supported languages की सूची प्रभावशाली है microsandbox supported languages list
      अच्छा होता अगर contribution guide और विस्तार से होती contributor guide
  • पिछले कुछ वर्षों में ultra-light, लगभग disposable VM विकल्पों की बढ़ती संख्या देखकर हैरानी होती है
    पहले के अनुभव में VM धीमे और भारी हुआ करते थे, जिससे काफी झंझट होती थी
    मैं इसकी तुलना macOS के Orbstack, खासकर उसके “Linux machines” feature से करना चाहूँगा
    यह भी जानना है कि क्या Orb सिर्फ एक ही VM को reuse करता है
  • बधाई
    millisecond स्तर पर VM boot होना एक बहुत महत्वपूर्ण सुधार है
    लेकिन ऐसा CloudHypervisor और Firecracker से भी किया जा सकता है
    containers की बढ़त VM पर runtime performance में होती है
    VM के धीमे होने का कारण IO device emulation है
    खासकर AI agent-टाइप workloads में application layer पर overhead महसूस हो सकता है
    performance issues को सुलझाने की क्या योजना है, यह जानना चाहूँगा
    • सही बात है
      Microsandbox libkrun का उपयोग करता है, और libkrun performance overhead कम करने के लिए block, vsock और virtio-fs पर virtio-mmio इस्तेमाल करता है
      Firecracker भी मूल रूप से काफ़ी मिलता-जुलता है, और E2B project agentic AI workloads के लिए Firecracker इस्तेमाल करता है
      फिलहाल filesystem issues के अलावा किसी बड़े performance improvement की योजना नहीं है
  • मेरी पसंद के हिसाब से container technology OS को कुछ ज़्यादा ही फैलाकर जटिल बना देती है
    सिर्फ mount command चला कर ही समझ आ जाएगा कि मेरा क्या मतलब है
    जो जानकारी छिपी रहनी चाहिए थी, वह सब सामने आ जाती है, जिससे पहले के सरल commands की उपयोगिता घट जाती है
    इससे भी गंभीर समस्या यह है कि user अंदरूनी data structures को सीधे छू सकता है
    जैसे user को peek और poke दोनों की permission दे दी गई हो
    container का विचार अपने आप में अच्छा है, लेकिन जब तक kernel को फिर से design नहीं किया जाता, मौजूदा तरीका एक अस्थायी जुगाड़ जैसा है
    • मुझे पोस्ट की बात ठीक से समझ नहीं आई
      container के अंदर mount चलाने पर ऐसा क्या गंभीर दिखता है, ज़रा समझाइए
      क्या host mount वास्तव में container में exposed होता है?
      आम तौर पर तो मेरी समझ यह है कि केवल तभी संभव है जब volume वगैरह को स्पष्ट रूप से container से जोड़ा जाए
  • यह बहुत दिलचस्प लग रहा है और इसे तुरंत आज़माने का मन हो रहा है
    मैंने भी CodeSandbox SDK, E2B आदि से काफी मज़ा लिया है, इसलिए जानना चाहता हूँ कि इनके मुकाबले इसका अंतर क्या है और आगे की दिशा क्या है
    यह भी जानना चाहता हूँ कि क्या अंदरूनी तौर पर Firecracker इस्तेमाल होता है
    • Microsandbox कोई cloud solution नहीं देता
      यह self-hosted संरचना है
      E2B की तरह यह microVM-आधारित sandbox को local environment(Linux, macOS, Windows(जल्द)) में चलाना आसान बनाता है, और production में ले जाना भी सरल करता है
      Firecracker की जगह libkrun इस्तेमाल होता है
    • मेरी सबसे बड़ी जिज्ञासा यही थी कि क्या Firecracker इस्तेमाल होता है, वही मेरा मुख्य interest था
      मुझे यह भी जिज्ञासा है कि microVM solutions में maintenance issues कैसे संभाले जाते हैं, और क्या security audits लगातार होते रहेंगे
      Firecracker और OCI image setup मुश्किल लगते हैं, इसलिए किसी वैकल्पिक समाधान का आना स्वागतयोग्य है
      Kata container को संभालना भी आसान नहीं है
  • इस तरह के projects आते हैं तो मेरी हमेशा रुचि जागती है
    containers का सबसे बड़ा फायदा यह है कि वे disk size, CPU cores जैसी specific resources बताए बिना भी जल्दी चल जाते हैं
    और उनकी state को image और diff के रूप में देखकर यह भी पता लगाया जा सकता है कि program ने चलते समय system में क्या-क्या बदलाव किए
    अगर ऐसी सुविधा वाले छोटे VM के ज़रिए ज्यादा सुरक्षित sandboxing मिल सके, तो बहुत अच्छा होगा
    कभी-कभी मैं bwrap भी इस्तेमाल करता हूँ, लेकिन वह command line के लिए बहुत अनुकूल tool नहीं है
    • resources(disk capacity, CPU आदि) को YAML file में एक बार declare कर दिया जाए तो काम हो जाता है
      templates या remote/automatic generation भी संभव है
  • विषय थोड़ा अलग है, लेकिन मैं एक ऐसे project पर काम कर रहा हूँ जहाँ अविश्वसनीय JavaScript code को ज़रूर चलाना पड़ता है
    microsandbox की वजह से उम्मीद जगी है कि ऐसे code को सुरक्षित रूप से isolate करके चलाया जा सकेगा
    200ms का boot delay भी live sandbox pool से संभाला जा सकता है
    OCI compatibility होने से पूरा sandbox environment भी दिया जा सकता है
    क्या यह वाकई अच्छा use case है, या इससे बेहतर कोई विकल्प है?
    • runsc/gVisor पर भी विचार किया जा सकता है
      runsc engine Docker/Docker Desktop के अंदर भी चल सकता है
      लेकिन gVisor में network parallelism जैसी चीज़ों में performance docker के मुकाबले लगभग 1/3 रहती है
    • यही तो microsandbox के लिए आदर्श use case है
      मुझे इससे बेहतर कोई विकल्प नहीं मिला, इसलिए मैंने खुद microsandbox बनाया