VPS پر sandboxd خود چلانے کا مکمل طریقہ

sandboxd کیا ہے، اور اسے خود چلانے سے آپ کو کیا حاصل ہوتا ہے

sandboxd کو self-host کرنے کے لیے آپ کو Docker کے ساتھ ایک Linux server اور ایک domain name درکار ہے۔ آپ ایک prompt بھیجتے ہیں، coding agent ایک isolated container کے اندر حقیقی application بناتا ہے، اور وہ application اپنی preview URL پر دستیاب ہو جاتی ہے۔ Prompt-to-app builders 2026 کی سب سے نمایاں hosted category ہیں، جبکہ sandboxd وہ سروس ہے جو آپ کے VPS پر، MIT licence کے تحت چلتی ہے اور جس کا تیار کردہ code آپ کی اپنی disk پر محفوظ رہتا ہے۔

اس design کو دانستہ طور پر چھوٹا رکھا گیا ہے۔ Go control plane، Docker کو چلاتا ہے؛ Traefik v3 ہر preview hostname کو route کرتا ہے؛ SQLite state محفوظ کرتا ہے؛ اور ہر app ایک container کے اندر چلتی ہے۔ Kubernetes اور الگ database server کی ضرورت نہیں ہوتی، اسی لیے 2 vCPU والا server بھی اسے چلا سکتا ہے۔

پورے model کو چار objects سنبھالتے ہیں۔ app مستقل project ہوتا ہے، جس میں اس کا name، git metadata اور secrets محفوظ ہوتے ہیں۔ sandbox وہ Docker container ہے جس میں app چلتی ہے، اور ایک app ایک وقت میں ایک sandbox سے منسلک ہوتی ہے۔ workspace app کی files ہوتی ہیں، جو host پر محفوظ رہتی ہیں اور container کے بعد بھی موجود رہتی ہیں۔ task وہ ایک prompt ہے جو sandbox کے اندر موجود agent کو دیا جاتا ہے۔ sandbox روکنے سے memory خالی ہو جاتی ہے اور files محفوظ رہتی ہیں۔ اسے destroy کرنے سے container حذف ہو جاتا ہے، اور app ایک نیا container شروع کر سکتی ہے۔

sandboxd، Dify اور OpenHands میں کیا فرق ہے؟

ان تینوں کو اس لیے ایک جیسا سمجھا جاتا ہے کہ یہ سب آپ کے server پر LLM (large language model) چلاتے ہیں، لیکن ان سے تیار ہونے والی چیز مختلف ہوتی ہے۔ Dify LLM ایپلی کیشنز تیار کرتا ہے: chat interfaces، retrieval pipelines، اور ایسے workflows جو ہر بار استعمال ہونے پر model کو call کرتے ہیں۔ model تیار شدہ product کا حصہ ہوتا ہے۔ OpenHands پہلے سے موجود repository پر کام کرتا ہے: آپ اسے اپنے code کی طرف متوجہ کرتے ہیں، پھر یہ files پڑھتا ہے، commands چلاتا ہے اور تبدیلیاں تجویز کرتا ہے۔ sandboxd کا آغاز خالی جگہ سے ہوتا ہے۔ یہ preset سے project کا بنیادی ڈھانچہ تیار کرتا ہے، اسے نئے container میں build کرتا ہے، اور آپ کو دیکھنے کے لیے URL فراہم کرتا ہے۔ نتیجے میں ایک عام React یا FastAPI application ملتی ہے جسے چلانے کے لیے کسی model کی ضرورت نہیں ہوتی۔

اس لیے انتخاب اس بنیاد پر کریں کہ آخر میں آپ کیا چاہتے ہیں۔ sandboxd اس وقت موزوں ہے جب آپ ایک جملے سے آغاز کر کے بعد میں code اپنے پاس رکھنا چاہتے ہوں۔ باقی دونوں اس وقت موزوں ہیں جب 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 کو جاری ہوئی۔ project خود کو beta کہتا ہے اور بتاتا ہے کہ 0.x releases compatibility توڑ سکتی ہیں۔ ان اعداد کو quality کے حتمی فیصلے کے بجائے dependency risk کے طور پر دیکھیں: دو ماہ پرانے project کو دوسرے لوگوں کے اس کے bugs دریافت کرنے کے لیے صرف دو ماہ ملے ہیں۔

سرور کی ضروریات اور وسائل کم ہونے پر پیدا ہونے والی خرابیاں

پروجیکٹ کے مطابق آغاز کے لیے 2 vCPU اور 4 GB RAM کافی ہے۔ یہ مقدار control plane اور ایک چھوٹے sandbox کے لیے درست ہے، لیکن بیک وقت دو افراد کے build کرنے کے لیے کافی نہیں۔ میموری کو مختلف حصوں میں تقسیم کر کے منصوبہ بنائیں۔ Traefik اور Go control plane کم وسائل استعمال کرتے ہیں۔ ہر running sandbox میں مکمل Node یا Python toolchain موجود ہوتی ہے، اور زیادہ سے زیادہ استعمال ایک npm install کے بعد production build کے دوران ہوتا ہے۔ ایسے server کے لیے 8 GB RAM رکھیں جس پر چند ایپس فعال رہیں گی۔ swap کو capacity نہیں بلکہ حفاظتی سہارا سمجھیں، کیونکہ swap استعمال کرنے والا build سیکنڈز کے بجائے منٹ لیتا ہے۔

میموری ختم ہونے پر دو مختلف خرابیاں پیدا ہوتی ہیں، اور دونوں ایک جیسی نظر نہیں آتیں۔ sandbox کے اندر container، sandboxd کی مقرر کردہ سخت --memory حد تک پہنچ جاتا ہے اور kernel سب سے بڑے process کو ختم کر دیتا ہے۔ اس لیے build، agent کی طرف سے کسی مفید message کے بغیر ناکام ہو جاتا ہے۔ docker ps -a اس container کے لیے exit code 137 دکھاتا ہے، اور اس پر docker inspect چلانے سے "OOMKilled": true رپورٹ ہوتا ہے۔ اس طرح ناکام ہونے والا Node build اکثر پہلے JavaScript heap out of memory دکھاتا ہے۔

دوسری خرابی host پر پیدا ہوتی ہے۔ host کی میموری کم ہونے پر sandboxd ایک pressure reaper چلاتا ہے جو sandboxes کو روک دیتا ہے۔ اس لیے چھوٹے server پر preview دیکھتے وقت sandbox غائب ہو سکتا ہے۔ فائلیں محفوظ رہتی ہیں، اور preview URL پر اگلی request اسے دوبارہ فعال کر دیتی ہے، لیکن container رکنے کے وقت چلنے والا task دوبارہ شروع نہیں ہوتا۔

Disk زیادہ خاموش مسئلہ ہے۔ ہر ایپ host پر اپنا workspace رکھتی ہے، اور JavaScript project میں node_modules tree سینکڑوں megabytes تک پہنچ سکتی ہے۔ 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 ملتی ہے اور پانچ منٹ تک الجھن رہتی ہے۔

متعین کردہ sandboxd ریلیز انسٹال کریں

پہلے سرور پر 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 ایک shell script ہے جو network کے ذریعے حاصل کی جاتی ہے۔ اسے چلانے سے پہلے پڑھیں اور 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 ہے جسے installer $HOME/.sandboxd/src میں checkout کرتا ہے، اور اس کی default قدر main ہے۔ اسے unset چھوڑنے کا مطلب ہے کہ آپ کی installation اسی صبح merge ہونے والی تبدیلیوں پر منحصر ہوگی۔ یہ اس project میں اہم ہے جس نے صرف July 2026 میں چھ releases جاری کیں۔ version کو pin کریں، پھر changelog پڑھنے کے بعد جان بوجھ کر upgrade کریں۔

script source کو clone کرتی ہے، images build کرتی ہے، docker compose up -d کے ساتھ stack شروع کرتی ہے، اور آخر میں console URL اور API token دکھاتی ہے۔ اس token کو محفوظ جگہ پر رکھیں۔ یہ اس API کی credential ہے جو Docker کو root کے طور پر چلاتی ہے۔

curl http://127.0.0.1:9090/healthz

control plane فعال ہونے پر یہ ok دکھاتا ہے۔ اگر کچھ بھی ظاہر نہ ہو تو stack شروع نہیں ہوا۔ ~/.sandboxd/src سے docker compose ps چلائیں تاکہ معلوم ہو سکے کہ کون سی service بند ہے، پھر وجہ جاننے کے لیے docker compose logs sandboxd چلائیں۔

ریموٹ سرور پر کنسول تک رسائی

کنسول HTTP_PORT کے ذریعے، جو پہلے سے 80 ہے، hostname http://console.localhost پر فراہم کیا جاتا ہے۔ Traefik hostname کی بنیاد پر route کرتا ہے، اس لیے browser میں اپنے server کا IP address درج کرنے سے کوئی rule match نہیں ہوتا اور 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 سے گزرتی ہے۔ پہلی بار رسائی پر console password سیٹ کریں۔

ایجنٹ کو ماڈل دیں

base image میں دو coding agents شامل ہیں: OpenCode اور Claude Code۔ SANDBOXD_DEFAULT_AGENT اس task کے لیے ان دونوں میں سے انتخاب کرتا ہے جس میں کسی agent کا نام نہ دیا گیا ہو، اور اس کی default قدر opencode ہے۔ اگر کوئی key منسلک نہ ہو تو tasks، OpenCode Zen کے keyless free models پر چلتے ہیں۔ اس طرح آپ کی پہلی build کی کوئی لاگت نہیں ہوتی، اور آپ کچھ خرچ کرنے سے پہلے پورا عمل آزما سکتے ہیں۔

جب آپ کو زیادہ طاقتور model درکار ہو تو اپنی key منسلک کریں۔ Keys control plane میں جاتی ہیں، sandbox میں نہیں۔ انہیں data directory کے تحت encrypted حالت میں محفوظ کیا جاتا ہے اور credential proxy wire پر inject کرتا ہے۔ اس لیے نہ agent انہیں پڑھ سکتا ہے اور نہ وہ code جو agent لکھتا ہے۔

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 میں مقرر کیا جاتا ہے، اور ایک single task اس setting کو override کر سکتا ہے۔

آخر تک ایک چھوٹی ایپ بنائیں

ایپ بنائیں، اس کا 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> اس کا result واپس کرتا ہے، جبکہ اسی task پر موجود /events path اس کام کی live SSE (server sent events) stream ہے جو agent انجام دے رہا ہے۔ console یہی stream chat کی صورت میں دکھاتا ہے۔

ایپ اب http://s-<sandbox id>-3000.preview.localhost پر دستیاب ہے، جہاں 3000 وہ port ہے جو آپ نے طلب کیا تھا۔ اگر sandbox سو رہا ہو تو پہلی request Traefik کے catch-all پر پہنچتی ہے۔ sandboxd container شروع کرتا ہے، port کے جواب دینے کا انتظار کرتا ہے، اور ایک مختصر warming page دکھاتا ہے جو refresh ہو کر آپ کی ایپ میں تبدیل ہو جاتا ہے۔ اگر preview کبھی اس page سے آگے نہ بڑھے تو اس کا مطلب ہے کہ اندر چلنے والا process ایپ کے sandbox.yaml میں declared port پر listen نہیں کر رہا۔

پری ویوز کو HTTPS کے ساتھ حقیقی domain پر رکھیں

ہر sandbox کو اپنا hostname ملتا ہے، اس لیے ایک wildcard DNS record تمام sandbox کو cover کرتا ہے۔ *.preview.yourdomain.com کو A record کے ذریعے server کے IP address کی طرف 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 کو cover کرتا ہے۔ HTTP-01 کے ساتھ ہر نئے sandbox کے لیے الگ issuance درکار ہوتی، اور مصروف build session براہ راست 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 کھولیں اور 9090 کو دنیا کے لیے بند رکھیں: بنیادی ufw firewall rules دیکھیں۔ یاد رکھیں کہ جو شخص preview hostname کا اندازہ لگا سکتا ہے، وہ app load کر سکتا ہے؛ اس لیے previews کو public سمجھیں۔

تیار کردہ code کہاں محفوظ ہوتا ہے، اور کیا آپ اسے export کر سکتے ہیں؟

Host پر، data directory کے اندر۔ ہر workspace، /var/lib/sandboxed/workspaces/<id>/ پر ایک سادہ directory ہوتی ہے جسے container میں bind mount کیا جاتا ہے، اور app کی files sandbox کے اندر /home/sandbox/workspace/app پر موجود ہوتی ہیں۔ Control plane کی state ایک ہی SQLite file، state/sandboxd.db پر محفوظ ہوتی ہے، جبکہ 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":"main"}'

Private remote کے لیے personal access token درکار ہوتا ہے۔ اسے console میں Settings، Git credentials کے تحت ایک بار set کریں۔ یہ encrypted حالت میں محفوظ رہتا ہے اور sandbox سے باہر رہتا ہے، اس لیے agent اسے پڑھ نہیں سکتا اور نہ ہی آپ کی اجازت کے بغیر اس کے ذریعے push کر سکتا ہے۔ جلدی اور باقاعدگی سے push کریں۔ جب تک آپ ایسا نہیں کرتے، workspace directory ہی code کی واحد 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 جو پہلی کوشش میں درست نتیجہ دے، کم خرچ ہوتا ہے۔ لیکن پچاس files والے project میں "اب spacing درست کریں" کے پندرہ rounds مہنگے ہوتے ہیں، کیونکہ ہر بار file contents بھی ساتھ بھیجے جاتے ہیں۔ Input اور output tokens کی قیمتیں مختلف ہوتی ہیں، اور coding agent کی فی session لاگت حقیقت پسندانہ range فراہم کرتی ہے۔ unattended طور پر چلنے والے loop کو credentials دینے سے پہلے provider پر اخراجات کی سخت حد مقرر کریں۔

پرانے sandboxes کی صفائی

Idle reaper ایسے ہر sandbox کو روک دیتا ہے جو SANDBOXD_IDLE_THRESHOLD_SECONDS سے زیادہ وقت تک idle رہے۔ اس کی طے شدہ قدر 2100 seconds، یعنی 35 minutes ہے۔ اس سے RAM واپس دستیاب ہو جاتی ہے، جبکہ files برقرار رہتی ہیں۔ Preview URL پر اگلی request آنے پر container دوبارہ بیدار ہو جاتا ہے۔ چھوٹے server پر یہ مدت کم رکھیں، کیونکہ 35 minutes تک idle containers کا مطلب ہے کہ 35 minutes تک memory استعمال کے لیے دستیاب نہیں ہوگی۔

روکنا، حذف کرنا نہیں ہے، اور اسی وجہ سے disks خاموشی سے بھر جاتی ہیں۔ رکا ہوا 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 بے حوالہ layers صاف کرتا ہے۔ پہلے GET /v1/apps چیک کریں، کیونکہ sleeping sandbox کے زیرِ حوالہ image garbage نہیں ہوتی۔

کنٹینر کی حد آپ کو کیا دیتی ہے اور کیا نہیں دیتی

ہر sandbox ایک غیر مراعات یافتہ user کے طور پر چلتا ہے۔ اس کا root filesystem صرف پڑھنے کے لیے ہوتا ہے، Linux کی تمام capabilities ختم کر دی جاتی ہیں، no-new-privileges set ہوتا ہے، اور memory ceiling اور process limit مقرر ہوتی ہے۔ project اس حد کے بارے میں واضح ہے: مشترکہ 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 نہیں کیا جاتا۔ اس کا مطلب ہے کہ یہ limits آپ کے 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 شامل ہوتا ہے، لیکن syscall-heavy کام عموماً 1.7 سے 4 گنا سست ہو جاتا ہے۔ زیادہ مضبوط حل یہ ہے کہ ہر tenant کے لیے الگ machine استعمال کی جائے۔ یہی دلیل disposable VM میں coding agents چلانے کے حق میں بھی ہے۔

کیا آپ کو دو ماہ پرانے project کی بنیاد پر build کرنا چاہیے؟

ذاتی build box کے لیے ہاں، لیکن واضح احتیاطی تدابیر کے ساتھ: SANDBOXD_REF کو pin کریں، /var/lib/sandboxed کا backup لیں، اور ہر اہم app کو git remote پر push کریں۔ جس چیز کو customer استعمال کرے، اس کے لیے 1.0 تک انتظار کریں یا breakage کے لیے budget رکھیں، کیونکہ maintainers واضح طور پر کہتے ہیں کہ 0.x میں آپ کی تنصیب کے دوران تبدیلی آ سکتی ہے۔ August 2026 تک maintainers 79 dollars ماہانہ میں managed install بھی فروخت کرتے ہیں۔ یہ بات اس وقت اہم ہے جب آپ جانچ رہے ہوں کہ project کے برقرار رہنے کی کوئی وجہ ہے یا نہیں۔

خطرہ قابلِ قبول ہونے کی وجہ output ہے۔ sandboxd ایک عام application کو عام git repository میں تیار کرتا ہے۔ اس لیے اگر project رک جائے تو code آپ کے پاس رہتا ہے اور صرف wrapper ختم ہوتا ہے۔ یہ اس hosted builder کے مقابلے میں کہیں بہتر صورتِ حال ہے جو آپ کے project کی ملکیت رکھتا ہو۔ اس سال اپنے server پر کس چیز کو جگہ دینی چاہیے، اس کے وسیع جائزے کے لیے 2026 میں self-hosting کے قابل کیا ہے دیکھیں۔

FAQ

sandboxd کے لیے کم از کم سرور specs کیا ہیں؟

پروجیکٹ کے مطابق آغاز کے لیے 2 vCPU اور 4 GB RAM کافی ہے۔ اس میں control plane، Traefik اور ایک چھوٹا sandbox چل جاتا ہے۔ اگر آپ بیک وقت کئی ایپس فعال رکھنا چاہتے ہیں تو 8 GB RAM اور 40 GB disk استعمال کریں، کیونکہ ہر running sandbox مکمل Node یا Python toolchain رکھتا ہے اور ہر workspace اپنی dependency tree disk پر محفوظ رکھتا ہے۔ جب host کے وسائل کم پڑتے ہیں تو sandboxd کا pressure reaper memory خالی کرنے کے لیے sandboxes روک دیتا ہے۔ اگر کوئی build اپنے container کی memory ceiling سے تجاوز کرے تو kernel اسے ختم کر دیتا ہے: docker ps -a اس کے لیے exit code 137 دکھاتا ہے۔

sandboxd، Dify یا OpenHands سے کیسے مختلف ہے؟

یہ مختلف artifacts تیار کرتے ہیں۔ Dify ایسی applications بناتا ہے جو runtime پر model کو call کرتی ہیں، مثلاً chat interfaces اور retrieval pipelines۔ OpenHands آپ کے پہلے سے موجود repository میں ترمیم کرتا ہے، commands چلاتا ہے اور موجودہ code میں تبدیلیاں تجویز کرتا ہے۔ sandboxd کسی prompt سے بالکل نیا project تیار کرتا ہے، اسے اپنے container کے اندر build کرتا ہے اور preview URL پر serve کرتا ہے۔ نتیجہ ایک عام web application ہوتا ہے جسے چلنے کے لیے model کی ضرورت نہیں ہوتی۔

agent کا لکھا ہوا code حقیقت میں کہاں محفوظ ہوتا ہے؟

یہ host filesystem پر محفوظ ہوتا ہے، container image کے اندر نہیں۔ ہر app کو /var/lib/sandboxed/workspaces/<id>/ میں ایک directory ملتی ہے، جو اس کے sandbox میں bind mount ہوتی ہے، اور files وہاں /home/sandbox/workspace/app پر ظاہر ہوتی ہیں۔ Control plane state اسی data directory میں state/ کے تحت ایک single SQLite file میں محفوظ ہوتی ہے۔ آپ console کے Git tab سے یا /v1/apps/<id>/git/commit اور /git/push endpoints کے ذریعے git remote پر 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 بھی کھلا حاصل ہوتا ہے۔ اس کا مطلب ہے کہ agent کا لکھا ہوا code آپ کے local network اور cloud metadata endpoints تک پہنچ سکتا ہے۔ اگر host پر ایسے دوسرے systems موجود ہوں جن کا تحفظ ضروری ہے تو host firewall rules شامل کریں۔ ایسے لوگوں کے prompts کے لیے جن پر آپ اعتماد نہیں کرتے، container boundary پر انحصار کرنے کے بجائے ہر tenant کے لیے ایک الگ host چلائیں۔