Sprites - स्टेटफुल सैंडबॉक्स

 (fly.io)
5 पॉइंट द्वारा GN⁺ 2026-01-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Fly.io ने नया ‘Sprites’ पेश किया है, जो मौजूदा एकबारगी सैंडबॉक्स की जगह persistent cloud computer की अवधारणा लाता है
  • इसे 1~2 सेकंड के भीतर बनाया जा सकता है, और यह ऑटो idle state transition, checkpoint restore, तथा 100GB durable storage प्रदान करता है
  • यह बताता है कि मौजूदा stateless container model AI एजेंटों (जैसे Claude) के लिए अप्रभावी है, और persistent environment की आवश्यकता पर ज़ोर देता है
  • एक वास्तविक उदाहरण के रूप में, Claude ने Sprite पर SQLite-आधारित Go app (MDM) बनाया और उसे लंबे समय तक चलाया
  • लेख का निष्कर्ष: “सैंडबॉक्स का युग खत्म हो गया है, और disposable computer का युग आ गया है”

Sprites: persistent cloud computer - https://sprites.dev/

  • Fly.io का कहना है कि मौजूदा read-only sandbox model पुराना हो चुका है, और उसकी जगह लेने के लिए उसने ‘Sprite’ पेश किया है
    • sprite create कमांड से 1 सेकंड के भीतर Linux root shell बन जाता है
    • Sprite में 100GB durable storage होता है, और idle होने पर यह अपने-आप sleep में जाकर बाद में restore हो सकता है
  • sprite-env checkpoints create से पूरे सिस्टम का checkpoint तुरंत बनाया जा सकता है
    • sprite checkpoint restore v1 से 1 सेकंड के भीतर restore किया जा सकता है, और Git की तरह system-level version control संभव है
  • प्रमुख विशेषताएँ
    • सैकड़ों instances आसानी से बनाए जा सकते हैं
    • ऑटो billing pause (Idle metering) से लागत कम होती है
    • Anycast network connection के ज़रिए HTTPS URL मिलता है
    • पूर्ण durability बनाए रखता है, और स्पष्ट रूप से delete करने तक बना रहता है

Claude और stateless containers की सीमाएँ

  • आज अधिकांश cloud environment stateless container-केंद्रित संरचना पर आधारित हैं
    • डेटा केवल बाहरी DB में स्टोर होता है, जिसका उद्देश्य सरलता और scalability हासिल करना है
  • लेकिन Claude जैसे AI agents इस संरचना के लिए उपयुक्त नहीं हैं
    • वे container को bypass या उससे बाहर निकलने जैसा व्यवहार दिखाते हैं, और पूरे “computer” तक access चाहते हैं
  • “computer” की परिभाषा के रूप में durability और ऐसा environment जो काम के बाद भी गायब न हो प्रस्तुत किया गया है
    • मौजूदा sandbox इन दोनों चीज़ों से वंचित हैं

सरलता (Simple Wins)

  • persistent environment में development environment को दोबारा बनाना (node_modules आदि) ज़रूरी नहीं होता
    • उद्योग इसे हल करने के लिए snapshot तकनीक पर करोड़ों डॉलर निवेश कर रहा है
  • ऐसे वास्तविक उदाहरण भी हैं जहाँ infra बनाकर agent को S3, Redis, RDS जैसे बाहरी resources तक पहुँच दी जाती है
    • यह sandbox की non-persistent प्रकृति को bypass करने के लिए एक अस्थायी उपाय है
  • Sprite इस जटिलता को हटाकर ऐसा environment देता है जहाँ लिखी गई फाइलें वैसी ही बनी रहती हैं
  • उदाहरण के तौर पर, Phoenix.new प्रोजेक्ट में Fly Machine-आधारित agent ने app logs को सीधे देखते हुए त्रुटियाँ ठीक कीं

Galaxy Brain Win: development और operations का मेल

  • लेखक ने Claude के साथ मिलकर SQLite-आधारित Go app (MDM) को Sprite पर बनाया
    • Anycast URL के ज़रिए इसका उपयोग MDM registration URL के रूप में किया गया
    • Claude ने APNS certificate setup तक अपने-आप संभाला
  • यह app एक महीने से अधिक समय से Sprite पर स्थिर रूप से चल रही है
    • इससे “development environment ही production environment है (dev is prod, prod is dev)” की अवधारणा साकार होती है
  • लेखक का तर्क है कि अधिकांश apps को बड़े पैमाने के traffic की ज़रूरत नहीं होती, बल्कि व्यक्तिगत रूप से अनुकूलित persistent apps अधिक महत्वपूर्ण हैं
    • ऐसी संरचना जहाँ उपयोगकर्ता सीधे features माँग सकें और उन्हें तुरंत लागू किया जा सके

सैंडबॉक्स का अंत और disposable computers का युग

  • Fly.io लंबे समय से horizontally scalable micro-VM platform विकसित कर रहा है, लेकिन sandbox model अब अपनी सीमा तक पहुँच चुका है
  • Sprite, Fly Machines जैसा है, लेकिन इसमें नई storage stack और orchestration structure है, और Dockerfile की आवश्यकता नहीं
  • एक मुख्य प्रश्न उठाया गया है:

    “अगर आप किसी agent को चला सकते हैं, तो क्या आप read-only sandbox की बजाय तुरंत बुलाया जा सकने वाला EC2 instance नहीं चाहेंगे?”

  • निष्कर्ष: “सैंडबॉक्स का युग खत्म हो गया है, और disposable computer का युग आ गया है।”

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

1 टिप्पणियां

 
GN⁺ 2026-01-11
Hacker News प्रतिक्रियाएँ

  • शुरुआत में यह मुझे सच में बहुत पसंद आया, लेकिन Fly API के साथ पहले के दूसरे अनुभवों की तरह इस बार भी कुछ टूटा हुआ-सा लगा
    अगर https://sprites.dev/api दस्तावेज़ में दिया गया उदाहरण कमांड ज्यों का त्यों चलाएँ, तो {"error":"name is required"} जैसा जवाब मिलता है
    लेकिन Create Sprite docs में दिया गया पूरा request body इस्तेमाल करें, तो यह ठीक से काम करता है
    निजी workflow के लिए ऐसी rough edges शायद झेली जा सकती हैं, लेकिन पूरी टीम को प्रभावित करने वाले CI/CD में इसे लेकर हिचकिचाहट होगी
    Fly टीम से एक अनुरोध है — दस्तावेज़ में दिए गए उदाहरणों को ज़रूर test automation से verify किया जाए

    • शायद वजह यह है कि Content-Type header शामिल नहीं किया गया
    • अच्छा होगा अगर ऐसी समस्या को public issue tracker में report किया जा सके। ज़रूरी नहीं कि वह GitHub ही हो, लेकिन ऐसा कोई स्थान होना चाहिए जहाँ उपयोगकर्ता सार्वजनिक रूप से चर्चा कर सकें

  • https://sprites.dev/ वाकई बहुत दिलचस्प है
    यह एक साथ मेरी पसंद की दो समस्याएँ हल करता है

    1. development environment sandbox — Claude Code या Codex CLI को सुरक्षित रूप से चलाने के लिए सस्ता और persistent VM environment
    2. Sandbox API — एक साधारण JSON API call से untrusted code को isolated environment में चलाया जा सकता है
      इसमें snapshot फीचर भी है, इसलिए execution के बाद पिछली स्थिति में आसानी से लौटा जा सकता है
      मैंने इसके बारे में विस्तार से अपने ब्लॉग में लिखा है → simonwillison.net लेख
    • अगर आप रुचि रखते हैं, तो यह संबंधित thread भी देख सकते हैं: Fly’s Sprites.dev addresses dev environment sandboxes and API sandboxes together
    • मैं इस काम के लिए container-use का अच्छी तरह उपयोग कर रहा हूँ → https://container-use.com/quickstart
      और यह सुनकर अच्छा लगा कि Simon अपने काम को और monetize करने की कोशिश कर रहे हैं। उन्हें जितना अधिक लाभ मिलेगा, दुनिया उतनी बेहतर लगेगी

  • दार्शनिक रूप से मुझे Fly पसंद है और मैं शुरुआती दिनों से इसका ग्राहक रहा हूँ
    लेकिन CLI से जुड़े कामों में अब भी एक तरह का डर रहता है। अगर इसे हर कुछ हफ्तों में सिर्फ एक बार भी इस्तेमाल करूँ, तो auto-update बहुत बार बीच में आ जाता है और flow टूट जाता है
    चिंता है कि Sprite CLI भी वही समस्या दोहराएगा

    • मैंने भी इसी कारण Fly छोड़कर Digital Ocean पर जाना चुना। जो चीज़ “just works” होनी चाहिए थी, वह बहुत बार काम नहीं करती थी

  • यह सच में दिलचस्प है!
    हमारी कंपनी में हम Claude को SSH से जोड़े गए persistent development server का इस्तेमाल करते हैं, लेकिन git repo या environment गायब हो जाए तो असुविधा होती है
    लगता है Sprite से SQLite जैसी चीज़ों में data save करके URL से access होने वाला एक simple app बनाया जा सकता है
    अगर यह कुछ समय बाद अपने-आप हट जाने वाली संरचना है, तो simple personal software के लिए यह परफेक्ट लगती है
    अगर इसमें Vercel preview environment की तरह Fly account authentication के बाद URL देखने की सुविधा हो, तो और भी अच्छा होगा

  • यह अच्छा दिखता है, लेकिन Fly के दूसरे प्रोडक्ट stability या completeness के मामले में आदर्श नहीं रहे हैं
    API downtime और temporary errors अक्सर होते हैं, और billing issues का समाधान भी धीमा है
    उदाहरण के लिए, delete की गई instance अब भी उपयोग में दिखाई देती है, और hourly charge वास्तविक से दोगुना गिना जाता है
    उन्होंने Phoenix.new और Sprites जैसे नए AI products जारी किए हैं, लेकिन ऐसा लगता है कि मौजूदा products की quality सुधारने से ज़्यादा ध्यान नए products पर है

    • अगर सिर्फ reliability और support को देखें, तो मुझे इसे इस्तेमाल करने की कोई वजह नहीं दिखती

  • मैं लंबे समय से ऐसे development sandbox की चाहत रखता था — ऐसा environment जिसे बंद करना भूल जाएँ तो भी बड़ा खर्च न हो
    लेकिन कुछ समस्याएँ थीं

    1. manpath: can't set the locale error — शायद local locale settings ज्यों की त्यों pass हो गईं
    2. $SHELL /opt/homebrew/bin/fish पर set था। local environment variables remote पर बिना अनुमति भेजे गए लग रहे थे, जो थोड़ा असहज करने वाला था

  • यह सच में शानदार है। मैं ऐसे DX और API वाले sandbox execution environment का इंतज़ार कर रहा था
    मैं base image या VM को customize करके अनावश्यक tools हटाना और सिर्फ ज़रूरी binaries रखना चाहूँगा
    या checkpoint के आधार पर sprite clone करने की सुविधा होनी चाहिए। अभी ऐसा कोई option नज़र नहीं आता

    • अच्छा होगा अगर Docker deployment की तरह मैं अपनी पसंद का base sprite image upload कर सकूँ और उसी के ऊपर काम आगे बढ़ा सकूँ

  • पिछले कुछ महीनों से Sprites पर काम करते हुए मुझे सच में बहुत मज़ा आया
    जल्द ही Elixir वाले कुछ हिस्से open source किए जाएँगे
    5 मिनट का demo video भी है → YouTube डेमो

    • दिलचस्प बात यह है कि Claude खुद Sprites को control करता है। server चलाने पर वह अपने-आप local service के रूप में register हो जाता है, और बड़े बदलाव होने पर अपने-आप checkpoint बना देता है
      जो sprites उपयोग में नहीं हैं, उनका खर्च लगभग नहीं के बराबर है। हर नया काम शुरू करते समय बस एक नया बना लें
      यह अजीब लेकिन अच्छा एहसास है कि बिना ज़्यादा सोचे कभी भी चलाने लायक environment मौजूद है

  • domain fly.io से जुड़ा होने की वजह से, पहले मुझे लगा कि यह local solution होगा
    भले ही self-hosted न हो, मैं Docker या bubblewrap जैसी चीज़ों को wrap करने वाला local VM wrapper उम्मीद कर रहा था

    • अगर आपका उपयोग ऐसा है, तो LXC/Incus project देखना उपयोगी हो सकता है → https://linuxcontainers.org/incus/
      local hardware पर ZFS-आधारित IncusOS चलाएँ, तो यह बहुत शक्तिशाली sandbox environment बन जाता है

  • हो सकता है मैंने दस्तावेज़ में यह मिस कर दिया हो, लेकिन जानना चाहता हूँ कि sprite को fork/clone किया जा सकता है या checkpoint को नए sprite के रूप में restore किया जा सकता है
    उदाहरण के लिए, एक sprite को template की तरह इस्तेमाल करके कई copies चलानी हों, या Claude code कई समाधान तलाशे और बाद में सिर्फ एक रखकर बाकी हटा दे

    • वह फीचर जल्द जोड़ा जाएगा। अगले हफ्ते आने वाली “how this works” पोस्ट में इसके कारण और संरचना समझाई जाएगी
      इसे launch में शामिल करना चाहा गया था, लेकिन फैसला हुआ कि पहले कुछ और वास्तविक उपयोग डेटा इकट्ठा किया जाए