VPS पर sandboxd कैसे host करें: पूरी गाइड

sandboxd क्या है, और इसे स्वयं चलाने से आपको क्या लाभ मिलता है

sandboxd को self-host करने के लिए आपको Docker के साथ एक Linux सर्वर और एक domain name की आवश्यकता होती है। आप एक prompt भेजते हैं, एक coding agent एक isolated container के भीतर एक वास्तविक application बनाता है, और वह application अपने स्वयं के preview URL पर live हो जाता है। Prompt-to-app builders 2026 की सबसे चर्चित hosted श्रेणी है, और sandboxd वह है जो आपके VPS पर, MIT licence के तहत चलता है, जिसमें generated code आपकी अपनी disk पर रहता है।

इसका design जानबूझकर छोटा रखा गया है। एक Go control plane Docker को संचालित करता है, Traefik v3 प्रत्येक preview hostname को route करता है, SQLite state को सुरक्षित रखता है, और प्रत्येक app एक container के भीतर चलता है। इसमें कोई Kubernetes और कोई अलग database server नहीं है, यही कारण है कि एक 2 vCPU वाला box इसे चलाने में सक्षम है।

चार objects पूरे model को संचालित करते हैं। एक app एक durable project है, जिसमें उसका नाम, git metadata और secrets होते हैं। एक sandbox वह Docker container है जिसमें app चलता है, और एक app एक समय में एक sandbox की ओर point करता है। एक workspace app की files हैं, जो host पर रहती हैं और container के बंद होने के बाद भी सुरक्षित रहती हैं। एक task sandbox के भीतर agent को दिया गया एक prompt है। Sandbox को stop करने से memory खाली हो जाती है और files सुरक्षित रहती हैं। इसे destroy करने से container हट जाता है, और app एक नया container boot कर सकता है।

sandboxd, Dify और OpenHands से किस प्रकार भिन्न है?

इन तीनों के बीच भ्रम होता है क्योंकि ये सभी आपके सर्वर पर एक LLM (large language model) चलाते हैं, लेकिन इनका आउटपुट अलग होता है। Dify LLM applications बनाता है: चैट इंटरफेस, रिट्रीवल पाइपलाइन, और ऐसे वर्कफ़्लो जो हर बार उपयोग किए जाने पर मॉडल को कॉल करते हैं। मॉडल तैयार उत्पाद का एक हिस्सा होता है। OpenHands आपके मौजूदा रिपॉजिटरी पर काम करता है: आप इसे अपने कोड की ओर निर्देशित करते हैं और यह फाइलों को पढ़ता है, कमांड चलाता है और बदलावों का सुझाव देता है। sandboxd शून्य से शुरुआत करता है। यह एक प्रीसेट से प्रोजेक्ट को तैयार करता है, इसे एक नए कंटेनर में बनाता है, और आपको देखने के लिए एक URL देता है। अंत में जो मिलता है वह एक सामान्य React या FastAPI एप्लिकेशन होता है जिसे चलने के लिए किसी मॉडल की आवश्यकता नहीं होती।

इसलिए चुनाव इस आधार पर करें कि आप अंत में क्या चाहते हैं। sandboxd एक वाक्य से शुरुआत करने और बाद में कोड को अपने पास रखने के लिए है। अन्य दो तब के लिए हैं जब रिपॉजिटरी या मॉडल-आधारित उत्पाद पहले से मौजूद हो।

दूसरा अंतर उम्र का है, और किसी भी वास्तविक प्रोजेक्ट को बनाने से पहले इसे ध्यान में रखना आवश्यक है।

[
  {
    "tool": "sandboxd",
    "github_stars": "875",
    "forks": "50"
  },
  {
    "tool": "OpenHands",
    "github_stars": "83,091",
    "forks": "10,711"
  },
  {
    "tool": "Dify",
    "github_stars": "151,320",
    "forks": "23,886"
  }
]

sandboxd के पास 875 स्टार हैं, जबकि OpenHands के पास 83,091 और Dify के पास 151,320 स्टार हैं। रिपॉजिटरी 3 June 2026 को बनाई गई थी, इसलिए August 2026 तक यह दो महीने पुरानी है, जबकि OpenHands March 2024 से और Dify April 2023 से मौजूद है। Release v0.1.0 को 6 June 2026 को और v0.3.6 को 1 August 2026 को जारी किया गया था। प्रोजेक्ट खुद को बीटा कहता है और बताता है कि 0.x रिलीज़ में कम्पैटिबिलिटी टूट सकती है। इन आंकड़ों को गुणवत्ता के फैसले के बजाय निर्भरता जोखिम (dependency risk) के रूप में देखें: दो महीने पुराने प्रोजेक्ट को केवल दो महीने ही मिले हैं जिसमें अन्य लोगों ने इसकी कमियां ढूंढी हैं।

सर्वर की आवश्यकताएं और संसाधनों की कमी से होने वाली समस्याएं

प्रोजेक्ट के अनुसार 2 vCPU और 4 GB RAM शुरुआत के लिए पर्याप्त हैं। यह control plane और एक छोटे sandbox के लिए सटीक है, लेकिन दो लोगों के एक साथ काम करने के लिए यह पर्याप्त नहीं है। मेमोरी को हिस्सों में विभाजित करें। Traefik और Go control plane छोटे हैं। प्रत्येक चल रहे sandbox में एक पूर्ण Node या Python toolchain होता है, और peak उपयोग npm install के बाद production build के दौरान होता है। ऐसे सर्वर के लिए 8 GB RAM की योजना बनाएं जो कुछ apps को चालू रखेगा, और swap को क्षमता के बजाय सुरक्षा कवच मानें, क्योंकि swap का उपयोग करने वाला build सेकंड के बजाय मिनटों का समय लेता है।

मेमोरी खत्म होने पर दो अलग-अलग तरह की विफलताएं होती हैं, और वे एक-दूसरे से बिल्कुल अलग दिखती हैं। sandbox के अंदर, container उस कठोर --memory सीमा तक पहुँच जाता है जिसे sandboxd सेट करता है और kernel सबसे बड़ी process को kill कर देता है, इसलिए build बिना किसी उपयोगी संदेश के समाप्त हो जाता है। docker ps -a उस container के लिए exit code 137 दिखाता है और उस पर docker inspect चलाने पर "OOMKilled": true रिपोर्ट होता है। इस तरह से समाप्त होने वाला Node build अक्सर पहले JavaScript heap out of memory प्रिंट करता है।

दूसरी विफलता host पर होती है। sandboxd एक pressure reaper चलाता है जो host memory कम होने पर sandboxes को रोक देता है, इसलिए छोटे सर्वर पर preview देखते समय sandbox गायब हो सकता है। फाइलें सुरक्षित रहती हैं और preview URL पर अगला request उसे फिर से सक्रिय कर देता है, लेकिन container रुकने के समय जो task चल रहा था वह फिर से शुरू नहीं होता।

Disk एक शांत समस्या है। प्रत्येक app host पर अपना workspace रखता है, और एक JavaScript प्रोजेक्ट में सैकड़ों megabytes का node_modules tree होता है। दस apps का मतलब है images की गणना करने से पहले ही कई gigabytes की dependencies। 40 GB से शुरुआत करें और उस पर नज़र रखें:

docker system df
sudo du -sh /var/lib/sandboxed/workspaces

डिफ़ॉल्ट डेटा डायरेक्टरी /var/lib/sandboxed है, जिसमें अतिरिक्त e लिखा जाता है। /var/lib/sandboxd टाइप करने पर आपको एक खाली डायरेक्टरी मिलेगी और पाँच मिनट का भ्रम होगा।

pinned sandboxd release को इंस्टॉल करना

Docker Engine के साथ Compose plugin, और git का सर्वर पर पहले से मौजूद होना आवश्यक है। VPS पर Docker इंस्टॉल करना इस प्रक्रिया को कवर करता है।

docker compose version
git --version

दोनों को एक version प्रिंट करना चाहिए। docker: 'compose' is not a docker command का अर्थ है कि आपके पास पुराना standalone docker-compose बाइनरी है, जबकि इंस्टॉलर को v2 plugin की आवश्यकता है।

इंस्टॉलर एक शेल स्क्रिप्ट है जिसे नेटवर्क से प्राप्त किया जाता है, इसलिए इसे चलाने से पहले पढ़ें और version को पिन करें।

curl -fsSL https://raw.githubusercontent.com/tastyeffectco/sandboxd/v0.3.6/install.sh -o install-sandboxd.sh
less install-sandboxd.sh
SANDBOXD_REF=v0.3.6 bash install-sandboxd.sh

SANDBOXD_REF वह git ref है जिसे इंस्टॉलर $HOME/.sandboxd/src में चेक आउट करता है, और यह डिफ़ॉल्ट रूप से main पर सेट होता है। इसे unset छोड़ने का अर्थ है कि आपका इंस्टॉलेशन वह होगा जो उस सुबह मर्ज किया गया था, जो कि ऐसे प्रोजेक्ट के लिए महत्वपूर्ण है जिसने केवल जुलाई 2026 में ही छह releases जारी किए हों। इसे पिन करें, और changelog पढ़ने के बाद ही सोच-समझकर अपग्रेड करें।

यह स्क्रिप्ट सोर्स को क्लोन करती है, इमेजेस को बिल्ड करती है, docker compose up -d के साथ स्टैक को स्टार्ट करती है, और अंत में कंसोल URL तथा एक API token प्रिंट करती है। उस टोकन को सुरक्षित स्थान पर सेव करें। यह उस API के लिए क्रेडेंशियल है जो root के रूप में Docker को संचालित करता है।

curl http://127.0.0.1:9090/healthz

जब control plane चालू हो जाता है, तो यह ok प्रिंट करता है। यदि यह कुछ भी प्रिंट नहीं करता है, तो स्टैक स्टार्ट नहीं हुआ है: यह देखने के लिए कि कौन सी सर्विस डाउन है, ~/.sandboxd/src से docker compose ps चलाएं, और कारण जानने के लिए docker compose logs sandboxd का उपयोग करें।

रिमोट बॉक्स पर कंसोल तक पहुँचना

कंसोल को HTTP_PORT पर Traefik के माध्यम से सर्व किया जाता है, जो डिफ़ॉल्ट रूप से 80 है, और इसका होस्टनेम http://console.localhost है। Traefik होस्टनेम के आधार पर रूटिंग करता है, इसलिए ब्राउज़र में अपने सर्वर का IP एड्रेस डालने पर कोई नियम मैच नहीं होता और 404 एरर मिलता है। जब तक आप कोई वास्तविक डोमेन सेट नहीं करते, तब तक पोर्ट को फॉरवर्ड करें और होस्टनेम को बनाए रखें:

ssh -L 8080:127.0.0.1:80 you@your-vps

इसके बाद अपने लैपटॉप पर http://console.localhost:8080 खोलें। Linux और macOS पर .localhost पर समाप्त होने वाला कोई भी नाम 127.0.0.1 पर रिज़ॉल्व होता है, इसलिए अनुरोध सही Host हेडर के साथ टनल से होकर जाता है। पहली बार विजिट करने पर कंसोल पासवर्ड सेट करें।

एजेंट को एक मॉडल दें

बेस इमेज में दो कोडिंग एजेंट आते हैं: OpenCode और Claude Code। SANDBOXD_DEFAULT_AGENT यह तय करता है कि कौन सा एजेंट उस कार्य को चलाएगा जिसका नाम निर्दिष्ट नहीं है, और यह डिफ़ॉल्ट रूप से opencode का उपयोग करता है। यदि कोई भी की (key) कनेक्ट नहीं है, तो कार्य OpenCode Zen के की-लेस फ्री मॉडल पर चलते हैं, इसलिए आपका पहला बिल्ड निःशुल्क होता है और आप कुछ भी खर्च करने से पहले पूरे लूप का परीक्षण कर सकते हैं।

जब आप एक अधिक शक्तिशाली मॉडल का उपयोग करना चाहें, तो अपनी स्वयं की की (key) कनेक्ट करें। कीज़ कंट्रोल प्लेन में जाती हैं, सैंडबॉक्स में कभी नहीं: इन्हें डेटा डायरेक्टरी के अंतर्गत एन्क्रिप्ट करके रखा जाता है और एक क्रेडेंशियल प्रॉक्सी द्वारा वायर पर इंजेक्ट किया जाता है, इसलिए न तो एजेंट और न ही इसके द्वारा लिखा गया कोड उन्हें पढ़ सकता है।

export API=http://127.0.0.1:9090
export SANDBOXD_TOKEN=sk_...                       # printed by the installer
export AUTH="Authorization: Bearer $SANDBOXD_TOKEN"

curl -s -XPOST $API/v1/agents/claude-code/api-key -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"api_key":"sk-ant-..."}'

कंसोल में Settings, AI Agents के अंतर्गत भी यही प्रक्रिया अपनाई जाती है, जिसमें एक गाइडेड OAuth फ्लो शामिल है यदि आप API की (key) के बजाय Claude सब्सक्रिप्शन का उपयोग करना चाहते हैं। प्रत्येक एजेंट के लिए डिफ़ॉल्ट मॉडल उसी पैनल में रहता है, और एक एकल कार्य इसे ओवरराइड कर सकता है।

एक छोटा ऐप शुरू से अंत तक बनाएँ

ऐप बनाएँ, उसका sandbox बूट करें, और फिर एक prompt भेजें। IDs JSON के रूप में वापस आते हैं, और quickstart उन्हें sed के साथ निकाल लेता है, इसलिए आपको jq इंस्टॉल करने की आवश्यकता नहीं है।

APP=$(curl -s -XPOST $API/v1/apps -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"name":"todo","runtime_preset":"react-vite"}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

SB=$(curl -s -XPOST $API/v1/apps/$APP/sandbox -H "$AUTH" \
  -H 'content-type: application/json' -d '{"ports":[3000]}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

echo "app=$APP sandbox=$SB"

दोनों variables में एक id होना चाहिए। एक खाली $SB का मतलब है कि sandbox कभी बूट नहीं हुआ, और इसका सामान्य कारण base image का अभी भी build होना या host की memory खत्म हो जाना है। id के स्थान पर 401 का मतलब है कि bearer token गलत है।

curl -s -XPOST $API/v1/sandboxes/$SB/tasks -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"prompt":"Add a todo list with a text input, an add button, and a delete button on each row. Keep the list in localStorage.","agent":"opencode"}'

response में एक task id होता है। GET /v1/sandboxes/$SB/tasks/<task id> उसका परिणाम लौटाता है, और उसी task पर /events path, agent क्या कर रहा है, इसका एक live SSE (server sent events) stream है। console वही stream दिखाता है जो chat में दिखता है।

ऐप फिर http://s-<sandbox id>-3000.preview.localhost पर होता है, जहाँ 3000 वह port है जिसके लिए आपने अनुरोध किया था। यदि sandbox sleep mode में था, तो पहला अनुरोध Traefik के catch-all पर जाता है, sandboxd container को start करता है, port के जवाब देने का इंतज़ार करता है, और एक छोटा warming page दिखाता है जो आपके ऐप में refresh हो जाता है। यदि preview उस page से आगे नहीं बढ़ता है, तो इसका मतलब है कि अंदर चल रही process ऐप के sandbox.yaml में घोषित port पर listen नहीं कर रही है।

Previews को HTTPS के साथ एक वास्तविक domain पर रखें

प्रत्येक sandbox का अपना hostname होता है, इसलिए एक wildcard DNS record उन सभी को कवर कर लेता है। *.preview.yourdomain.com को server के IP address पर एक A record के साथ point करें। फिर ~/.sandboxd/src में .env के भीतर preview variables को set करें:

PREVIEW_DOMAIN=yourdomain.com
PREVIEW_ENTRYPOINT=websecure
PREVIEW_TLS=true
SANDBOXD_API_AUTH_DISABLED=false

Traefik को इसके पूरक हिस्से की आवश्यकता है: traefik/traefik.yml में websecure entrypoint को enable करें और एक certificate resolver जोड़ें। DNS-01 challenge का उपयोग करें, क्योंकि एक wildcard certificate फिर प्रत्येक preview hostname को कवर कर लेता है। HTTP-01 के साथ प्रत्येक नए sandbox को अपने स्वयं के issuance की आवश्यकता होगी, और building की एक व्यस्त दोपहर सीधे Let's Encrypt की rate limits में फंस जाएगी। DNS-01 challenge के माध्यम से wildcard certificates इसके DNS पक्ष को कवर करता है।

cd ~/.sandboxd/src
docker compose up -d

Preview URLs https://s-<id>-3000.preview.yourdomain.com बन जाते हैं। Firewall पर 80 और 443 port खोलें और 9090 को दुनिया के लिए बंद रखें: देखें बुनियादी ufw firewall नियम। याद रखें कि जो कोई भी preview hostname का अनुमान लगा सकता है, वह app को load कर सकता है, इसलिए previews को public मानें।

जनरेट किया गया कोड कहाँ सुरक्षित होता है, और क्या इसे export किया जा सकता है?

होस्ट पर, यह डेटा डायरेक्टरी के अंतर्गत होता है। प्रत्येक workspace /var/lib/sandboxed/workspaces/<id>/ पर एक साधारण डायरेक्टरी है, जिसे container में bind mount किया जाता है, और app की फाइलें sandbox के अंदर /home/sandbox/workspace/app पर स्थित होती हैं। कंट्रोल प्लेन की स्थिति state/sandboxd.db पर एक एकल SQLite फाइल में होती है, और एन्क्रिप्टेड एजेंट क्रेडेंशियल्स agent-auth/ में होते हैं। कंटेनर लेयर के अंदर कुछ भी छिपा नहीं होता है, इसलिए बैकअप का अर्थ है एक डायरेक्टरी कॉपी और वह डेटाबेस फाइल। VPS पर restic backups इन दोनों को संभालता है।

sudo ls /var/lib/sandboxed/workspaces
sudo du -sh /var/lib/sandboxed/workspaces/*

Git export को अलग से जोड़ने के बजाय इसमें इन-बिल्ट दिया गया है। API पढ़ने के लिए status और diff को expose करता है, जिसके बाद commit और push किया जा सकता है:

curl -s $API/v1/apps/$APP/git/status -H "$AUTH"

curl -s -XPOST $API/v1/apps/$APP/git/commit -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"message":"todo list, first pass"}'

curl -s -XPOST $API/v1/apps/$APP/git/push -H "$AUTH" \
  -H 'content-type: application/json' -d '{"branch":"main"}'

एक प्राइवेट रिमोट के लिए personal access token की आवश्यकता होती है, जिसे console में Settings, Git credentials के अंतर्गत एक बार सेट करना होता है। यह एन्क्रिप्टेड रूप में स्टोर होता है और sandbox से बाहर रहता है, इसलिए एजेंट इसे पढ़ नहीं सकता और आपकी जानकारी के बिना इसका उपयोग करके push नहीं कर सकता। जल्दी और बार-बार push करें। जब तक आप ऐसा नहीं करते, workspace डायरेक्टरी ही कोड की एकमात्र कॉपी होती है, और DELETE /v1/apps/<id> इसे बिना किसी चेतावनी के हटा देता है।

एक बिल्ड में कितने model tokens का खर्च आता है?

sandboxd आपके खर्च को मापता नहीं है, इसलिए जो संख्या मायने रखती है वह आपके provider के console में दिखाई देती है। मुफ्त OpenCode Zen models की कोई लागत नहीं होती, लेकिन ये paid model की तुलना में धीमे और कमजोर होते हैं। इसका परिणाम यह होता है कि छोटे-मोटे apps के अलावा किसी भी चीज़ पर सुधार के अधिक rounds की आवश्यकता पड़ती है।

बिल का आकार इस बात पर निर्भर करता है कि agent loop कैसे काम करता है। प्रत्येक turn में आवश्यक context को फिर से भेजा जाता है, इसलिए लागत apps की संख्या के बजाय turns की संख्या के अनुसार बढ़ती है। एक बार में सफल होने वाला prompt सस्ता होता है। पचास फाइलों वाले project पर "अब spacing ठीक करो" जैसे पंद्रह rounds सस्ते नहीं होते, क्योंकि हर बार फाइल की सामग्री साथ में भेजी जाती है। Input और output tokens की कीमत अलग-अलग होती है, और एक coding agent प्रति session कितना खर्च करता है वास्तविक सीमा बताता है। किसी ऐसे loop को चलाने की अनुमति देने से पहले, जो बिना निगरानी के चलता हो, provider के पास एक hard spend limit सेट करें।

पुराने सैंडबॉक्स को हटाना

Idle reaper किसी भी ऐसे सैंडबॉक्स को रोक देता है जो SANDBOXD_IDLE_THRESHOLD_SECONDS से अधिक समय तक निष्क्रिय रहा हो, जो डिफ़ॉल्ट रूप से 2100 सेकंड या 35 मिनट होता है। यह RAM को वापस उपलब्ध करा देता है और फ़ाइलों को सुरक्षित रखता है, और प्रीव्यू URL पर अगला अनुरोध आने पर कंटेनर फिर से सक्रिय हो जाता है। छोटे सर्वर पर इसे कम रखें, क्योंकि 35 मिनट तक निष्क्रिय रहने वाले कंटेनर उस मेमोरी का उपयोग करते हैं जिसे आप इस्तेमाल नहीं कर पा रहे हैं।

रोकना (stopping) हटाना (deleting) नहीं है, और यहीं से डिस्क धीरे-धीरे भर जाती है। एक रुका हुआ सैंडबॉक्स अभी भी अपने वर्कस्पेस और कंटेनर का स्वामी होता है। सैंडबॉक्स को हटाना लेकिन ऐप को बनाए रखना सैंडबॉक्स पर एक DELETE है, जो कंटेनर और वर्कस्पेस दोनों को साथ ले जाता है। ऐप को हटाने से सब कुछ स्थायी रूप से मिट जाता है।

curl -s -XPOST $API/v1/sandboxes/$SB/stop -H "$AUTH"     # frees RAM, keeps files
curl -s -XDELETE $API/v1/sandboxes/$SB -H "$AUTH"        # container and workspace gone
curl -s -XDELETE $API/v1/apps/$APP -H "$AUTH"            # app and everything under it

कुछ हफ़्तों के प्रयोगों के बाद, docker system df आपकी अपेक्षा से अधिक reclaimable इमेज स्पेस दिखाएगा, क्योंकि जिस भी ऐप ने अपना टूलचेन पुल किया, उसने पीछे लेयर्स छोड़ दीं। docker image prune इन dangling लेयर्स को साफ़ करता है। पहले GET /v1/apps की जाँच करें, क्योंकि जो इमेज अभी भी किसी स्लीपिंग सैंडबॉक्स द्वारा संदर्भित है, वह कचरा (garbage) नहीं है।

कंटेनर बाउंड्री आपको क्या देती है और क्या नहीं

प्रत्येक सैंडबॉक्स एक unprivileged user के रूप में चलता है, जिसका root filesystem read-only होता है। इसमें सभी Linux capabilities को हटा दिया जाता है, no-new-privileges सेट होता है, और memory तथा process की सीमा तय होती है। यह प्रोजेक्ट इसकी सीमाओं के बारे में स्पष्ट है: एक shared kernel Linux container एक मजबूत isolation boundary है, लेकिन एक कमजोर security boundary है। एक kernel bug का मतलब host का breach होना है।

दो तथ्यों पर कार्रवाई की आवश्यकता है। self-hosted build में सैंडबॉक्स से network egress खुला रहता है, इसलिए जनरेट किया गया कोड इंटरनेट, आपके local network और cloud metadata endpoints तक पहुँच सकता है। source में एक nftables egress subsystem मौजूद है, लेकिन portable Docker Compose build में इसे compile नहीं किया गया है, जिसका अर्थ है कि सीमाएं आपके host firewall से तय होनी चाहिए। और control plane API प्रभावी रूप से host root है, क्योंकि यह Docker socket को नियंत्रित करता है। यह डिफ़ॉल्ट रूप से 127.0.0.1:9090 पर bind होता है, SANDBOXD_API_AUTH_DISABLED को false ही रहना चाहिए, और इसे कभी भी इंटरनेट पर publish नहीं किया जाना चाहिए।

यदि आप अन्य लोगों को अपने बॉक्स पर प्रॉम्प्ट भेजने की अनुमति देने की योजना बना रहे हैं, तो यह मॉडल अपने आप में बहुत कमजोर है। यह प्रोजेक्ट SANDBOXD_RUNTIME=runsc के साथ gVisor का सुझाव देता है, जो सैंडबॉक्स और host के बीच एक userspace kernel रखता है। इसमें syscall-heavy कार्यों के लिए प्रदर्शन लगभग 1.7 से 4 गुना धीमा हो जाता है। इसका अधिक मजबूत समाधान प्रति tenant एक मशीन का उपयोग करना है, जो डिस्पोजेबल VM में कोडिंग एजेंट चलाने के समान ही तर्क है।

क्या आपको दो महीने पुराने प्रोजेक्ट पर काम करना चाहिए?

एक पर्सनल बिल्ड बॉक्स के लिए, हाँ, लेकिन स्पष्ट सावधानियों के साथ: SANDBOXD_REF को पिन करें, /var/lib/sandboxed का बैकअप लें, और जिस भी ऐप की आपको परवाह है उसे git remote पर पुश करें। ऐसी किसी भी चीज़ के लिए जिसे कोई ग्राहक इस्तेमाल करता हो, 1.0 वर्शन का इंतज़ार करें या फिर उसमें आने वाली खराबी के लिए बजट रखें, क्योंकि मेंटेनर्स स्पष्ट रूप से कहते हैं कि 0.x वर्शन कभी भी बदल सकता है। मेंटेनर्स अगस्त 2026 तक 79 डॉलर प्रति माह पर एक मैनेज्ड इंस्टॉलेशन भी बेचते हैं, जिसे जानना तब उपयोगी होता है जब आप यह आकलन कर रहे हों कि प्रोजेक्ट के अस्तित्व में बने रहने का कोई ठोस कारण है या नहीं।

जोखिम के स्वीकार्य होने का कारण इसका आउटपुट है। sandboxd एक सामान्य git रिपॉजिटरी में एक सामान्य एप्लिकेशन तैयार करता है, इसलिए यदि प्रोजेक्ट रुक भी जाता है, तो आपके पास कोड सुरक्षित रहता है और आप केवल रैपर खोते हैं। यह किसी ऐसे होस्टेड बिल्डर की तुलना में बहुत बेहतर स्थिति है जो आपके प्रोजेक्ट का मालिकाना हक रखता है। इस वर्ष आपके सर्वर पर क्या जगह पाने योग्य है, इसके व्यापक दृष्टिकोण के लिए, 2026 में क्या self-host करना सार्थक है देखें।

FAQ

sandboxd के लिए न्यूनतम सर्वर स्पेसिफिकेशन क्या हैं?

प्रोजेक्ट के अनुसार, 2 vCPU और 4 GB RAM शुरू करने के लिए पर्याप्त हैं, जिसमें control plane, Traefik और एक छोटा sandbox शामिल है। यदि आप एक साथ कई apps चलाना चाहते हैं, तो 8 GB RAM और 40 GB डिस्क का उपयोग करें, क्योंकि प्रत्येक चल रहा sandbox एक पूर्ण Node या Python toolchain रखता है और प्रत्येक workspace डिस्क पर अपनी dependency tree बनाए रखता है। जब host पर संसाधन कम पड़ते हैं, तो sandboxd का pressure reaper मेमोरी खाली करने के लिए sandboxes को रोक देता है, और जो build अपने container की मेमोरी सीमा से अधिक हो जाती है, उसे kernel द्वारा समाप्त कर दिया जाता है: docker ps -a इसके लिए exit code 137 दिखाता है।

sandboxd, Dify या OpenHands से कैसे अलग है?

ये अलग-अलग artifacts तैयार करते हैं। Dify ऐसे applications बनाता है जो runtime पर model को call करते हैं, जैसे कि chat interfaces और retrieval pipelines। OpenHands आपके पास मौजूद repository को edit करता है, commands चलाता है और मौजूदा code में बदलाव का सुझाव देता है। sandboxd एक prompt से बिल्कुल नया project तैयार करता है, उसे अपने container के अंदर build करता है, और उसे एक preview URL पर serve करता है, और परिणाम एक सामान्य web application होता है जिसे चलने के लिए model की आवश्यकता नहीं होती है।

एजेंट जो code लिखता है, वह वास्तव में कहाँ रहता है?

यह host filesystem पर रहता है, न कि container image के अंदर। प्रत्येक app को /var/lib/sandboxed/workspaces/<id>/ पर एक directory मिलती है जिसे उसके sandbox में bind mount किया जाता है, और फाइलें अंदर /home/sandbox/workspace/app पर दिखाई देती हैं। Control plane की स्थिति उसी data directory में state/ के अंतर्गत एक एकल SQLite फाइल में होती है। आप console के Git tab से या /v1/apps/<id>/git/commit और /git/push endpoints के माध्यम से git remote पर commit और push कर सकते हैं, और private remotes के लिए token को sandbox को देने के बजाय control plane द्वारा encrypted रूप में store किया जाता है।

क्या sandboxd को इंटरनेट पर expose करना सुरक्षित है?

Preview URLs और console को expose करें, control plane API को कभी न करें। वह API host पर Docker को संचालित करती है, इसलिए यह root के बराबर है, और इसी कारण से यह डिफ़ॉल्ट रूप से 127.0.0.1:9090 पर bind होती है। Self-hosted build में sandboxes के पास open network egress भी होता है, जिसका अर्थ है कि एजेंट द्वारा लिखा गया code आपके local network और cloud metadata endpoints तक पहुँच सकता है, इसलिए यदि host के पास सुरक्षित रखने योग्य अन्य उपकरण हैं, तो host firewall rules जोड़ें। जिन लोगों पर आप भरोसा नहीं करते, उनके prompts के लिए container boundary पर निर्भर रहने के बजाय प्रति tenant एक host चलाएँ।