VPS-এ sandboxd নিজে চালানোর সম্পূর্ণ গাইড

sandboxd কী এবং নিজে চালালে আপনি কী পাবেন

sandboxd নিজে host করতে আপনার Docker-সহ একটি Linux server এবং একটি domain name দরকার। আপনি একটি prompt পাঠাবেন, একটি coding agent isolated container-এর ভেতরে বাস্তব application তৈরি করবে, এবং সেই application নিজের preview URL-এ চালু হবে। Prompt-to-app builder 2026 সালের hosted category-গুলোর মধ্যে সবচেয়ে আলোচিত। sandboxd এমন একটি builder, যা আপনার VPS-এ, MIT licence-এর অধীনে চলে এবং তৈরি করা code আপনার নিজের disk-এ রাখে।

নকশাটি ইচ্ছাকৃতভাবে ছোট রাখা হয়েছে। একটি Go control plane Docker নিয়ন্ত্রণ করে, Traefik v3 প্রতিটি preview hostname route করে, SQLite state সংরক্ষণ করে, এবং প্রতিটি app একটি container-এর ভেতরে চলে। Kubernetes বা আলাদা database server নেই। তাই 2 vCPU-এর server-এও এটি চালানো সম্ভব।

চারটি object পুরো model পরিচালনা করে। app হলো স্থায়ী project, যেখানে তার name, git metadata এবং secrets থাকে। sandbox হলো সেই Docker container, যার ভেতরে app চলে; একটি 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 application তৈরি করে: chat interface, retrieval pipeline, এবং এমন workflow, যা কেউ ব্যবহার করলেই প্রতিবার একটি model call করে। model-টি চূড়ান্ত product-এর অংশ। OpenHands আপনার আগে থেকেই থাকা repository-তে কাজ করে: আপনি এটিকে আপনার code দেখান, আর এটি file পড়ে, command চালায় এবং পরিবর্তনের প্রস্তাব দেয়। sandboxd শূন্য থেকে শুরু করে। এটি একটি preset থেকে project-এর প্রাথমিক কাঠামো তৈরি করে, নতুন container-এ সেটি build করে এবং দেখার জন্য আপনাকে একটি URL দেয়। এতে তৈরি হওয়া জিনিসটি একটি সাধারণ React বা FastAPI application, যা চালাতে কোনো model-এর প্রয়োজন হয় না।

তাই শেষ পর্যন্ত আপনি কী চান, তার ভিত্তিতে বেছে নিন। একটি বাক্য থেকে শুরু করে পরে code রেখে দিতে চাইলে sandboxd ব্যবহার করুন। অন্য দুটি ব্যবহার করুন যখন repository বা model-চালিত 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টি star রয়েছে, যেখানে OpenHands-এর 83,091টি এবং Dify-এর 151,320টি star রয়েছে। 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 release compatibility ভেঙে দিতে পারে। এই সংখ্যাগুলোকে quality সম্পর্কে চূড়ান্ত রায় হিসেবে নয়, dependency risk হিসেবে দেখুন: দুই মাস পুরোনো project-এ অন্যদের তার bug খুঁজে পাওয়ার সুযোগও মাত্র দুই মাস হয়েছে।

সার্ভারের প্রয়োজনীয়তা এবং ঘাটতি হলে যে সমস্যাগুলো হয়

প্রকল্পের নির্দেশনা অনুযায়ী শুরু করার জন্য 2 vCPU এবং 4 GB RAM যথেষ্ট। Control plane-এর সঙ্গে একটি ছোট sandbox চালানোর ক্ষেত্রে এটি সঠিক। তবে একই সময়ে দুইজন build করলে এই সামর্থ্য যথেষ্ট নয়। Memory আলাদা অংশে হিসাব করুন। Traefik এবং Go control plane-এর memory চাহিদা কম। প্রতিটি চলমান sandbox-এ সম্পূর্ণ Node বা Python toolchain থাকে। সর্বোচ্চ memory ব্যবহারের সময় একটি npm install-এর পর production build চলে। কয়েকটি অ্যাপ চালু রাখবে এমন সার্ভারের জন্য 8 GB RAM পরিকল্পনা করুন। Swap-কে capacity নয়, safety net হিসেবে বিবেচনা করুন। কারণ swap ব্যবহার করে চলা build শেষ হতে কয়েক মিনিট লাগে, কয়েক সেকেন্ড নয়।

Memory শেষ হলে দুটি ভিন্ন ধরনের failure দেখা যায়। এগুলো দেখতে একেবারেই একরকম নয়। Sandbox-এর ভেতরে container sandboxd নির্ধারিত hard --memory সীমায় পৌঁছায়। তখন kernel সবচেয়ে বড় process-টিকে kill করে। ফলে agent থেকে কোনো কার্যকর message ছাড়াই build ব্যর্থ হয়। docker ps -a ওই container-এর জন্য exit code 137 দেখায়। ওই container-এ docker inspect চালালে "OOMKilled": true দেখা যায়। এভাবে কোনো Node build ব্যর্থ হলে সাধারণত আগে JavaScript heap out of memory মুদ্রিত হয়।

দ্বিতীয় failure host-এ ঘটে। Host-এর memory কমে গেলে sandboxd একটি pressure reaper চালিয়ে sandbox বন্ধ করে। তাই ছোট সার্ভারে preview দেখার সময়ও একটি sandbox অদৃশ্য হয়ে যেতে পারে। Files নিরাপদ থাকে। Preview URL-এ পরের request এলে sandbox আবার চালু হয়। তবে container বন্ধ হওয়ার সময় চলমান কোনো task আবার শুরু হয় না।

Disk তুলনামূলকভাবে নীরব সমস্যা। প্রতিটি অ্যাপ host-এ নিজস্ব workspace রাখে। একটি JavaScript project-এ কয়েকশ megabyte-এর node_modules tree থাকতে পারে। Images-এর হিসাব বাদ দিলেও 10টি অ্যাপের dependency-তেই কয়েক gigabyte লাগে। 40 GB দিয়ে শুরু করুন এবং এটি পর্যবেক্ষণ করুন:

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 লিখলে কোনো ফল পাবেন না এবং বিভ্রান্তিকরভাবে পাঁচ মিনিট নষ্ট হবে। v0.3.9-এ (25 August 2026) এটি পরিবর্তিত হয়েছে। নতুন installer-গুলো fresh install-এর জন্য /var/lib/sandboxd ব্যবহার করে। /var/lib/sandboxed কেবল সেই install-এর জন্য রাখা হয়, যেটি ইতিমধ্যে সেখানে রয়েছে। পরবর্তী release দিয়ে প্রথমবার সেট আপ করা সার্ভারে নিচের প্রতিটি command-এ e ছাড়া path ব্যবহার করুন।

একটি নির্দিষ্ট sandboxd release ইনস্টল করুন

সার্ভারে আগে 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 ইনস্টল থাকলে সেটিতে fallback করে। দুটিই না থাকলেই শুধু Docker Compose not found দেখিয়ে বন্ধ হয়। এই নির্দেশিকার command-গুলো docker compose ব্যবহার করে। তাই plugin ইনস্টল করাই সহজ সমাধান।

Installer হলো network থেকে আনা একটি shell script। তাই এটি চালানোর আগে পড়ে নিন এবং 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 হলো installer যে git ref checkout করে $HOME/.sandboxd/src-এ রাখে। এর default মান main। এটি unset রাখলে আপনার installation সেই সকালের merge হওয়া code-এর ওপর নির্ভর করবে। জুলাই 2026-এই project-টি ছয়টি release প্রকাশ করেছে, তাই বিষয়টি গুরুত্বপূর্ণ। একটি version নির্দিষ্ট করুন। এরপর changelog পড়ে ইচ্ছাকৃতভাবে upgrade করুন। 12 October 2026 অনুযায়ী সর্বশেষ release হলো v0.3.22। এখানে নির্দিষ্ট v0.3.6-এর পরে এটি আরও ষোলোটি release।

Script-টি source clone করে, image build করে, docker compose up -d দিয়ে stack চালু করে এবং শেষে console URL ও একটি API token দেখায়। Token-টি নিরাপদ স্থানে সংরক্ষণ করুন। এটি এমন একটি API-এর credential, যা root হিসেবে Docker পরিচালনা করে।

curl http://127.0.0.1:9090/healthz

Control plane চালু হলে এটি ok দেখায়। কিছু না দেখালে stack start হয়নি। কোন service বন্ধ আছে তা দেখতে ~/.sandboxd/src থেকে docker compose ps চালান। এরপর কারণ জানতে docker compose logs sandboxd চালান।

দূরবর্তী সার্ভারের কনসোলে পৌঁছানো

HTTP_PORT-এ Traefik-এর মাধ্যমে কনসোলটি পরিবেশিত হয়। ডিফল্টভাবে এই port হলো 80। কনসোলটি http://console.localhost hostname-এ উপলভ্য। Traefik hostname অনুযায়ী routing করে। তাই browser-এ আপনার server-এর IP address দিলে কোনো rule মেলে না এবং 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 সহ request-টি tunnel-এর মধ্য দিয়ে যায়। প্রথমবার প্রবেশের সময় console password সেট করুন।

এজেন্টকে একটি মডেল দিন

Base image-এ দুটি coding agent থাকে: OpenCode এবং Claude Code। কোনো task-এ নির্দিষ্ট agent-এর নাম না থাকলে কোনটি চালানো হবে তা SANDBOXD_DEFAULT_AGENT নির্ধারণ করে, এবং ডিফল্ট হিসেবে opencode ব্যবহার করে। কোনো key সংযুক্ত না থাকলেও task-গুলো OpenCode Zen-এর keyless free model-এ চলে। তাই প্রথম build-এর জন্য কোনো খরচ হয় না এবং কোনো অর্থ ব্যয় করার আগে পুরো workflow পরীক্ষা করা যায়।

আরও শক্তিশালী model ব্যবহার করতে চাইলে নিজের key সংযুক্ত করুন। Key-গুলো control plane-এ যায়, sandbox-এ কখনো নয়। এগুলো data directory-র অধীনে encrypted অবস্থায় সংরক্ষিত হয় এবং credential proxy wire-এ inject করে। ফলে agent বা সেটি যে code লেখে, কোনোটিই 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-..."}'

Console-এর Settings, AI Agents অংশেও একই কাজ করা যায়। API key-এর পরিবর্তে Claude subscription ব্যবহার করতে চাইলে সেখানে guided OAuth flow-ও আছে। প্রতিটি agent-এর default model একই panel-এ নির্ধারণ করা যায়। একটি নির্দিষ্ট task-এ সেটি override-ও করা যায়।

একটি ছোট অ্যাপ শুরু থেকে শেষ পর্যন্ত তৈরি করুন

অ্যাপটি তৈরি করুন, এর 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"

উভয় ভেরিয়েবলের মান অবশ্যই একটি 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-এ response আসা পর্যন্ত অপেক্ষা করে এবং একটি সংক্ষিপ্ত warming page দেখায়, যা refresh হয়ে আপনার অ্যাপে চলে যায়। Preview যদি ওই page থেকে আর এগোয় না, তাহলে app-এর sandbox.yaml-এ ঘোষিত port-এ ভেতরের process listen করছে না।

বাস্তব domain-এ HTTPS সহ preview প্রকাশ করুন

প্রতিটি sandbox-এর নিজস্ব hostname থাকে, তাই একটি wildcard DNS record দিয়েই সব sandbox কভার করা যায়। A record ব্যবহার করে *.preview.yourdomain.com-কে server-এর IP address-এ নির্দেশ করুন। এরপর ~/.sandboxd/src-এ .env-এর preview variable-গুলো সেট করুন:

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

Traefik-এও সংশ্লিষ্ট অংশটি কনফিগার করতে হবে: traefik/traefik.yml-এ websecure entrypoint সক্রিয় করুন এবং একটি certificate resolver যোগ করুন। DNS-01 challenge ব্যবহার করুন, কারণ একটি wildcard certificate দিয়েই প্রতিটি preview hostname কভার করা যায়। HTTP-01 ব্যবহার করলে প্রতিটি নতুন sandbox-এর জন্য আলাদা certificate issuance প্রয়োজন হবে, আর ব্যস্ত দিনে একটানা build করলে সরাসরি Let's Encrypt-এর rate limit-এ পৌঁছে যেতে পারেন। DNS অংশের জন্য DNS-01 challenge-এর মাধ্যমে wildcard certificate দেখুন।

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

Preview URL হবে https://s-<id>-3000.preview.yourdomain.com। Firewall-এ 80 এবং 443 port খুলুন, কিন্তু Internet থেকে 9090 বন্ধ রাখুন: মৌলিক ufw firewall rule দেখুন। মনে রাখবেন, যে কেউ preview hostname অনুমান করতে পারলে app লোড করতে পারবে। তাই preview-কে public হিসেবে বিবেচনা করুন।

আপনি যদি domain, DNS এবং certificate সম্পূর্ণ এড়িয়ে যেতে চান, maintainer-রা এখন sandboxd Cloud বিক্রি করে। এটি sandboxd.io-এর অধীনে আপনার server-এর জন্য একটি public HTTPS address দেয়। মূল্য প্রতি server-এ প্রতি মাসে 9.99 dollar, অথবা launch discount-সহ 4.99 dollar; এই তথ্য October 2026 অনুযায়ী প্রযোজ্য। এটি ব্যবহার করার আগে v0.3.6 pin দিয়ে কোন release প্রয়োজন তা যাচাই করুন।

উৎপন্ন কোড কোথায় থাকে, এবং এটি কি export করা যায়?

Host-এ, data directory-এর অধীনে। প্রতিটি workspace হলো /var/lib/sandboxed/workspaces/<id>/-এ থাকা একটি সাধারণ directory, যা v0.3.6 install-এ container-এ bind mount করা থাকে। App-এর ফাইলগুলো 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 backup দুটিই পরিচালনা করে।

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

Git export আলাদা করে যোগ করা কোনো feature নয়; এটি built in। 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 করা হয়েছে, সেগুলো প্রত্যাখ্যাত হয়। তাই remote side-এ merge করুন।

Private remote-এর জন্য personal access token প্রয়োজন। Console-এর Settings, Git credentials অংশে এটি একবার সেট করুন। এটি encrypted অবস্থায় সংরক্ষিত হয় এবং sandbox-এর বাইরে থাকে। তাই agent এটি পড়তে পারে না বা আপনার অজান্তে এটি ব্যবহার করে push করতে পারে না। দ্রুত এবং নিয়মিত push করুন। এটি না করা পর্যন্ত workspace directory-ই কোডের একমাত্র copy। আর DELETE /v1/apps/<id> কোনো দ্বিতীয় সুযোগ ছাড়াই সেটি মুছে দেয়।

একটি build-এর খরচ model token-এ কত?

sandboxd আপনার খরচের হিসাব রাখে না। তাই গুরুত্বপূর্ণ সংখ্যা provider-এর console-এ দেখতে হবে। বিনামূল্যের OpenCode Zen model-এর কোনো খরচ নেই। তবে সেগুলো paid model-এর তুলনায় ধীর এবং কম সক্ষম। toy app-এর চেয়ে বড় কাজ হলে বারবার সংশোধনের প্রয়োজন হওয়ায় এই পার্থক্য স্পষ্ট হয়।

বিলের পরিমাণ agent loop যেভাবে কাজ করে তার ওপর নির্ভর করে। প্রতিটি turn-এ প্রয়োজনীয় context আবার পাঠানো হয়। তাই খরচ app-এর সংখ্যার নয়, turn-এর সংখ্যার সঙ্গে বাড়ে। একটি prompt সফলভাবে কার্যকর হলে খরচ কম। কিন্তু পঞ্চাশটি file-সম্বলিত project-এ "এখন spacing ঠিক করুন" ধরনের পনেরোটি round ব্যয়বহুল। কারণ প্রতিবার file-এর contents-ও পাঠানো হয়। Input ও output token-এর মূল্য আলাদাভাবে নির্ধারিত হয়, এবং প্রতি session-এ coding agent-এর বাস্তব খরচ সম্ভাব্য পরিসরটি দেখায়। unattended অবস্থায় চলা loop-কে অনুমতি দেওয়ার আগে provider-এর console-এ একটি hard spend limit নির্ধারণ করুন।

অব্যবহৃত sandbox পরিষ্কার করা

Idle reaper কোনো sandbox SANDBOXD_IDLE_THRESHOLD_SECONDS সময়ের বেশি idle থাকলে সেটি বন্ধ করে দেয়। এর ডিফল্ট মান 2100 seconds বা 35 minutes। এতে RAM মুক্ত হয়, কিন্তু ফাইলগুলো থেকে যায়। Preview URL-এ পরবর্তী request এলে container আবার চালু হয়। ছোট সার্ভারে এই সময় কমিয়ে দিন, কারণ 35 minutes ধরে idle container চললে সেই 35 minutes-এর memory আপনি অন্য কাজে ব্যবহার করতে পারবেন না।

বন্ধ করা আর মুছে ফেলা এক নয়। এখানেই disk ধীরে ধীরে পূর্ণ হয়। বন্ধ থাকা sandbox-এর workspace এবং container তখনও থাকে। Sandbox মুছে app রেখে দেওয়া হলো 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 এখনও যে image ব্যবহার করছে, সেটি garbage নয়।

কনটেইনার boundary কী দেয় এবং কী দেয় না

প্রতিটি sandbox read-only root filesystem, বাদ দেওয়া সব Linux capability, no-new-privileges সেটিং, memory ceiling এবং process limit সহ unprivileged user হিসেবে চলে। প্রকল্পটি এই সীমাবদ্ধতা স্পষ্টভাবে স্বীকার করে: 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 endpoint-এ পৌঁছাতে পারে। 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 থাকতে হবে, এবং এটি কখনো internet-এ publish করা উচিত নয়।

আপনি যদি অন্য ব্যক্তিদের আপনার machine-এ prompt পাঠানোর সুযোগ দিতে চান, তাহলে এই model একা যথেষ্ট নিরাপদ নয়। প্রকল্পটি SANDBOXD_RUNTIME=runsc সহ gVisor ব্যবহারের পরামর্শ দেয়। এতে sandbox এবং host-এর মধ্যে একটি userspace kernel থাকে। প্রকল্পের নিজস্ব পরিমাপ অনুযায়ী এতে package install প্রায় 1.7 গুণ ধীর হয় এবং syscall-নির্ভর কাজ প্রায় 4 গুণ ধীর হয়। আরও শক্তিশালী সমাধান হলো প্রতিটি tenant-এর জন্য একটি করে machine ব্যবহার করা। এটিই একটি অস্থায়ী VM-এ coding agent চালানোর পক্ষে একই যুক্তি।

দুই মাস পুরোনো একটি প্রকল্পের ওপর কি কাজ শুরু করা উচিত?

ব্যক্তিগত build box-এর ক্ষেত্রে, হ্যাঁ। তবে কিছু স্বাভাবিক সতর্কতা নিন: SANDBOXD_REF pin করুন, data directory-এর backup রাখুন (v0.3.6-এ /var/lib/sandboxed, এবং v0.3.9 বা পরের fresh install-এ /var/lib/sandboxd), এবং গুরুত্বপূর্ণ প্রতিটি app-এর code একটি git remote-এ push করুন। কোনো customer ব্যবহার করবে এমন কিছুর ক্ষেত্রে 1.0 প্রকাশ হওয়া পর্যন্ত অপেক্ষা করুন, অথবা breakage সামলানোর জন্য budget রাখুন। কারণ maintainers স্পষ্টভাবে বলেছেন, 0.x সংস্করণ আপনার configuration বা workflow-এর ওপর নির্ভর না করেই পরিবর্তিত হতে পারে। Maintainers একটি managed install-ও বিক্রি করেন: October 2026 অনুযায়ী setup-এর জন্য 199 dollars এবং চালানোর জন্য মাসে 79 dollars। প্রকল্পটির টিকে থাকার বাস্তব কারণ আছে কি না বিচার করার সময় এই তথ্য জানা উপকারী।

ঝুঁকি গ্রহণযোগ্য হওয়ার কারণ হলো এর output। sandboxd একটি সাধারণ git repository-তে একটি সাধারণ application তৈরি করে। তাই প্রকল্পটির development থেমে গেলেও code আপনার কাছে থাকে; শুধু wrapper হারাবেন। আপনার প্রকল্পের মালিকানা যেসব hosted builder নিজের হাতে রাখে, তার তুলনায় এটি অনেক ভালো অবস্থান। এই বছর আপনার server-এ কোন ধরনের জিনিস self-hosting করার উপযুক্ত, তার সামগ্রিক ধারণার জন্য দেখুন 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 disk-এ নিজস্ব dependency tree সংরক্ষণ করে। Host-এর memory কমে গেলে sandboxd-এর pressure reaper memory খালি করতে sandbox বন্ধ করে। কোনো build তার container-এর memory ceiling অতিক্রম করলে kernel সেটিকে বন্ধ করে: docker ps -a-এ এর exit code 137 দেখা যায়।

Dify বা OpenHands থেকে sandboxd কীভাবে আলাদা?

এগুলো ভিন্ন ধরনের artifact তৈরি করে। Dify এমন application তৈরি করে যা runtime-এ model call করে, যেমন chat interface এবং retrieval pipeline। OpenHands আপনার বিদ্যমান repository সম্পাদনা করে, command চালায় এবং বিদ্যমান code-এ পরিবর্তনের প্রস্তাব দেয়। sandboxd prompt থেকে সম্পূর্ণ নতুন project-এর কাঠামো তৈরি করে, নিজস্ব container-এর মধ্যে সেটি build করে এবং preview URL-এ পরিবেশন করে। এর ফল একটি সাধারণ 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 করা হয় এবং ভিতরে file-গুলো /home/sandbox/workspace/app-এ দেখা যায়। Control plane-এর state একই data directory-এর state/-এর অধীনে একটি SQLite file-এ থাকে। Console-এর Git tab থেকে অথবা /v1/apps/<id>/git/commit এবং /git/push endpoint ব্যবহার করে git remote-এ নতুন branch-এ commit ও push করতে পারেন। Private remote-এর token control plane encrypted অবস্থায় সংরক্ষণ করে; এটি sandbox-এ দেওয়া হয় না।

sandboxd-কে Internet-এ উন্মুক্ত করা কি নিরাপদ?

Preview URL এবং console উন্মুক্ত করুন, কিন্তু control plane API কখনো উন্মুক্ত করবেন না। এই API host-এর Docker নিয়ন্ত্রণ করে, তাই এটি root access-এর সমতুল্য। এই কারণেই এটি ডিফল্টভাবে 127.0.0.1:9090-এ bind করে। Self-hosted build-এ sandbox-এর network egress-ও খোলা থাকে। ফলে agent-এর লেখা code আপনার local network এবং cloud metadata endpoint-এ পৌঁছাতে পারে। তাই host-এ সুরক্ষার প্রয়োজন আছে এমন অন্য system থাকলে host firewall rule যোগ করুন। যাদের prompt আপনি বিশ্বাস করেন না, তাদের ক্ষেত্রে container boundary-এর ওপর নির্ভর না করে প্রতি tenant-এর জন্য একটি করে host চালান।