VPS वर sandboxd स्वतः कसे चालवायचे?

sandboxd काय आहे आणि ते स्वतः चालवल्याने काय मिळते

sandboxd स्वतः host करण्यासाठी Docker असलेला एक Linux सर्व्हर आणि एक domain name आवश्यक आहे. तुम्ही prompt पाठवता, coding agent isolated container मध्ये प्रत्यक्ष application तयार करतो आणि ते application स्वतःच्या preview URL वर उपलब्ध होते. 2026 मध्ये prompt-to-app builders ही hosted क्षेत्रातील सर्वाधिक चर्चेत असलेली श्रेणी आहे. sandboxd मात्र तुमच्या VPS वर चालते, MIT licence अंतर्गत उपलब्ध आहे आणि निर्माण केलेला code तुमच्या स्वतःच्या disk वर साठवते.

ही रचना जाणीवपूर्वक लहान ठेवली आहे. Go control plane Docker नियंत्रित करतो, Traefik v3 प्रत्येक preview hostname साठी routing करतो, SQLite state साठवते आणि प्रत्येक app एका container मध्ये चालते. Kubernetes किंवा स्वतंत्र database server नाही. त्यामुळे 2 vCPU असलेला सर्व्हरही ते चालवू शकतो.

संपूर्ण मॉडेल चार objects वर आधारित आहे. app हा टिकाऊ project असतो. त्यात त्याचे नाव, git metadata आणि secrets असतात. sandbox हा त्या app साठी वापरला जाणारा Docker container असतो. एका वेळी app एका sandbox कडे निर्देश करतो. workspace म्हणजे app च्या files. त्या host वर साठवल्या जातात आणि container नष्ट झाल्यानंतरही टिकतात. task म्हणजे sandbox मधील agent कडे पाठवलेला एक prompt. sandbox थांबवल्यास memory मोकळी होते आणि files कायम राहतात. sandbox नष्ट केल्यास container काढून टाकला जातो. त्यानंतर app साठी नवीन sandbox सुरू करता येतो.

sandboxd आणि Dify व OpenHands यांच्यात काय फरक आहे?

हे तिन्ही गोंधळात टाकले जातात, कारण ते सर्व तुमच्या सर्व्हरवर LLM (large language model) चालवतात. मात्र त्यांच्यापासून तयार होणारी गोष्ट वेगळी असते. Dify LLM अॅप्लिकेशन्स तयार करते: chat interfaces, retrieval pipelines आणि प्रत्येक वेळी कोणी वापरल्यावर model ला call करणारे workflows. तयार उत्पादनाचा एक भाग म्हणून model त्यात समाविष्ट असतो. OpenHands तुमच्याकडे आधीपासून असलेल्या repository वर काम करते: तुम्ही त्याला तुमच्या code कडे निर्देशित करता आणि ते files वाचते, commands चालवते आणि बदल सुचवते. sandboxd मात्र शून्यापासून सुरू होते. ते preset वरून project ची मूलभूत रचना तयार करते, fresh container मध्ये ते build करते आणि पाहण्यासाठी तुम्हाला URL देते. त्यातून तयार होणारे app हे सामान्य React किंवा FastAPI application असते. ते चालण्यासाठी कोणत्याही model ची गरज नसते.

म्हणून शेवटी तुम्हाला काय हवे आहे, त्यानुसार निवड करा. एका वाक्यापासून सुरुवात करून नंतर code स्वतःकडे ठेवायचा असल्यास sandboxd वापरा. Repository किंवा model-powered product आधीपासून अस्तित्वात असल्यास इतर दोनपैकी योग्य साधन वापरा.

दुसरा फरक म्हणजे त्यांचे वय. त्यावर प्रत्यक्ष काही उभारण्यापूर्वी हा फरक विचारात घेणे महत्त्वाचे आहे.

[
  {
    "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 stars आहेत. OpenHands कडे 83,091 आणि Dify कडे 151,320 stars आहेत. Repository 3 June 2026 रोजी तयार करण्यात आली. त्यामुळे August 2026 नुसार ती दोन महिन्यांची आहे. OpenHands ची सुरुवात March 2024 मध्ये झाली, तर Dify ची सुरुवात April 2023 मध्ये झाली. Release v0.1.0 6 June 2026 रोजी आणि v0.3.6 1 August 2026 रोजी release झाला. Project स्वतःला beta म्हणतो आणि 0.x releases मुळे compatibility तुटू शकते असे सांगतो. या आकड्यांकडे quality वरील अंतिम निर्णय म्हणून पाहू नका. त्यांना dependency risk म्हणून समजा: दोन महिन्यांच्या project मध्ये इतर वापरकर्त्यांना त्यातील bugs शोधण्यासाठी फक्त दोन महिने मिळाले आहेत.

सर्व्हरला काय आवश्यक आहे आणि कमतरता झाल्यावर काय बिघडते

प्रकल्पाच्या मते सुरुवातीसाठी 2 vCPU आणि 4 GB RAM पुरेसे आहेत. Control plane आणि एका लहान sandbox साठी हे अचूक आहे. मात्र एकाच वेळी दोन जण build करत असतील, तर ते पुरेसे नाही. मेमरीचे नियोजन घटकांनुसार करा. Traefik आणि Go control plane कमी मेमरी वापरतात. प्रत्येक चालू sandbox मध्ये संपूर्ण Node किंवा Python toolchain असतो. npm install नंतर production build चालू असताना मेमरीचा वापर सर्वाधिक होतो. काही अॅप्स चालू ठेवणाऱ्या सर्व्हरसाठी 8 GB RAM ठेवा. Swap कडे क्षमतेऐवजी सुरक्षिततेचे साधन म्हणून पाहा. कारण swap वापरून होणाऱ्या build ला काही सेकंदांऐवजी काही मिनिटे लागू शकतात.

मेमरी संपल्यावर दोन वेगवेगळे अपयश दिसतात. ते एकमेकांसारखे दिसत नाहीत. Sandbox मध्ये container, sandboxd ने निश्चित केलेल्या कठोर --memory मर्यादेपर्यंत पोहोचतो. त्यानंतर kernel सर्वात मोठी process बंद करतो. त्यामुळे agent कडून उपयुक्त संदेश न मिळता build थांबतो. docker ps -a त्या container साठी exit code 137 दाखवतो. त्यावर docker inspect चालवल्यास "OOMKilled": true दिसते. अशा प्रकारे थांबलेल्या Node build मध्ये सुरुवातीला अनेकदा JavaScript heap out of memory दिसते.

दुसरे अपयश host वर होते. Host ची मेमरी कमी झाल्यावर sandboxd pressure reaper चालवतो आणि sandboxes थांबवतो. त्यामुळे लहान सर्व्हरवर preview पाहत असताना sandbox नाहीसा होऊ शकतो. फाइल्स सुरक्षित राहतात. Preview URL कडे केलेली पुढील विनंती sandbox पुन्हा सुरू करते. मात्र container थांबला त्या वेळी चालू असलेले task पुन्हा सुरू होत नाही.

Disk ही तुलनेने शांतपणे निर्माण होणारी समस्या आहे. प्रत्येक अॅप host वर स्वतःचे workspace ठेवतो. JavaScript प्रकल्पात शेकडो megabytes आकाराचा node_modules tree असतो. Images धरून न मोजताही दहा अॅप्ससाठी dependencies ला अनेक gigabytes जागा लागते. 40 GB पासून सुरुवात करा आणि त्यावर लक्ष ठेवा:

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

या मार्गदर्शकात निश्चित केलेल्या v0.3.6 release मध्ये default data directory /var/lib/sandboxed आहे. त्यात अतिरिक्त e आहे. तेथे /var/lib/sandboxd टाइप केल्यास काहीही सापडणार नाही आणि समस्या समजण्यासाठी अनावश्यक पाच मिनिटे जातील. v0.3.9 (25 August 2026) मध्ये हे बदलले. नवीन installers नवीन installations /var/lib/sandboxd मध्ये ठेवतात. /var/lib/sandboxed हे केवळ आधीपासून तेथे असलेल्या installation साठी ठेवतात. नंतरच्या release ने प्रथम सेट केलेल्या सर्व्हरवर खालील प्रत्येक command मध्ये e नसलेला path वापरा.

पिन केलेले sandboxd release स्थापित करा

Docker Engine, Compose plugin आणि git हे प्रथम सर्व्हरवर स्थापित असणे आवश्यक आहे. VPS वर Docker स्थापित करणे या भागात त्याची माहिती दिली आहे.

docker compose version
git --version

दोन्ही commands ने version दाखवला पाहिजे. docker: 'compose' is not a docker command याचा अर्थ Compose v2 plugin उपलब्ध नाही. Installer प्रथम plugin वापरण्याचा प्रयत्न करतो. Plugin उपलब्ध नसल्यास, स्थापित असलेले standalone docker-compose binary वापरतो. दोन्ही उपलब्ध नसतील तेव्हाच तो Docker Compose not found सह थांबतो. या मार्गदर्शकातील commands docker compose वापरतात. त्यामुळे plugin स्थापित करणे हा सोपा उपाय आहे.

Installer हे network वरून आणलेले shell script आहे. त्यामुळे ते चालवण्यापूर्वी वाचा आणि version pin करा.

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 हा installer $HOME/.sandboxd/src मध्ये checkout करत असलेला git ref आहे. त्याची default value main आहे. हे unset ठेवल्यास त्या सकाळपर्यंत merge केलेली आवृत्ती स्थापित होईल. जुलै 2026 मध्ये या प्रकल्पाने एकट्याने सहा releases प्रकाशित केले असल्यामुळे हा फरक महत्त्वाचा आहे. Version pin करा. त्यानंतर changelog वाचून जाणीवपूर्वक upgrade करा. 12 October 2026 रोजी नवीनतम release v0.3.22 आहे. येथे pin केलेल्या v0.3.6 नंतरचे हे सोळावे release आहे.

Script source clone करते, images build करते, docker compose up -d वापरून stack सुरू करते आणि शेवटी console URL व API token दाखवते. हा token सुरक्षित ठिकाणी जतन करा. हा API साठीचा credential आहे आणि त्या API द्वारे Docker root म्हणून चालवला जातो.

curl http://127.0.0.1:9090/healthz

Control plane सुरू झाल्यावर हे ok दाखवते. काहीही दिसत नसेल, तर stack सुरू झालेला नाही. कोणती service down आहे हे पाहण्यासाठी ~/.sandboxd/src मधून docker compose ps चालवा. कारण पाहण्यासाठी त्यानंतर docker compose logs sandboxd चालवा.

दूरस्थ मशीनवरील कन्सोलपर्यंत पोहोचणे

कन्सोल Traefik द्वारे HTTP_PORT वर उपलब्ध करून दिला जातो. HTTP_PORT चे डीफॉल्ट मूल्य 80 आहे. तो http://console.localhost या hostname वर उपलब्ध असतो. Traefik hostname नुसार routing करतो. त्यामुळे browser मध्ये सर्व्हरचा IP address टाकल्यास कोणताही नियम जुळत नाही आणि 404 मिळतो. वास्तविक domain सेट करेपर्यंत port forward करा आणि hostname कायम ठेवा:

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

त्यानंतर आपल्या laptop वर http://console.localhost:8080 उघडा. Linux आणि macOS मध्ये .localhost ने समाप्त होणारे कोणतेही नाव 127.0.0.1 वर resolve होते. त्यामुळे योग्य Host header सह विनंती tunnel मधून जाते. पहिल्यांदा प्रवेश केल्यावर कन्सोलचा password सेट करा.

एजंटला मॉडेल द्या

Base image मध्ये दोन coding agents उपलब्ध असतात: OpenCode आणि Claude Code. SANDBOXD_DEFAULT_AGENT नाव स्पष्टपणे दिलेले नसलेल्या task साठी कोणता agent चालवायचा हे ठरवते आणि default म्हणून opencode वापरते. कोणतीही key जोडलेली नसली तरी task OpenCode Zen च्या keyless free models वर चालतात. त्यामुळे सुरुवातीचा build कोणताही खर्च न करता करता येतो आणि खर्च करण्यापूर्वी संपूर्ण कार्यप्रवाह तपासता येतो.

अधिक सक्षम मॉडेल वापरायचे असल्यास तुमची स्वतःची key जोडा. Keys control plane कडे जातात; त्या sandbox मध्ये कधीही जात नाहीत. त्या data directory अंतर्गत encrypted स्वरूपात साठवल्या जातात आणि credential proxy त्यांना wire वर inject करते. त्यामुळे agent किंवा त्याने लिहिलेला code या keys वाचू शकत नाही.

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-..."}'

Console मध्ये Settings, AI Agents अंतर्गत हीच प्रक्रिया करता येते. API key ऐवजी Claude subscription वापरायचे असल्यास guided OAuth flow देखील उपलब्ध आहे. प्रत्येक agent साठीचे default model याच panel मध्ये असते. एखाद्या task साठी ते स्वतंत्रपणे बदलता येते.

एक लहान अॅप सुरुवातीपासून शेवटपर्यंत तयार करा

अॅप तयार करा, त्याचा sandbox सुरू करा आणि त्यानंतर prompt पाठवा. id हे 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> त्याचा result परत करते. त्याच task वरील /events path हा agent काय करत आहे याचा live SSE (server sent events) stream असतो. console मध्ये हाच stream chat स्वरूपात दिसतो.

यानंतर अॅप http://s-<sandbox id>-3000.preview.localhost वर उपलब्ध होते. येथे 3000 हा तुम्ही मागितलेला port आहे. sandbox निष्क्रिय अवस्थेत असल्यास, पहिली request Traefik च्या catch-all वर जाते. sandboxd container सुरू करते, port कडून प्रतिसाद मिळेपर्यंत प्रतीक्षा करते आणि तुमच्या अॅपमध्ये refresh होणारे छोटे warming page दाखवते. Preview त्या page वरून पुढे जात नसेल, तर अॅपच्या sandbox.yaml मध्ये घोषित केलेल्या port वर आतील process listening करत नाही.

Preview साठी HTTPS असलेले प्रत्यक्ष domain वापरा

प्रत्येक sandbox ला स्वतंत्र hostname मिळतो, त्यामुळे एक wildcard DNS record सर्व sandbox साठी पुरेसा असतो. A record वापरून *.preview.yourdomain.com ला server च्या IP address कडे निर्देशित करा. त्यानंतर ~/.sandboxd/src मधील .env मध्ये preview variables सेट करा:

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 साठी स्वतंत्र certificate issuance करावी लागेल. त्यामुळे व्यस्त दुपारी वारंवार build केल्यास Let's Encrypt च्या rate limits लागू होऊ शकतात. DNS संदर्भातील माहितीसाठी DNS-01 challenge द्वारे wildcard certificates पहा.

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

Preview URLs आता https://s-<id>-3000.preview.yourdomain.com असतील. Firewall वर 80 आणि 443 उघडे ठेवा आणि 9090 सर्वांसाठी बंद ठेवा: मूलभूत ufw firewall नियम पहा. Preview hostname चा अंदाज लावू शकणारी कोणतीही व्यक्ती अॅप उघडू शकते, त्यामुळे previews सार्वजनिक आहेत असे समजा.

Domain, DNS आणि certificates पूर्णपणे टाळायचे असल्यास, maintainers आता sandboxd Cloud विकतात. ते तुमच्या server साठी sandboxd.io अंतर्गत सार्वजनिक HTTPS address देते. त्याची किंमत प्रति server दरमहा 9.99 dollars आहे; October 2026 पर्यंत launch discount मुळे ती 4.99 आहे. त्यावर अवलंबून राहण्यापूर्वी कोणता release आवश्यक आहे ते तपासा आणि v0.3.6 pin वापरा.

तयार झालेला कोड कुठे साठवला जातो आणि तो export करता येतो का?

Host वरील data directory मध्ये. v0.3.6 install मध्ये प्रत्येक workspace हा /var/lib/sandboxed/workspaces/<id>/ येथे असलेला साधा directory असतो आणि तो container मध्ये bind mount केलेला असतो. अॅपच्या files sandbox मधील /home/sandbox/workspace/app येथे असतात. Control plane state ही state/sandboxd.db येथील एकाच SQLite file मध्ये असते आणि encrypted agent credentials agent-auth/ येथे साठवले जातात. Container layer मध्ये काहीही लपवलेले नसते. त्यामुळे backup म्हणजे directory ची copy आणि ती database file. VPS वरील restic backups दोन्हींचे backup हाताळते.

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

Git export आधीपासून उपलब्ध आहे; तो वेगळा जोडलेला घटक नाही. API प्रथम status आणि diff वाचण्यासाठी उपलब्ध करून देते. त्यानंतर 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":"todo-first-pass"}'

Push नेहमी नवीन branch वर जातो. branch वगळल्यास default म्हणून sandboxd/<slug>-<shortsha> वापरले जाते. main, master आणि ज्या branch मधून import केले ती branch नाकारली जाते. त्यामुळे remote side वर merge करा.

Private remote साठी personal access token आवश्यक असतो. तो console मधील Settings, Git credentials येथे एकदाच सेट करा. तो encrypted स्वरूपात साठवला जातो आणि sandbox च्या बाहेर राहतो. त्यामुळे agent तो वाचू शकत नाही किंवा तुमच्या नकळत त्याचा वापर करून push करू शकत नाही. लवकर आणि वारंवार push करा. तसे न केल्यास workspace directory ही कोडची एकमेव copy राहते आणि DELETE /v1/apps/<id> ती कोणतीही दुसरी संधी न देता काढून टाकते.

मॉडेल tokens मध्ये build ची किंमत किती असते?

sandboxd तुमचा खर्च मोजत नाही. त्यामुळे महत्त्वाची संख्या तुमच्या provider च्या console मध्ये दिसते. मोफत OpenCode Zen models साठी कोणताही खर्च येत नाही. मात्र paid model च्या तुलनेत ते अधिक धीमे आणि कमी सक्षम असतात. toy app पेक्षा मोठ्या कोणत्याही कामात अधिक correction rounds लागतात. हे त्याचा परिणाम स्पष्टपणे दाखवते.

बिलाचा आकार agent loop कसा कार्य करतो यावर अवलंबून असतो. प्रत्येक turn मध्ये आवश्यक context पुन्हा पाठवला जातो. त्यामुळे खर्च apps च्या संख्येऐवजी turns च्या संख्येनुसार वाढतो. योग्य परिणाम देणारा एक prompt स्वस्त असतो. मात्र 50 files असलेल्या project वर "आता spacing दुरुस्त करा" अशा 15 rounds महाग ठरतात. कारण प्रत्येक वेळी file contents पुन्हा पाठवले जातात. Input आणि output tokens ची किंमत वेगवेगळी असते, आणि coding agent चा प्रत्येक session मधील खर्च याची वास्तववादी श्रेणी सांगते. unattended loop कडे keys सोपवण्यापूर्वी provider कडे hard spend limit निश्चित करा.

शिल्लक sandbox साफ करणे

idle reaper SANDBOXD_IDLE_THRESHOLD_SECONDS पेक्षा जास्त काळ idle असलेल्या कोणत्याही sandbox ला थांबवतो. SANDBOXD_IDLE_THRESHOLD_SECONDS ची default value 2100 seconds किंवा 35 minutes आहे. यामुळे RAM मोकळी होते आणि files जशाच्या तशा राहतात. Preview URL वर पुढील request आल्यावर container पुन्हा सुरू होतो. लहान मशीनवर ही value कमी ठेवा, कारण 35 minutes idle containers म्हणजे 35 minutes इतकी memory तुम्ही वापरू शकत नाही.

थांबवणे म्हणजे delete करणे नाही. Disk शांतपणे भरत जाण्याचे कारण हेच आहे. थांबवलेला sandbox अजूनही त्याचा workspace आणि container ठेवतो. App ठेवून sandbox काढणे म्हणजे sandbox वरील DELETE होय. यामुळे container आणि workspace दोन्ही काढले जातात. App काढल्यास सर्वकाही कायमचे काढले जाते.

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 image space दाखवेल. कारण प्रत्येक app ने स्वतःचा toolchain pull केल्यामुळे त्याचे layers मागे राहतात. docker image prune dangling layers काढतो. प्रथम GET /v1/apps तपासा, कारण sleeping sandbox कडून अजून referenced असलेली image garbage नसते.

कंटेनर boundary काय देते आणि काय देत नाही

प्रत्येक sandbox privileged नसलेल्या user म्हणून चालतो. त्याची root filesystem read only असते. सर्व Linux capabilities काढून टाकलेल्या असतात. no-new-privileges सेट केलेले असते. तसेच memory ceiling आणि process limit लागू असतात. हा प्रकल्प या मर्यादेबाबत स्पष्ट आहे: shared kernel असलेला Linux container हा मजबूत isolation boundary आहे, पण कमकुवत security boundary आहे. Kernel मधील bug मुळे host compromise होऊ शकतो.

दोन बाबींवर कृती करणे आवश्यक आहे. Self-hosted build मध्ये sandbox मधून बाहेर जाणारा network egress खुला असतो. त्यामुळे generated code इंटरनेट, तुमच्या local network आणि cloud metadata endpoints शी संपर्क साधू शकतो. Source मध्ये nftables egress subsystem उपलब्ध आहे. मात्र portable Docker Compose build मध्ये ते compile केलेले नसते. त्यामुळे हे निर्बंध तुमच्या host firewall कडून लागू करावे लागतात. Control plane API ला प्रत्यक्षात host root इतकेच अधिकार असतात, कारण ते Docker socket नियंत्रित करते. ते default ने 127.0.0.1:9090 वर bind होते. SANDBOXD_API_AUTH_DISABLED हे false राहणे आवश्यक आहे. ते इंटरनेटवर कधीही publish करू नये.

इतर लोकांना तुमच्या box वर prompts पाठवू देण्याचा विचार असल्यास, ही रचना एकटी पुरेशी सुरक्षित नाही. हा प्रकल्प SANDBOXD_RUNTIME=runsc सह gVisor वापरण्याचा निर्देश करतो. यामुळे sandbox आणि host यांच्या मध्ये userspace kernel ठेवला जातो. प्रकल्पाच्या स्वतःच्या मोजमापांनुसार package installs सुमारे 1.7 पट धीमे होतात आणि syscall-heavy काम सुमारे 4 पट धीमे होते. अधिक मजबूत उपाय म्हणजे प्रत्येक tenant साठी एक स्वतंत्र machine. हेच disposable VM मध्ये coding agents चालवण्यामागील कारण आहे.

दोन महिने जुन्या प्रकल्पावर आधारित बांधकाम करावे का?

वैयक्तिक build box साठी होय, मात्र स्पष्ट खबरदारी घ्या: SANDBOXD_REF pin करा, data directory चा backup घ्या (v0.3.6 वर /var/lib/sandboxed, तसेच v0.3.9 किंवा त्यानंतरच्या नवीन install वर /var/lib/sandboxd), आणि ज्या प्रत्येक app ची तुम्हाला काळजी आहे तो git remote वर push करा. ग्राहक वापरणार असलेल्या कोणत्याही गोष्टीसाठी 1.0 येईपर्यंत थांबा किंवा बदलांमुळे होणाऱ्या अडचणींसाठी बजेट ठेवा, कारण maintainers स्पष्टपणे सांगतात की 0.x मध्ये तुमच्या अपेक्षेविरुद्ध बदल होऊ शकतात. Maintainers managed install देखील विकतात. October 2026 पर्यंत त्याची setup किंमत 199 dollars आणि चालवण्यासाठी दरमहा 79 dollars आहे. प्रकल्प सुरू ठेवण्यामागे कारण आहे का, हे तपासताना ही माहिती उपयुक्त ठरते.

हा धोका स्वीकारता येण्याजोगा असण्याचे कारण म्हणजे त्यातून मिळणारे output. sandboxd सामान्य git repository मध्ये सामान्य application तयार करते. त्यामुळे प्रकल्प थांबला तरी code तुमच्याकडे राहतो आणि फक्त wrapper गमावता. तुमच्या प्रकल्पावर मालकी ठेवणाऱ्या hosted builder पेक्षा ही स्थिती खूपच चांगली आहे. या वर्षी तुमच्या server वर कोणत्या गोष्टी self-host करणे योग्य आहे, याचा व्यापक आढावा घेण्यासाठी 2026 मध्ये self-host करणे काय योग्य आहे हे पहा.

FAQ

sandboxd साठी किमान सर्व्हर तपशील कोणते आहेत?

प्रकल्पानुसार सुरुवातीस 2 vCPU आणि 4 GB RAM पुरेसे आहेत. यामध्ये control plane, Traefik आणि एक लहान sandbox चालतो. एकाच वेळी अनेक अॅप्स चालू ठेवायचे असल्यास 8 GB RAM आणि 40 GB disk वापरा. प्रत्येक चालू sandbox मध्ये संपूर्ण Node किंवा Python toolchain असतो आणि प्रत्येक workspace आपली स्वतंत्र dependency tree disk वर ठेवतो. Host कडे memory कमी पडल्यास sandboxd चा pressure reaper memory मोकळी करण्यासाठी sandboxes थांबवतो. एखाद्या build ने त्याच्या container ची memory ceiling ओलांडल्यास kernel तो process बंद करतो: docker ps -a मध्ये त्याचा exit code 137 दिसतो.

sandboxd हे Dify किंवा OpenHands पेक्षा कसे वेगळे आहे?

ती वेगवेगळे artifacts तयार करतात. Dify runtime वेळी model ला call करणारे applications तयार करते, जसे chat interfaces आणि retrieval pipelines. OpenHands तुमच्याकडे आधीपासून असलेला repository संपादित करते. ते commands चालवते आणि विद्यमान code मध्ये बदल सुचवते. sandboxd prompt वरून पूर्णपणे नवीन project ची संरचना तयार करते, तो स्वतःच्या container मध्ये build करते आणि preview URL वर serve करते. त्याचा परिणाम हा साधारण web application असतो आणि तो चालण्यासाठी model आवश्यक नसतो.

agent ने लिहिलेला code प्रत्यक्षात कुठे साठवला जातो?

तो container image मध्ये नाही, तर host filesystem वर साठवला जातो. v0.3.6 install मध्ये प्रत्येक app ला /var/lib/sandboxed/workspaces/<id>/ येथे directory मिळते. v0.3.9 किंवा त्यानंतरच्या fresh install मध्ये ती /var/lib/sandboxd/workspaces/<id>/ येथे असते. ही directory त्याच्या sandbox मध्ये bind mount केली जाते आणि files आत /home/sandbox/workspace/app येथे दिसतात. Control plane state त्याच data directory मधील state/ अंतर्गत असलेल्या एका SQLite file मध्ये साठवली जाते. Console च्या Git tab मधून किंवा /v1/apps/<id>/git/commit आणि /git/push endpoints द्वारे तुम्ही git remote वर नवीन branch ला commit आणि push करू शकता. Private remotes साठीचा token control plane encrypted स्वरूपात साठवतो; तो sandbox कडे दिला जात नाही.

sandboxd इंटरनेटसमोर उघडणे सुरक्षित आहे का?

Preview URLs आणि console उघडे ठेवा; control plane API कधीही उघडू नका. हे API host वरील Docker नियंत्रित करते, त्यामुळे त्याचे अधिकार root इतकेच आहेत. याच कारणामुळे ते default ने 127.0.0.1:9090 वर bind होते. Self-hosted build मध्ये sandboxes साठी network egress देखील खुले असते. त्यामुळे agent ने लिहिलेला code तुमच्या local network आणि cloud metadata endpoints पर्यंत पोहोचू शकतो. म्हणून त्या host जवळील इतर systems चे संरक्षण आवश्यक असल्यास host firewall rules जोडा. ज्यांच्यावर तुमचा विश्वास नाही अशा लोकांचे prompts चालवताना container boundary वर अवलंबून राहू नका. त्याऐवजी प्रत्येक tenant साठी स्वतंत्र host वापरा.