VPSలో sandboxdని సొంతంగా హోస్ట్ చేయడం ఎలా?

sandboxd అంటే ఏమిటి మరియు దానిని మీరే సొంతంగా రన్ చేయడం వల్ల కలిగే ప్రయోజనాలు

sandboxd ను self-host చేయడానికి మీకు Docker ఉన్న ఒక Linux సర్వర్ మరియు ఒక domain name అవసరం. మీరు ఒక prompt పంపినప్పుడు, ఒక coding agent ఐసోలేటెడ్ కంటైనర్ లోపల ఒక నిజమైన అప్లికేషన్‌ను నిర్మిస్తుంది, ఆ అప్లికేషన్ దాని స్వంత preview URL వద్ద అందుబాటులోకి వస్తుంది. 2026లో Prompt-to-app బిల్డర్లు అత్యంత ప్రాచుర్యం పొందిన hosted కేటగిరీగా ఉన్నాయి, మరియు sandboxd అనేది మీ VPSపై, MIT లైసెన్స్ కింద రన్ అయ్యే సాఫ్ట్‌వేర్; దీని ద్వారా తయారైన కోడ్ మీ స్వంత డిస్క్‌లోనే ఉంటుంది.

దీని డిజైన్ ఉద్దేశపూర్వకంగానే చిన్నదిగా ఉంచబడింది. ఒక Go control plane Docker ను నడిపిస్తుంది, Traefik v3 ప్రతి preview hostname ను రూట్ చేస్తుంది, SQLite స్టేట్‌ను భద్రపరుస్తుంది, మరియు ప్రతి అప్లికేషన్ ఒక కంటైనర్ లోపల రన్ అవుతుంది. ఇందులో Kubernetes లేదు మరియు ప్రత్యేకమైన database సర్వర్ కూడా లేదు, అందుకే ఇది 2 vCPU ఉన్న సర్వర్‌పై కూడా రన్ అవ్వగలదు.

నాలుగు ఆబ్జెక్టులు మొత్తం మోడల్‌ను నడిపిస్తాయి. ఒక app అనేది శాశ్వత ప్రాజెక్ట్, ఇది దాని పేరు, git మెటాడేటా మరియు secrets ను కలిగి ఉంటుంది. ఒక sandbox అనేది అప్లికేషన్ రన్ అయ్యే Docker కంటైనర్, మరియు ఒక app ఒక సమయంలో ఒక sandbox కు మాత్రమే అనుసంధానించబడి ఉంటుంది. ఒక workspace అనేది అప్లికేషన్ యొక్క ఫైళ్లు, ఇవి హోస్ట్ మెషీన్‌పై ఉంటాయి మరియు కంటైనర్ ఆగిపోయినా అలాగే ఉంటాయి. ఒక task అనేది sandbox లోపల ఉన్న agent కు పంపబడే ఒక prompt. ఒక sandbox ను ఆపడం వల్ల మెమరీ ఖాళీ అవుతుంది కానీ ఫైళ్లు అలాగే ఉంటాయి. దానిని destroy చేయడం వల్ల కంటైనర్ తొలగించబడుతుంది, ఆ తర్వాత app కొత్త దానిని boot చేయగలదు.

sandboxd, Dify మరియు OpenHands ల మధ్య తేడాలు ఏమిటి?

ఈ మూడూ మీ సర్వర్‌పై LLM (large language model) ను రన్ చేస్తాయి కాబట్టి వీటి మధ్య గందరగోళం ఏర్పడుతుంది, కానీ వీటి ద్వారా వచ్చే ఫలితాలు వేరుగా ఉంటాయి. Dify LLM అప్లికేషన్లను నిర్మిస్తుంది: ఎవరైనా ఉపయోగించిన ప్రతిసారీ మోడల్‌ను పిలిచే చాట్ ఇంటర్‌ఫేస్‌లు, రిట్రీవల్ పైప్‌లైన్‌లు మరియు వర్క్‌ఫ్లోలను ఇది రూపొందిస్తుంది. మోడల్ అనేది తయారైన ఉత్పత్తిలో ఒక భాగంగా ఉంటుంది. OpenHands ఇప్పటికే ఉన్న రిపోజిటరీపై పనిచేస్తుంది: మీరు దీన్ని మీ కోడ్‌కు పాయింట్ చేసినప్పుడు, అది ఫైళ్లను చదువుతుంది, కమాండ్లను రన్ చేస్తుంది మరియు మార్పులను సూచిస్తుంది. sandboxd సున్నా నుండి మొదలవుతుంది. ఇది ఒక preset నుండి ప్రాజెక్ట్‌ను సిద్ధం చేసి, కొత్త కంటైనర్‌లో బిల్డ్ చేసి, మీరు చూడటానికి ఒక 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 జూన్ 2026న సృష్టించబడింది, కాబట్టి ఆగస్టు 2026 నాటికి దీనికి రెండు నెలల వయస్సు ఉంది. అదే సమయంలో OpenHands మార్చి 2024 నుండి, Dify ఏప్రిల్ 2023 నుండి అందుబాటులో ఉన్నాయి. v0.1.0 రిలీజ్ 6 జూన్ 2026న మరియు v0.3.6 రిలీజ్ 1 ఆగస్టు 2026న విడుదలయ్యాయి. ఈ ప్రాజెక్ట్ తనను తాను బీటా అని పిలుచుకుంటుంది మరియు 0.x రిలీజ్‌లు అనుకూలతను దెబ్బతీసే అవకాశం ఉందని పేర్కొంది. ఈ సంఖ్యలను నాణ్యతకు కొలమానంగా కాకుండా, డిపెండెన్సీ రిస్క్‌గా పరిగణించండి: రెండు నెలల వయస్సు ఉన్న ప్రాజెక్ట్‌లో ఇతరులు బగ్‌లను కనుగొనడానికి కేవలం రెండు నెలల సమయం మాత్రమే లభించింది.

సర్వర్‌కు అవసరమైన వనరులు, అవి తక్కువైతే ఏర్పడే సమస్యలు

ప్రారంభించడానికి 2 vCPU మరియు 4 GB RAM సరిపోతాయని ప్రాజెక్ట్ పేర్కొంటుంది. control plane తో పాటు ఒక చిన్న sandbox నడిపేందుకు ఇది సరైనదే. అయితే ఒకేసారి ఇద్దరు వ్యక్తులు build చేస్తే ఇది సరిపోదు. Memory ను భాగాలుగా అంచనా వేయండి. Traefik మరియు Go control plane తక్కువ memory ఉపయోగిస్తాయి. ప్రతి running sandbox లో పూర్తి Node లేదా Python toolchain ఉంటుంది. npm install తర్వాత production build జరిగే సమయంలో memory వినియోగం గరిష్ఠానికి చేరుతుంది. కొన్ని అప్లికేషన్లను నిరంతరం నడిపే server కోసం 8 GB RAM ను ప్రణాళికలో ఉంచండి. Swap ను capacity గా కాకుండా safety net గా పరిగణించండి. Swap ఉపయోగించే build కు seconds బదులు minutes పడతాయి.

Memory అయిపోయినప్పుడు రెండు రకాల వైఫల్యాలు ఏర్పడతాయి. అవి ఒకేలా కనిపించవు. Sandbox లో container, sandboxd నిర్దేశించిన hard --memory పరిమితిని చేరుతుంది. అప్పుడు kernel అత్యధిక memory ఉపయోగిస్తున్న process ను terminate చేస్తుంది. అందువల్ల agent నుంచి ఉపయోగకరమైన message లేకుండానే 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 ను అమలు చేసి sandboxes ను ఆపుతుంది. అందువల్ల చిన్న server పై preview ను చూస్తున్న సమయంలో sandbox అదృశ్యమవచ్చు. Files సురక్షితంగానే ఉంటాయి. Preview URL కు తదుపరి request పంపితే sandbox మళ్లీ ప్రారంభమవుతుంది. అయితే container ఆగిన సమయంలో నడుస్తున్న task తిరిగి కొనసాగదు.

Disk సమస్య సాధారణంగా నెమ్మదిగా బయటపడుతుంది. ప్రతి app తన workspace ను host పై ఉంచుతుంది. JavaScript project లో dependencies కోసం వందల megabytes పరిమాణం గల node_modules tree ఉంటుంది. Images ను లెక్కలోకి తీసుకోకముందే పది apps కు అనేక gigabytes dependencies అవసరం అవుతాయి. 40 GB తో ప్రారంభించి దీన్ని monitor చేయండి:

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

ఈ guide నిర్దేశించే release అయిన v0.3.6 లో default data directory /var/lib/sandboxed. ఇందులో అదనపు e ఉంటుంది. అక్కడ /var/lib/sandboxd టైప్ చేస్తే ఏమీ కనిపించదు. దీనివల్ల సమస్యను అర్థం చేసుకోవడానికి ఐదు minutes వరకు పట్టవచ్చు. ఇది v0.3.9 (25 August 2026) లో మారింది. కొత్త installers తాజా installations ను /var/lib/sandboxd లో ఉంచుతాయి. ఇప్పటికే అక్కడ ఉన్న installation కోసం మాత్రమే /var/lib/sandboxed ను ఉపయోగిస్తాయి. తరువాతి release తో మొదటిసారి setup చేసిన server పై, దిగువన ఉన్న ప్రతి command లో e లేని path ను ఉపయోగించండి.

స్థిరపరచిన sandboxd విడుదలను ఇన్‌స్టాల్ చేయండి

Docker Engine, Compose plugin, అలాగే git ముందుగా సర్వర్‌లో ఉండాలి. VPSలో Dockerను ఇన్‌స్టాల్ చేయడం ఆ భాగాన్ని వివరిస్తుంది.

docker compose version
git --version

రెండూ version ను ప్రింట్ చేయాలి. docker: 'compose' is not a docker command కనిపిస్తే Compose v2 plugin లేదు. Installer ముందుగా 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 విలువ main. దీన్ని unset గా వదిలేస్తే, ఆ ఉదయం merge అయిన code ఆధారంగా మీ installation మారుతుంది. జూలై 2026లో మాత్రమే ఆ project ఆరు releases విడుదల చేసినందున ఇది ముఖ్యమైన విషయం. Version ను pin చేయండి. Changelog చదివిన తర్వాత ఉద్దేశపూర్వకంగా upgrade చేయండి. 12 October 2026 నాటికి తాజా release v0.3.22. ఇది ఇక్కడ pin చేసిన v0.3.6 కంటే పదహారు releases ముందుంది.

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 down అయిందో చూడటానికి ~/.sandboxd/src నుంచి docker compose ps ను అమలు చేయండి. కారణం తెలుసుకోవడానికి తరువాత docker compose logs sandboxd ను అమలు చేయండి.

రిమోట్ సర్వర్‌లోని కన్సోల్‌ను చేరుకోవడం

కన్సోల్ Traefik ద్వారా HTTP_PORT పోర్ట్‌లో అందుబాటులో ఉంటుంది, ఇది డిఫాల్ట్‌గా 80వ పోర్ట్, మరియు దీని hostname 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 యొక్క కీ-రహిత ఉచిత మోడళ్లపై రన్ అవుతాయి. కాబట్టి మీ మొదటి బిల్డ్ ఉచితంగా పూర్తవుతుంది మరియు మీరు ఎటువంటి ఖర్చు లేకుండా మొత్తం లూప్‌ను పరీక్షించుకోవచ్చు.

మీకు మరింత శక్తివంతమైన మోడల్ కావాలనుకున్నప్పుడు మీ స్వంత కీని కనెక్ట్ చేయండి. కీలు కంట్రోల్ ప్లేన్‌కు మాత్రమే వెళ్తాయి, శాండ్‌బాక్స్‌లోకి ఎప్పటికీ వెళ్లవు: అవి డేటా డైరెక్టరీలో ఎన్‌క్రిప్ట్ చేయబడి భద్రపరచబడతాయి మరియు క్రెడెన్షియల్ ప్రాక్సీ ద్వారా నెట్‌వర్క్ వైర్ ద్వారా పంపబడతాయి. కాబట్టి ఏజెంట్ గానీ, అది రాసే కోడ్ గానీ వాటిని చదవలేవు.

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 విభాగంలో కూడా ఇదే ప్రక్రియ ఉంటుంది. మీరు API కీకి బదులుగా Claude సబ్‌స్క్రిప్షన్‌ను ఉపయోగించాలనుకుంటే, ఇందులో గైడెడ్ OAuth ఫ్లో కూడా అందుబాటులో ఉంటుంది. ప్రతి ఏజెంట్‌కు సంబంధించిన డిఫాల్ట్ మోడల్ అదే ప్యానెల్‌లో ఉంటుంది, అయితే ఒకే టాస్క్ కోసం దానిని మార్చుకోవచ్చు (override చేయవచ్చు).

ఒక చిన్న అప్లికేషన్‌ను పూర్తిగా నిర్మించండి

అప్లికేషన్‌ను సృష్టించి, దాని sandbox ను బూట్ చేయండి, ఆపై ఒక ప్రాంప్ట్‌ను పంపండి. ఐడిలు (ids) JSON రూపంలో తిరిగి వస్తాయి, మరియు క్విక్‌స్టార్ట్ వాటిని 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"

రెండు వేరియబుల్స్ తప్పనిసరిగా ఒక ఐడిని కలిగి ఉండాలి. $SB ఖాళీగా ఉందంటే sandbox బూట్ కాలేదని అర్థం; సాధారణంగా బేస్ ఇమేజ్ ఇంకా బిల్డ్ అవుతుండటం లేదా హోస్ట్ మెమరీ అయిపోవడం దీనికి కారణం. ఐడికి బదులుగా 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"}'

ప్రతిస్పందన ఒక టాస్క్ ఐడిని కలిగి ఉంటుంది. GET /v1/sandboxes/$SB/tasks/<task id> దాని ఫలితాన్ని తిరిగి ఇస్తుంది, మరియు అదే టాస్క్‌పై ఉన్న /events పాత్ ఏజెంట్ ఏమి చేస్తుందో తెలిపే లైవ్ SSE (server sent events) స్ట్రీమ్. కన్సోల్ అదే స్ట్రీమ్‌ను చాట్ రూపంలో చూపిస్తుంది.

అప్లికేషన్ అప్పుడు http://s-<sandbox id>-3000.preview.localhost వద్ద ఉంటుంది, ఇక్కడ 3000 అనేది మీరు కోరిన పోర్ట్. ఒకవేళ sandbox నిద్రపోతుంటే (asleep), మొదటి అభ్యర్థన Traefik యొక్క catch-all కు చేరుతుంది, sandboxd కంటైనర్‌ను ప్రారంభిస్తుంది, పోర్ట్ స్పందించే వరకు వేచి ఉంటుంది, మరియు మీ అప్లికేషన్‌కు రీఫ్రెష్ అయ్యే ఒక చిన్న వార్మింగ్ పేజీని చూపిస్తుంది. ప్రివ్యూ ఆ పేజీని దాటి ముందుకు వెళ్లడం లేదంటే, అప్లికేషన్ యొక్క sandbox.yaml లో ప్రకటించిన పోర్ట్‌పై లోపల ఉన్న ప్రాసెస్ వినడం లేదని (listening) అర్థం.

HTTPS‌తో previews ను నిజమైన domain పై ఉంచడం

ప్రతి sandbox కు ప్రత్యేక hostname ఉంటుంది. అందువల్ల ఒక wildcard DNS record వాటన్నింటికీ సరిపోతుంది. A record ద్వారా *.preview.yourdomain.com ను server IP address కు point చేయండి. తరువాత ~/.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 అవసరం అవుతుంది. నిర్మాణ పనులు ఎక్కువగా జరిగే సమయంలో ఇది నేరుగా 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 ను open చేసి, 9090 ను బాహ్య ప్రపంచానికి closed గా ఉంచండి: ప్రాథమిక ufw firewall నియమాలు చూడండి. Preview hostname ను ఊహించగల ఎవరైనా app ను load చేయగలరని గుర్తుంచుకోండి. అందువల్ల previews ను public గా పరిగణించండి.

Domain, DNS మరియు certificates అన్నింటినీ వదిలివేయాలనుకుంటే, maintainers ఇప్పుడు sandboxd Cloud ను విక్రయిస్తున్నారు. ఇది మీ server కు sandboxd.io కింద public HTTPS address ను అందిస్తుంది. దీని ధర server కు నెలకు 9.99 dollars, లేదా launch discount తో 4.99. ఈ సమాచారం October 2026 నాటిది. దానిపై ఆధారపడే ముందు అవసరమైన release ను v0.3.6 pin ద్వారా నిర్ధారించండి.

రూపొందించిన కోడ్ ఎక్కడ ఉంటుంది? దాన్ని export చేయవచ్చా?

Hostలోని data directory కింద ఉంటుంది. v0.3.6 installలో ప్రతి workspace, /var/lib/sandboxed/workspaces/<id>/ వద్ద ఉన్న సాధారణ directoryగా ఉంటుంది. ఇది containerలో 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":"todo-first-pass"}'

Push ఎల్లప్పుడూ కొత్త branchకు వెళ్తుంది. branch ఇవ్వకపోతే, అది స్వయంచాలకంగా sandboxd/<slug>-<shortsha>కు default అవుతుంది. main, master మరియు మీరు import చేసిన branchను తిరస్కరిస్తుంది. కాబట్టి remote వైపున merge చేయాలి.

Private remoteకు personal access token అవసరం. దీన్ని consoleలో Settings, Git credentials కింద ఒకసారి సెట్ చేయాలి. ఇది encryptedగా నిల్వ చేయబడుతుంది. ఇది sandboxకు బయట ఉంటుంది. అందువల్ల agent దీన్ని చదవలేడు లేదా మీకు తెలియకుండా దానితో push చేయలేడు. తరచుగా push చేయండి. మీరు push చేసే వరకు workspace directory మాత్రమే code యొక్క copyగా ఉంటుంది. DELETE /v1/apps/<id> దాన్ని రెండో అవకాశం లేకుండా తొలగిస్తుంది.

బిల్డ్ చేయడానికి మోడల్ టోకెన్ల పరంగా ఎంత ఖర్చవుతుంది?

sandboxd మీ ఖర్చును లెక్కించదు, కాబట్టి మీ ప్రొవైడర్ కన్సోల్‌లో ఉన్న సంఖ్యే ప్రామాణికం. ఉచిత OpenCode Zen మోడల్స్‌కు ఎటువంటి ఖర్చు ఉండదు, కానీ ఇవి పెయిడ్ మోడల్స్ కంటే నెమ్మదిగా మరియు తక్కువ సామర్థ్యం కలిగి ఉంటాయి; చిన్న అప్లికేషన్లు కాకుండా వేటికైనా ఇవి ఎక్కువ సార్లు సరిదిద్దాల్సి వస్తుంది.

బిల్లు మొత్తం ఏజెంట్ లూప్ ఎలా పనిచేస్తుందనే దానిపై ఆధారపడి ఉంటుంది. ప్రతి టర్న్ (turn) తనకు అవసరమైన కాంటెక్స్ట్‌ను మళ్ళీ పంపుతుంది, కాబట్టి ఖర్చు అనేది అప్లికేషన్ల సంఖ్యపై కాకుండా, టర్న్ల సంఖ్యపై ఆధారపడి ఉంటుంది. ఒక ప్రాంప్ట్ పంపడం చౌకగానే ఉంటుంది. యాభై ఫైళ్లు ఉన్న ప్రాజెక్ట్‌లో "ఇప్పుడు స్పేసింగ్‌ను సరిచేయి" అని పదిహేను సార్లు అడిగితే ఖర్చు పెరుగుతుంది, ఎందుకంటే ప్రతిసారీ ఫైల్ కంటెంట్ కూడా పంపబడుతుంది. ఇన్‌పుట్ మరియు అవుట్‌పుట్ టోకెన్లకు వేర్వేరు ధరలు ఉంటాయి, మరియు ఒక కోడింగ్ ఏజెంట్‌కు సెషన్‌కు ఎంత ఖర్చవుతుందో చూస్తే వాస్తవిక ధరల పరిధి అర్థమవుతుంది. పర్యవేక్షణ లేని లూప్‌ను రన్ చేసే ముందు, ప్రొవైడర్ వద్ద ఖర్చుపై ఒక గరిష్ట పరిమితిని (hard spend limit) సెట్ చేయండి.

పాతబడిన (stale) శాండ్‌బాక్స్‌లను తొలగించడం

idle reaper, SANDBOXD_IDLE_THRESHOLD_SECONDS దాటి నిష్క్రియంగా ఉన్న ఏ శాండ్‌బాక్స్‌నైనా ఆపివేస్తుంది. ఇది డిఫాల్ట్‌గా 2100 సెకన్లు లేదా 35 నిమిషాలకు సెట్ చేయబడి ఉంటుంది. ఇది RAMను తిరిగి విడుదల చేస్తుంది మరియు ఫైళ్లను అలాగే ఉంచుతుంది; ఆ తర్వాత preview URLకి వచ్చే తదుపరి అభ్యర్థన కంటైనర్‌ను తిరిగి మేల్కొల్పుతుంది. తక్కువ సామర్థ్యం గల సర్వర్లలో దీనిని తగ్గించండి, ఎందుకంటే 35 నిమిషాల పాటు నిష్క్రియంగా ఉన్న కంటైనర్లు మీరు ఉపయోగించలేని 35 నిమిషాల మెమరీని వృథా చేస్తాయి.

ఆపివేయడం అంటే తొలగించడం కాదు, ఇక్కడే డిస్క్ స్పేస్ నిశ్శబ్దంగా నిండిపోతుంది. ఆపివేయబడిన శాండ్‌బాక్స్ తన వర్క్‌స్పేస్‌ను మరియు కంటైనర్‌ను ఇంకా కలిగి ఉంటుంది. శాండ్‌బాక్స్‌ను తొలగించి, అప్లికేషన్‌ను అలాగే ఉంచడం అనేది శాండ్‌బాక్స్‌పై చేసే 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ని తనిఖీ చేయండి, ఎందుకంటే స్లీపింగ్ శాండ్‌బాక్స్ ద్వారా ఇంకా రిఫరెన్స్ చేయబడుతున్న ఇమేజ్ గార్బేజ్ (చెత్త) కిందకు రాదు.

కంటైనర్ boundary మీకు అందించేది, అందించనిది

ప్రతి sandbox, read-only root filesystem, తొలగించిన అన్ని Linux capabilities, సెట్ చేసిన no-new-privileges, memory ceiling మరియు process limit తో unprivileged user గా నడుస్తుంది. దీనికి ఉన్న పరిమితిని project స్పష్టంగా పేర్కొంటుంది: shared kernel Linux container బలమైన isolation boundary, కానీ బలహీనమైన security boundary. Kernel లోని bug వల్ల host compromise కావచ్చు.

రెండు విషయాలపై తప్పనిసరిగా చర్య తీసుకోవాలి. Self-hosted build లో sandbox నుంచి network egress తెరిచి ఉంటుంది. అందువల్ల generated code internet, మీ 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 గానే ఉండాలి. దీన్ని internet కు ఎప్పుడూ publish చేయకూడదు.

ఇతరులు మీ box కు prompts పంపేలా అనుకుంటే, ఈ model ఒక్కటే సరిపోదు. Project SANDBOXD_RUNTIME=runsc తో gVisor ను సూచిస్తుంది. ఇది sandbox మరియు host మధ్య userspace kernel ను ఉంచుతుంది. Project స్వంత measurements ప్రకారం, దీనివల్ల package installs సుమారు 1.7 రెట్లు నెమ్మదిగా, syscall-heavy పనులు సుమారు 4 రెట్లు నెమ్మదిగా జరుగుతాయి. మరింత బలమైన పరిష్కారం ప్రతి tenant కు ఒక machine కేటాయించడం. ఇది coding agents ను disposable VM లో నడపడం అనే వాదనతో సమానం.

రెండు నెలల పాత project పై build చేయాలా?

వ్యక్తిగత build box కోసం అయితే చేయవచ్చు. అయితే కొన్ని స్పష్టమైన జాగ్రత్తలు తీసుకోవాలి: SANDBOXD_REF ను pin చేయండి, data directory (v0.3.6 లో /var/lib/sandboxed, v0.3.9 లేదా ఆ తర్వాతి తాజా install లో /var/lib/sandboxd) ను backup చేయండి, అలాగే మీరు ముఖ్యంగా భావించే ప్రతి app ను git remote కు push చేయండి. కస్టమర్ ఉపయోగించే ఏదైనా వ్యవస్థ కోసం 1.0 వచ్చే వరకు వేచి ఉండండి లేదా breakage కోసం బడ్జెట్ కేటాయించండి. ఎందుకంటే 0.x వెర్షన్లలో మీపై ఆధారపడే విధానం మారవచ్చని maintainers స్పష్టంగా చెబుతున్నారు. Maintainers managed install ను కూడా అందిస్తున్నారు. October 2026 నాటికి setup కోసం 199 dollars, నిర్వహణ కోసం నెలకు 79 dollars వసూలు చేస్తున్నారు. Project కొనసాగడానికి ఆర్థిక కారణం ఉందా అని అంచనా వేస్తున్నప్పుడు ఈ విషయం ఉపయోగకరంగా ఉంటుంది.

ఈ ప్రమాదాన్ని భరించగల కారణం దాని output. sandboxd సాధారణ git repository లో సాధారణ application ను సృష్టిస్తుంది. అందువల్ల project నిలిచిపోయినా code మీ వద్దే ఉంటుంది; కోల్పోయేది wrapper మాత్రమే. మీ project పై పూర్తి నియంత్రణ కలిగిన hosted builder కంటే ఇది మెరుగైన స్థితి. ఈ సంవత్సరం మీ server లో ఏవి self-hosting కు తగినవో విస్తృతంగా తెలుసుకోవడానికి 2026లో self-hosting చేయడం విలువైనవి ఏమిటి చూడండి.

FAQ

sandboxd కోసం కనీస server specs ఏమిటి?

ప్రాజెక్ట్ ప్రకారం ప్రారంభించడానికి 2 vCPU మరియు 4 GB RAM సరిపోతాయి. ఇవి control plane, Traefik మరియు ఒక చిన్న sandbox ను నడపడానికి సరిపోతాయి. ఒకేసారి అనేక apps నడపాలనుకుంటే 8 GB RAM మరియు 40 GB disk ఉపయోగించండి. ప్రతి running sandbox లో పూర్తి Node లేదా Python toolchain ఉంటుంది. ప్రతి workspace తన dependency tree ను disk పై ఉంచుతుంది. Host వద్ద వనరులు తగ్గితే, memory ను విడుదల చేయడానికి sandboxd యొక్క pressure reaper sandboxes ను ఆపుతుంది. ఏదైనా build తన container memory ceiling ను మించితే, kernel దాన్ని terminate చేస్తుంది: దాని కోసం docker ps -a exit code 137 చూపిస్తుంది.

sandboxd, Dify లేదా OpenHands కంటే ఎలా భిన్నంగా ఉంటుంది?

ఇవి వేర్వేరు artifacts ను ఉత్పత్తి చేస్తాయి. Dify runtime సమయంలో model ను పిలిచే applications ను నిర్మిస్తుంది. ఉదాహరణకు, chat interfaces మరియు retrieval pipelines. OpenHands మీ వద్ద ఇప్పటికే ఉన్న repository ను సవరిస్తుంది. ఇది commands ను నడిపి, ఉన్న code కు మార్పులను ప్రతిపాదిస్తుంది. sandboxd prompt ఆధారంగా పూర్తిగా కొత్త project కు scaffold ను రూపొందిస్తుంది. ఇది ఆ project ను తన స్వంత container లో build చేసి, preview URL వద్ద serve చేస్తుంది. ఫలితంగా వచ్చే ordinary web application నడవడానికి model అవసరం లేదు.

agent రాసే code వాస్తవంగా ఎక్కడ ఉంటుంది?

అది container image లో కాకుండా host filesystem పై ఉంటుంది. v0.3.6 install లో ప్రతి app కు /var/lib/sandboxed/workspaces/<id>/ వద్ద ఒక directory లభిస్తుంది. v0.3.9 లేదా తదుపరి version ను fresh install చేస్తే ఆ directory /var/lib/sandboxd/workspaces/<id>/ వద్ద ఉంటుంది. ఈ directory sandbox లోకి bind mount అవుతుంది. అందులోని files sandbox లో /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 ను internet కు expose చేయడం సురక్షితమేనా?

Preview URLs మరియు console ను మాత్రమే expose చేయండి. Control plane API ను ఎప్పుడూ expose చేయవద్దు. ఆ API host పై Docker ను నియంత్రిస్తుంది. అందువల్ల దానికి root స్థాయి అధికారం సమానం. ఇదే కారణంగా అది default గా 127.0.0.1:9090 కు bind అవుతుంది. Self-hosted build లో sandboxes కు network egress కూడా open గా ఉంటుంది. అంటే agent రాసే code మీ local network మరియు cloud metadata endpoints ను చేరుకోగలదు. కాబట్టి ఆ host కు రక్షించాల్సిన ఇతర systems ఉంటే host firewall rules జోడించండి. మీరు విశ్వసించని వ్యక్తుల prompts ను అమలు చేసేటప్పుడు container boundary పై మాత్రమే ఆధారపడకుండా, ప్రతి tenant కోసం ఒక ప్రత్యేక host ను ఉపయోగించండి.