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 करत असतील, तर ते पुरेसे नाही. Memory चे वाटप भागांमध्ये करा. Traefik आणि Go control plane कमी memory वापरतात. प्रत्येक चालू sandbox मध्ये संपूर्ण Node किंवा Python toolchain असतो आणि कमाल वापर npm install नंतर production build चालू असताना होतो. काही अॅप्स चालू ठेवणाऱ्या मशीनसाठी 8 GB RAM चे नियोजन करा. Swap ला क्षमता म्हणून नव्हे, तर safety net म्हणून वापरा. Swap वर चालणाऱ्या build ला सेकंदांऐवजी अनेक मिनिटे लागू शकतात.

Memory संपल्यावर दोन वेगवेगळ्या प्रकारच्या त्रुटी येतात आणि त्या एकमेकांसारख्या दिसत नाहीत. Sandbox मध्ये container, sandboxd ने निश्चित केलेली hard --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 memory कमी झाल्यावर sandboxd pressure reaper चालवतो आणि sandbox थांबवतो. त्यामुळे लहान मशीनवर तुम्ही preview पाहत असताना sandbox अदृश्य होऊ शकतो. Files सुरक्षित राहतात आणि preview URL ला केलेली पुढील request ते पुन्हा सुरू करते. मात्र container थांबला त्या वेळी चालू असलेले task पुन्हा सुरू होत नाही.

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

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

Default data directory /var/lib/sandboxed आहे आणि त्यात अतिरिक्त e आहे. /var/lib/sandboxd टाइप केल्यास रिकामी directory दिसते आणि पुढील पाच मिनिटे गोंधळात जातात.

pinned sandboxd release स्थापित करा

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

docker compose version
git --version

दोन्ही आदेशांनी version दाखवणे आवश्यक आहे. docker: 'compose' is not a docker command याचा अर्थ जुना standalone docker-compose binary उपलब्ध आहे. Installer ला v2 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 झालेला code तुमच्या install मध्ये येईल. जुलै 2026 मध्ये या project ने एकट्या महिन्यात सहा releases काढले असल्यामुळे हा फरक महत्त्वाचा आहे. Version pin करा. Changelog वाचल्यानंतरच जाणीवपूर्वक upgrade करा.

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

curl http://127.0.0.1:9090/healthz

Control plane सुरू असल्यास हा आदेश ok दाखवतो. काहीही दाखवत नसेल, तर stack सुरू झालेला नाही. कोणती service बंद आहे हे पाहण्यासाठी ~/.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 करत नाही.

पूर्वावलोकने HTTPS असलेल्या वास्तविक domain वर ठेवा

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

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

Traefik मध्ये यासाठी संबंधित भागही configure करावा लागतो. traefik/traefik.yml मध्ये websecure entrypoint enable करा आणि certificate resolver जोडा. DNS-01 challenge वापरा. त्यामुळे एक wildcard certificate सर्व preview hostname साठी लागू होते. HTTP-01 वापरल्यास प्रत्येक नवीन sandbox साठी स्वतंत्र issuance करावे लागेल. व्यस्त वेळी वारंवार build केल्यास Let's Encrypt च्या rate limits लागू होऊ शकतात. DNS-01 challenge वापरून wildcard certificates मध्ये DNS configuration दिले आहे.

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

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

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

Host वर, data directory अंतर्गत. प्रत्येक workspace हा /var/lib/sandboxed/workspaces/<id>/ येथे असलेला साधा directory असतो आणि तो container मध्ये bind mount केला जातो. App च्या 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 हे दोन्ही हाताळते.

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":"main"}'

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 नसते.

कंटेनरची सीमा कोणते संरक्षण देते आणि कोणते देत नाही

प्रत्येक sandbox एक unprivileged 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 पाठवू देण्याचा विचार असल्यास, हे model स्वतःपुरते पुरेसे सुरक्षित नाही. प्रकल्प SANDBOXD_RUNTIME=runsc सह gVisor सुचवतो. यामध्ये sandbox आणि host यांच्या मध्ये userspace kernel ठेवला जातो. त्यामुळे syscall-heavy काम साधारणपणे 1.7 ते 4 पट धीमे होते. अधिक मजबूत उपाय म्हणजे प्रत्येक tenant साठी एक स्वतंत्र machine वापरणे. coding agents disposable VM मध्ये चालवण्यामागील हाच युक्तिवाद आहे.

दोन महिन्यांपूर्वीच्या प्रकल्पावर आधारित काम करावे का?

वैयक्तिक build box साठी, होय. मात्र स्पष्ट खबरदारी घ्या: SANDBOXD_REF pin करा, /var/lib/sandboxed चा backup घ्या आणि ज्या प्रत्येक अॅपची तुम्हाला गरज आहे ते git remote वर push करा. ग्राहक वापरणार असलेल्या कोणत्याही गोष्टीसाठी 1.0 आवृत्तीची प्रतीक्षा करा किंवा बदलांमुळे होणाऱ्या अडचणींसाठी बजेट ठेवा, कारण maintainers स्पष्टपणे सांगतात की 0.x आवृत्तीत तुमच्या नकळत बदल होऊ शकतात. August 2026 पर्यंत maintainers 79 dollars प्रति महिना managed install देखील विकतात. प्रकल्प सुरू ठेवण्याचे कारण आहे का हे ठरवताना ही माहिती उपयुक्त ठरते.

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

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 पेक्षा जास्त memory वापरत असल्यास kernel तो बंद करतो: docker ps -a मध्ये त्याचा exit code 137 दिसतो.

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

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

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

तो container image मध्ये नसून host filesystem वर साठवला जातो. प्रत्येक app साठी /var/lib/sandboxed/workspaces/<id>/ येथे एक directory तयार केली जाते. ती directory bind mount द्वारे त्याच्या sandbox मध्ये जोडली जाते आणि 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 वर commit आणि push करू शकता. Private remotes साठीचा token sandbox कडे देण्याऐवजी control plane द्वारे encrypted स्वरूपात साठवला जातो.

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

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