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

তাই শেষ পর্যন্ত আপনি কী চান, তার ভিত্তিতে বেছে নিন। একটি sentence থেকে শুরু করে পরে code সংরক্ষণ করতে চাইলে sandboxd ব্যবহার করুন। অন্য দুটি ব্যবহার করুন যখন repository বা model-চালিত product আগে থেকেই আছে।

আরেকটি পার্থক্য হলো project-এর বয়স। এর ওপর বাস্তব কোনো কিছু তৈরি করার আগে এই বিষয়টি বিবেচনা করা জরুরি।

[
  {
    "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"
  }
]

OpenHands-এর 875 এবং Dify-এর 151,320-এর বিপরীতে sandboxd-এর 83,091 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 করলে এই সংস্থান যথেষ্ট নয়। মেমরি আলাদা অংশে হিসাব করুন। Traefik এবং Go control plane অল্প মেমরি ব্যবহার করে। প্রতিটি চলমান sandbox-এ সম্পূর্ণ Node বা Python toolchain থাকে। সর্বোচ্চ ব্যবহার হয় একটি npm install-এর পরে production build চলার সময়। কয়েকটি অ্যাপ চালু রাখবে এমন সার্ভারের জন্য 8 GB RAM পরিকল্পনা করুন। Swap-কে capacity নয়, safety net হিসেবে বিবেচনা করুন। কারণ build swap ব্যবহার করলে কয়েক সেকেন্ডের বদলে কয়েক মিনিট সময় লাগে।

মেমরি শেষ হলে দুটি ভিন্ন ধরনের ব্যর্থতা দেখা যায়। এগুলো দেখতে একে অপরের মতো নয়। 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-এর মেমরি কমে গেলে sandboxd একটি pressure reaper চালিয়ে sandbox বন্ধ করে। তাই ছোট সার্ভারে preview দেখার সময়ও কোনো sandbox অদৃশ্য হয়ে যেতে পারে। ফাইলগুলো নিরাপদ থাকে। Preview URL-এ পরবর্তী অনুরোধ করলে sandbox আবার চালু হয়। তবে container বন্ধ হওয়ার সময় চলমান কোনো task পুনরায় শুরু হয় না।

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

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

Default data directory হলো /var/lib/sandboxed। এর বানানে অতিরিক্ত e আছে। /var/lib/sandboxd টাইপ করলে একটি খালি directory পাবেন এবং বিভ্রান্তিতে পাঁচ মিনিট নষ্ট হবে।

pinned sandboxd release ইনস্টল করুন

Docker Engine, Compose plugin এবং 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। তাই চালানোর আগে 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 হলো সেই git ref, যেটি installer $HOME/.sandboxd/src-এ checkout করে। এর default মান main। এটি unset রাখলে সেদিন সকালে merge হওয়া code অনুযায়ী install হবে। 2026 সালের July মাসেই project-টি ছয়টি release প্রকাশ করেছে, তাই বিষয়টি গুরুত্বপূর্ণ। Version pin করুন। Changelog পড়ে তারপর ইচ্ছাকৃতভাবে upgrade করুন।

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 করছে না।

প্রিভিউগুলোকে HTTPS-সহ একটি বাস্তব ডোমেইনে চালান

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

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

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

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

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

জেনারেট করা কোড কোথায় থাকে, এবং এটি কি export করা যায়?

Host-এ, data directory-এর অধীনে। প্রতিটি workspace হলো /var/lib/sandboxed/workspaces/<id>/-এ থাকা একটি সাধারণ directory, যা container-এ bind mount করা হয়। Sandbox-এর ভেতরে app-এর files থাকে /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 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 অংশে একবার সেট করুন। Token-টি 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 একটি unprivileged user হিসেবে চলে। এর root filesystem read only থাকে, সব Linux capability বাদ দেওয়া হয়, 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 internet, আপনার local network এবং cloud metadata endpoint-এ পৌঁছাতে পারে। Source-এ একটি nftables egress subsystem আছে, কিন্তু portable Docker Compose build-এ এটি compile করা থাকে না। ফলে egress limit আপনার 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 থাকে, তবে syscall-heavy কাজ প্রায় 1.7 থেকে 4 গুণ ধীর হয়। আরও শক্তিশালী সমাধান হলো প্রতিটি tenant-এর জন্য একটি করে machine ব্যবহার করা। এটি disposable VM-এ coding agent চালানোর একই যুক্তি।

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

ব্যক্তিগত build box-এর জন্য হ্যাঁ, তবে স্বাভাবিক সতর্কতা মেনে চলুন: SANDBOXD_REF pin করুন, /var/lib/sandboxed-এর backup রাখুন, এবং যেসব app আপনার কাছে গুরুত্বপূর্ণ সেগুলো একটি git remote-এ push করুন। কোনো customer ব্যবহার করবে এমন কিছুর ক্ষেত্রে 1.0 release হওয়া পর্যন্ত অপেক্ষা করুন অথবা breakage-এর জন্য বাজেট রাখুন, কারণ maintainers স্পষ্টভাবে বলেছেন যে 0.x সংস্করণে আপনার অজান্তেই পরিবর্তন আসতে পারে। 2026 সালের August অনুযায়ী maintainers মাসে 79 dollars-এ managed install-ও বিক্রি করেন। প্রকল্পটি টিকে থাকার যথেষ্ট কারণ আছে কি না বিচার করার সময় এই তথ্যটি জানা গুরুত্বপূর্ণ।

ঝুঁকিটি গ্রহণযোগ্য হওয়ার কারণ হলো এর output। sandboxd একটি সাধারণ git repository-তে একটি সাধারণ application তৈরি করে। তাই প্রকল্পের development থেমে গেলেও code আপনার কাছে থাকে; শুধু wrapper-টি হারাবেন। আপনার প্রকল্পের মালিকানা একটি hosted builder-এর হাতে থাকার তুলনায় এটি অনেক ভালো অবস্থান। এই বছরে আপনার server-এ কোন ধরনের software self-hosting করার মতো, তার বিস্তৃত ধারণার জন্য দেখুন 2026 সালে কোন software 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 দেখা যায়।

sandboxd, Dify এবং OpenHands-এর মধ্যে পার্থক্য কী?

এগুলো ভিন্ন ধরনের 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-এ থাকে। প্রতিটি app-এর জন্য /var/lib/sandboxed/workspaces/<id>/-এ একটি directory তৈরি হয় এবং সেটি তার sandbox-এ bind mount করা হয়। Sandbox-এর ভেতরে 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-এ commit ও push করতে পারেন। Private remote-এর token control plane encrypted অবস্থায় সংরক্ষণ করে; এটি sandbox-এর কাছে হস্তান্তর করা হয় না।

sandboxd-কে Internet-এ প্রকাশ করা কি নিরাপদ?

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