VPS-ல் sandboxd AI app builder-ஐ நிறுவுவது எப்படி?

sandboxd என்றால் என்ன, அதை நீங்களே இயக்குவதால் கிடைக்கும் பயன்கள்

sandboxd-ஐ நீங்களே self-host செய்ய, Docker மற்றும் domain name கொண்ட ஒரு Linux server தேவை. நீங்கள் ஒரு prompt-ஐ அனுப்பினால், ஒரு coding agent தனிமைப்படுத்தப்பட்ட container-க்குள் ஒரு உண்மையான application-ஐ உருவாக்கும்; அந்த application அதன் சொந்த preview URL-ல் இயங்கும். Prompt-to-app builders என்பது 2026-ன் மிகவும் பிரபலமான hosted வகை ஆகும். sandboxd என்பது உங்கள் VPS-ல், MIT உரிமத்தின் கீழ் இயங்கக்கூடியது; இதில் உருவாக்கப்படும் code உங்கள் சொந்த disk-லேயே சேமிக்கப்படும்.

இதன் வடிவமைப்பு வேண்டுமென்றே சிறியதாக வைக்கப்பட்டுள்ளது. ஒரு Go control plane, Docker-ஐ இயக்குகிறது; Traefik v3 ஒவ்வொரு preview hostname-ஐயும் வழிநடத்துகிறது (route); SQLite தரவுகளைச் சேமிக்கிறது; ஒவ்வொரு app-ம் ஒரு தனி container-க்குள் இயங்குகிறது. இதில் Kubernetes அல்லது தனி database server கிடையாது; இதனால்தான் 2 vCPU கொண்ட ஒரு சிறிய server-ல் கூட இதை இயக்க முடிகிறது.

நான்கு பொருட்கள் இந்த முழு மாதிரியையும் தாங்குகின்றன. ஒரு app என்பது நிலையான project; இது அதன் பெயர், git metadata மற்றும் secrets-ஐக் கொண்டிருக்கும். ஒரு sandbox என்பது அந்த app இயங்கும் Docker container; ஒரு app ஒரு நேரத்தில் ஒரு sandbox-ஐ மட்டுமே குறிக்கும். ஒரு workspace என்பது app-ன் கோப்புகள்; இவை host-ல் இருக்கும் மற்றும் container நீக்கப்பட்டாலும் அழியாது. ஒரு task என்பது sandbox-க்குள் இருக்கும் agent-க்கு வழங்கப்படும் ஒரு prompt ஆகும். ஒரு sandbox-ஐ நிறுத்துவது memory-ஐ விடுவிக்கும், ஆனால் கோப்புகளை அப்படியே வைத்திருக்கும். அதை அழிப்பது container-ஐ நீக்கிவிடும், அதன் பிறகு app ஒரு புதிய sandbox-ஐத் தொடங்கிக்கொள்ளலாம்.

sandboxd, Dify மற்றும் OpenHands ஆகியவற்றிற்கு இடையிலான வேறுபாடு என்ன?

இவை மூன்றிலும் LLM (large language model) உங்கள் server-ல் இயங்குவதால், இவை குழப்பத்தை ஏற்படுத்தலாம். ஆனால், இவை ஒவ்வொன்றும் உருவாக்கும் வெளியீடு வெவ்வேறானது. Dify, LLM applications-ஐ உருவாக்குகிறது: chat interfaces, retrieval pipelines மற்றும் பயனர் பயன்படுத்தும் ஒவ்வொரு முறையும் model-ஐ அழைக்கும் workflows ஆகியவற்றை இது உருவாக்குகிறது. இதில் model என்பது இறுதி தயாரிப்பின் ஒரு பகுதியாகும். OpenHands உங்களிடம் ஏற்கனவே உள்ள repository-ல் வேலை செய்கிறது: நீங்கள் உங்கள் code-ஐக் குறிப்பிட்டால், அது கோப்புகளைப் படித்து, கட்டளைகளை இயக்கி, மாற்றங்களைப் பரிந்துரைக்கும். sandboxd எதையும் சாராமல் புதிதாகத் தொடங்குகிறது. இது ஒரு preset-லிருந்து project-ஐ உருவாக்கி, அதை ஒரு புதிய container-ல் கட்டமைத்து, நீங்கள் பார்ப்பதற்கான URL-ஐ வழங்குகிறது. இதன் முடிவில் கிடைப்பது ஒரு சாதாரண React அல்லது FastAPI application ஆகும்; இதை இயக்க எந்த model-ம் தேவையில்லை.

எனவே, இறுதியில் உங்களுக்கு என்ன தேவை என்பதைப் பொறுத்து ஒன்றைத் தேர்வு செய்யவும். ஒரு வாக்கியத்திலிருந்து தொடங்கி, அதன் பிறகு code-ஐத் தக்கவைக்க sandboxd பயன்படுகிறது. மற்ற இரண்டு கருவிகளும், ஏற்கனவே உள்ள repository அல்லது model-ஐ அடிப்படையாகக் கொண்ட தயாரிப்புகளுக்குப் பயன்படுகின்றன.

மற்றொரு வேறுபாடு அவற்றின் வயது. எதிலாவது ஒரு முக்கியமான 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"
  }
]

sandboxd 875 stars பெற்றுள்ளது, அதே சமயம் OpenHands 83,091 stars-ம், 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 மாறக்கூடும் என்று குறிப்பிடுகிறது. இந்த எண்களைத் தரத்திற்கான தீர்ப்பாகக் கருதாமல், dependency risk-ஆகக் கருதவும்: இரண்டு மாதங்களே ஆன ஒரு project-ல், மற்றவர்கள் அதன் பிழைகளைக் கண்டறிய இரண்டு மாதங்களே ஆகியுள்ளது.

server-க்குத் தேவையானவை மற்றும் பற்றாக்குறையினால் ஏற்படும் பாதிப்புகள்

இந்த project-ஐத் தொடங்க 2 vCPU மற்றும் 4 GB RAM போதுமானது என்று குறிப்பிடப்பட்டுள்ளது. இது control plane மற்றும் ஒரு சிறிய sandbox-க்குச் சரியாக இருக்கும், ஆனால் ஒரே நேரத்தில் இருவர் பணிபுரிய இது போதாது. நினைவகத்தை (memory) பகுதிகளாகப் பிரித்துத் திட்டமிடுங்கள். Traefik மற்றும் Go control plane ஆகியவை சிறியவை. இயங்கும் ஒவ்வொரு sandbox-ம் முழுமையான Node அல்லது Python toolchain-ஐக் கொண்டிருக்கும்; ஒரு npm install மற்றும் அதைத் தொடர்ந்து நடக்கும் production build ஆகியவை உச்சகட்ட நினைவகத்தைப் பயன்படுத்தும். சில பயன்பாடுகளைத் தொடர்ந்து இயக்க 8 GB RAM கொண்ட server-ஐத் திட்டமிடுங்கள். Swap-ஐ ஒரு பாதுகாப்பு வசதியாக மட்டுமே கருதுங்கள், அதைத் திறனாக (capacity) நினைக்க வேண்டாம்; ஏனெனில் swap-ஐப் பயன்படுத்தும் build, சில வினாடிகளுக்குப் பதிலாகச் சில நிமிடங்கள் எடுத்துக்கொள்ளும்.

நினைவகம் தீர்ந்துவிட்டால், இரண்டு வெவ்வேறு வகையான தோல்விகள் ஏற்படும்; அவை ஒன்றுக்கொன்று தொடர்பில்லாதவை போலத் தோன்றும். Sandbox-க்குள், container-ஆனது sandboxd அமைத்துள்ள கடினமான --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-களை நிறுத்திவிடும். எனவே, சிறிய server-களில் நீங்கள் preview-ஐப் பார்த்துக்கொண்டிருக்கும்போதே sandbox திடீரென மறையலாம். கோப்புகள் பாதுகாப்பாக இருக்கும், அடுத்த முறை preview URL-ஐ அணுகும்போது அது மீண்டும் இயங்கும். ஆனால், container நின்றபோது இயங்கிக்கொண்டிருந்த பணி மீண்டும் தொடராது.

Disk என்பது அமைதியான ஒரு சிக்கல். ஒவ்வொரு application-ம் தனது workspace-ஐ host-ல் வைத்திருக்கும். ஒரு JavaScript project-ல் நூற்றுக்கணக்கான megabytes அளவில் node_modules tree இருக்கும். பத்து application-கள் இருந்தால், images-ஐக் கணக்கிடுவதற்கு முன்பே பல gigabytes அளவிலான dependencies சேர்ந்துவிடும். 40 GB-ல் தொடங்கி, அதன் பயன்பாட்டைக் கவனியுங்கள்:

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

இயல்பான data directory /var/lib/sandboxed ஆகும், இதில் கூடுதல் e உள்ளது. தவறுதலாக /var/lib/sandboxd என்று உள்ளிட்டால், உங்களுக்கு ஒரு காலியான directory மட்டுமே கிடைக்கும், இது ஐந்து நிமிடங்களுக்கு உங்களை குழப்பமடையச் செய்யும்.

pinned sandboxd release-ஐ நிறுவுதல்

Compose plugin-உடன் கூடிய Docker Engine மற்றும் git ஆகியவை முதலில் server-ல் இருக்க வேண்டும். 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-ஐ 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 ஆகும்; இது இயல்பாக main என்று இருக்கும். இதை மாற்றாமல் விட்டால், அன்றைய தினம் merged செய்யப்பட்ட code-ஐ அது நிறுவும். 2026 ஜூலை மாதத்தில் மட்டும் ஆறு releases-ஐ வெளியிட்ட ஒரு project-க்கு இது முக்கியமானது. எனவே, version-ஐ pin செய்துவிட்டு, changelog-ஐப் படித்த பிறகு திட்டமிட்டு upgrade செய்யவும்.

இந்த script source-ஐ clone செய்து, images-ஐ build செய்து, docker compose up -d மூலம் stack-ஐத் தொடங்கும். இறுதியில் console URL மற்றும் API token-ஐக் காட்டும். அந்த token-ஐப் பாதுகாப்பாகச் சேமிக்கவும். இது root-ஆக Docker-ஐ இயக்கும் API-க்கான credential ஆகும்.

curl http://127.0.0.1:9090/healthz

control plane தயாரானதும் அது ok-ஐக் காட்டும். எதுவும் காட்டவில்லை என்றால், stack தொடங்கவில்லை என்று பொருள்: எந்த service இயங்கவில்லை என்பதை அறிய ~/.sandboxd/src-லிருந்து docker compose ps-ஐ இயக்கவும், அதன் பிறகு காரணம் என்னவென்று அறிய docker compose logs sandboxd-ஐ இயக்கவும்.

தொலைதூர கணினியில் உள்ள console-ஐ அணுகுதல்

இந்த console, Traefik மூலம் HTTP_PORT-ல் வழங்கப்படுகிறது. இது இயல்பாக 80-வது port-ல் இயங்கும், இதன் hostname http://console.localhost ஆகும். Traefik hostname-ஐ அடிப்படையாகக் கொண்டே routing செய்கிறது. எனவே, உங்கள் server-ன் IP முகவரியை browser-ல் உள்ளிட்டால் எந்த விதியும் பொருந்தாது, அது 404 பிழையைத் தரும். நீங்கள் உண்மையான domain-ஐ அமைக்கும் வரை, port-ஐ forward செய்து hostname-ஐ அப்படியே வைத்திருக்கவும்:

ssh -L 8080:127.0.0.1:80 you@your-vps

பிறகு உங்கள் மடிக்கணினியில் http://console.localhost:8080-ஐத் திறக்கவும். Linux மற்றும் macOS-ல் .localhost-ல் முடியும் எந்தவொரு பெயரும் 127.0.0.1-க்குத் திரும்பும் (resolve ஆகும்). எனவே, இந்த கோரிக்கை சரியான Host header-உடன் tunnel வழியாகச் செல்லும். முதல்முறை நுழையும்போது console-க்கான கடவுச்சொல்லை (password) அமைக்கவும்.

ஏஜெண்டிற்கு ஒரு மாடலை வழங்குதல்

அடிப்படை image-ல் OpenCode மற்றும் Claude Code ஆகிய இரண்டு கோடிங் ஏஜெண்டுகள் உள்ளன. ஒரு பணியில் எந்த ஏஜெண்ட் பெயரும் குறிப்பிடப்படாதபோது, SANDBOXD_DEFAULT_AGENT எந்த ஏஜெண்ட் இயங்க வேண்டும் என்பதைத் தீர்மானிக்கிறது; இது முன்னிருப்பாக opencode-ஐத் தேர்வு செய்கிறது. எந்தவொரு key-யும் இணைக்கப்படாத நிலையில், OpenCode Zen-ன் keyless free மாடல்களில் பணிகள் இயங்கும். எனவே, உங்கள் முதல் build-க்கு எந்தச் செலவும் இல்லை; எதையும் செலவழிக்கும் முன் முழு செயல்முறையையும் நீங்கள் சோதித்துப் பார்க்கலாம்.

உங்களுக்கு வலிமையான மாடல் தேவைப்படும்போது, உங்கள் சொந்த key-ஐ இணைக்கவும். Key-கள் control plane-க்கு மட்டுமே செல்லும், sandbox-க்குள் ஒருபோதும் செல்லாது: அவை data directory-க்குள் குறியாக்கப்பட்டு (encrypted) சேமிக்கப்படும். ஒரு credential proxy மூலம் அவை இணைப்பில் (on the wire) செலுத்தப்படும், எனவே ஏஜெண்டோ அல்லது அது எழுதும் குறியீடோ (code) அவற்றை வாசிக்க முடியாது.

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 என்பதன் கீழ் console-லும் இதே வசதி உள்ளது. நீங்கள் API key-க்கு பதிலாக Claude subscription-ஐப் பயன்படுத்த விரும்பினால், அதற்கான வழிகாட்டப்பட்ட OAuth flow-வும் இதில் உள்ளது. ஒவ்வொரு ஏஜெண்டிற்கான முன்னிருப்பு மாடலும் (default model) அதே panel-ல் இருக்கும், ஒரு குறிப்பிட்ட பணியின் போது அதை நீங்கள் மாற்றிக்கொள்ளலாம் (override).

ஒரு சிறிய செயலியை முழுமையாக உருவாக்குதல்

செயலியை உருவாக்கி, அதன் sandbox-ஐ boot செய்து, பின் ஒரு 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 boot ஆகவில்லை என்று அர்த்தம்; இதற்கு அடிப்படை 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"}'

பதில் ஒரு task id-ஐக் கொண்டிருக்கும். GET /v1/sandboxes/$SB/tasks/<task id> அதன் முடிவைத் தரும், அதே task-ல் உள்ள /events பாதை, agent என்ன செய்கிறது என்பதற்கான நேரடி SSE (server sent events) stream ஆகும். Console அதே stream-ஐ chat போலக் காட்டும்.

செயலி http://s-<sandbox id>-3000.preview.localhost-ல் இருக்கும், அங்கு 3000 என்பது நீங்கள் கேட்ட port ஆகும். Sandbox உறக்க நிலையில் இருந்தால், முதல் கோரிக்கை Traefik-ன் catch-all-க்குச் செல்லும்; sandboxd container-ஐத் தொடங்கி, port பதிலளிக்கும் வரை காத்திருந்து, ஒரு சிறிய warming page-ஐக் காட்டும், அது தானாகவே உங்கள் செயலிக்கு refresh ஆகும். அந்தப் பக்கத்திலேயே preview நின்றுவிட்டால், செயலியின் sandbox.yaml-ல் குறிப்பிடப்பட்ட port-ல் உள்ளே இருக்கும் process கேட்கவில்லை (listening) என்று அர்த்தம்.

முன்னோட்டங்களை (previews) HTTPS வசதியுடன் கூடிய உண்மையான domain-ல் பதிவேற்றுதல்

ஒவ்வொரு sandbox-க்கும் தனித்தனி hostname இருப்பதால், ஒரு wildcard DNS record மூலம் அனைத்தையும் கையாள முடியும். *.preview.yourdomain.com-ஐ server-ன் IP முகவரிக்கு ஒரு A record மூலம் சுட்டிக்காட்டவும். பின்னர் ~/.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-ஐ இயக்கி, ஒரு certificate resolver-ஐச் சேர்க்கவும். DNS-01 challenge-ஐப் பயன்படுத்தவும், ஏனெனில் ஒரு wildcard certificate மூலம் அனைத்து முன்னோட்ட hostname-களையும் பாதுகாக்க முடியும். HTTP-01 பயன்படுத்தினால், ஒவ்வொரு புதிய sandbox-க்கும் தனித்தனியாகச் சான்றிதழ் பெற வேண்டியிருக்கும்; அதிகப்படியான உருவாக்கப் பணிகளின் போது இது Let's Encrypt rate limits-ஐத் தாண்டிவிடும். DNS-01 challenge மூலம் wildcard certificates என்பது இதன் DNS பக்கத்தை விளக்குகிறது.

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

முன்னோட்ட URL-கள் https://s-<id>-3000.preview.yourdomain.com என மாறும். Firewall-ல் 80 மற்றும் 443 ports-ஐத் திறந்து வைக்கவும், ஆனால் 9090 port-ஐ வெளிப்புற அணுகலுக்குத் திறக்க வேண்டாம்: அடிப்படை ufw firewall விதிகள் என்பதைப் பார்க்கவும். முன்னோட்ட hostname-ஐக் கணிக்கும் எவரும் அந்த application-ஐ அணுக முடியும் என்பதை நினைவில் கொள்க, எனவே முன்னோட்டங்களை பொதுவானதாகவே கருதவும்.

உருவாக்கப்பட்ட குறியீடு எங்கே சேமிக்கப்படுகிறது, அதை export செய்ய முடியுமா?

Host-ல், data directory-க்கு அடியில் இது சேமிக்கப்படுகிறது. ஒவ்வொரு workspace-ம் /var/lib/sandboxed/workspaces/<id>/-ல் ஒரு சாதாரண directory-ஆக இருக்கும், அது container-க்குள் bind mount செய்யப்பட்டிருக்கும். Application-ன் கோப்புகள் sandbox-க்குள் /home/sandbox/workspace/app-ல் அமையும். Control plane-ன் நிலை state/sandboxd.db-ல் உள்ள ஒரே ஒரு SQLite கோப்பாக இருக்கும், மேலும் encrypted agent credentials agent-auth/-ல் இருக்கும். எதையும் container layer-க்குள் மறைத்து வைக்கவில்லை, எனவே ஒரு backup என்பது அந்த database கோப்புடன் கூடிய directory-ன் நகலாகும். 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 மட்டுமே குறியீட்டின் ஒரே நகலாகும், மேலும் DELETE /v1/apps/<id> அதை எந்தவித எச்சரிக்கையும் இன்றி நீக்கிவிடும்.

ஒரு build-க்கு எத்தனை model tokens செலவாகும்?

sandboxd உங்கள் செலவைக் கணக்கிடுவதில்லை, எனவே உங்கள் provider-ன் console-ல் உள்ள எண்ணிக்கையே முக்கியமானது. இலவச OpenCode Zen மாதிரிகளுக்குக் கட்டணம் ஏதுமில்லை, ஆனால் அவை கட்டண மாதிரிகளை விட மெதுவானவை மற்றும் திறன் குறைந்தவை; ஒரு சிறிய application-ஐத் தாண்டிய எதற்கும் இவை அதிகமுறை திருத்தங்களைச் செய்ய வேண்டியிருக்கும்.

பட்டியலின் அளவு agent loop எவ்வாறு செயல்படுகிறது என்பதைப் பொறுத்தது. ஒவ்வொரு சுற்றும் (turn) அதற்குத் தேவையான context-ஐ மீண்டும் அனுப்புகிறது, எனவே செலவு என்பது application-களின் எண்ணிக்கையை அல்ல, சுற்றுகளின் எண்ணிக்கையையே குறிக்கும். ஒருமுறை அனுப்பப்படும் prompt மலிவானது. ஐம்பது கோப்புகளைக் கொண்ட ஒரு project-ல் "இப்போது இடைவெளியைச் சரிசெய்" என்று பதினைந்து முறை திருத்தம் செய்வது மலிவானது அல்ல, ஏனெனில் ஒவ்வொரு முறையும் கோப்பின் உள்ளடக்கம் மீண்டும் அனுப்பப்படுகிறது. Input மற்றும் output tokens வெவ்வேறு விலைகளைக் கொண்டுள்ளன, மேலும் ஒரு coding agent-க்கு ஒரு session-க்கு எவ்வளவு செலவாகும் என்பது யதார்த்தமான வரம்பைக் காட்டுகிறது. கவனிக்கப்படாத ஒரு loop-ஐ இயக்குவதற்கு முன், provider-ல் ஒரு கடினமான செலவு வரம்பை (hard spend limit) நிர்ணயம் செய்யுங்கள்.

பழைய sandboxes-ஐ நீக்குதல்

Idle reaper, SANDBOXD_IDLE_THRESHOLD_SECONDS-ஐ விட அதிக நேரம் செயலற்று இருக்கும் எந்தவொரு sandbox-ஐயும் நிறுத்திவிடும். இதன் இயல்புநிலை மதிப்பு 2100 வினாடிகள் அல்லது 35 நிமிடங்கள் ஆகும். இது RAM-ஐ விடுவித்து கோப்புகளைத் தக்கவைக்கும்; preview URL-க்கு வரும் அடுத்த கோரிக்கை container-ஐ மீண்டும் இயக்கும். சிறிய server-களில் இந்த மதிப்பை குறைக்கவும், ஏனெனில் 35 நிமிடங்கள் செயலற்று இருக்கும் container-கள் நீங்கள் பயன்படுத்த முடியாத 35 நிமிட நினைவகத்தை வீணடிக்கும்.

நிறுத்துவது என்பது நீக்குவது அல்ல, இங்குதான் 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 நீங்கள் எதிர்பார்ப்பதை விட அதிக மீட்கக்கூடிய image இடத்தை காட்டும், ஏனெனில் தனது சொந்த toolchain-ஐப் பதிவிறக்கிய ஒவ்வொரு app-ம் layers-ஐ விட்டுச் செல்கிறது. docker image prune பயன்பாட்டில் இல்லாதவற்றை நீக்கும். முதலில் GET /v1/apps-ஐச் சரிபார்க்கவும், ஏனெனில் உறங்கும் sandbox-ஆல் குறிக்கப்படும் image குப்பை (garbage) அல்ல.

Container boundary எதை வழங்குகிறது, எதை வழங்காது

ஒவ்வொரு sandbox-ம் unprivileged user-ஆக, read-only root filesystem-உடன் இயங்குகிறது. இதில் அனைத்து Linux capabilities-ம் நீக்கப்பட்டுள்ளன, no-new-privileges அமைக்கப்பட்டுள்ளது, மேலும் memory மற்றும் process-களுக்கான வரம்புகள் உள்ளன. இந்தத் திட்டத்தின் வரம்புகள் குறித்து வெளிப்படையாகக் கூறப்பட்டுள்ளது: பகிரப்பட்ட kernel-ஐக் கொண்ட Linux container என்பது ஒரு வலுவான isolation boundary, ஆனால் பலவீனமான security boundary ஆகும். ஒரு kernel bug என்பது host-ஐயே பாதிக்கும் (compromise) அபாயம் கொண்டது.

இரண்டு உண்மைகளை கவனத்தில் கொள்ள வேண்டும். Self-hosted build-ல் sandbox-லிருந்து வெளிச்செல்லும் network egress அனுமதிக்கப்படுகிறது; எனவே உருவாக்கப்படும் code, internet, உங்கள் local network மற்றும் cloud metadata endpoints ஆகியவற்றை அணுக முடியும். Source-ல் nftables egress subsystem இருந்தாலும், portable Docker Compose build-ல் அது compile செய்யப்படவில்லை. எனவே, உங்கள் host firewall மூலமே வரம்புகளை அமைக்க வேண்டும். மேலும், control plane API என்பது Docker socket-ஐ இயக்குவதால், அது நடைமுறையில் host root-க்கு சமமானது. இது இயல்பாக 127.0.0.1:9090-ல் bind ஆகிறது, SANDBOXD_API_AUTH_DISABLED எப்போதும் false-ஆகவே இருக்க வேண்டும், மேலும் இதை ஒருபோதும் internet-ல் வெளியிடக்கூடாது.

மற்றவர்கள் உங்கள் box-க்கு prompts அனுப்ப அனுமதிக்கும் திட்டத்தில் இருந்தால், இந்த மாதிரி (model) போதுமானதாக இருக்காது. இந்தத் திட்டம் SANDBOXD_RUNTIME=runsc-உடன் gVisor-ஐப் பயன்படுத்த பரிந்துரைக்கிறது. இது sandbox-க்கும் host-க்கும் இடையே ஒரு userspace kernel-ஐ வைக்கிறது; syscall அதிகம் தேவைப்படும் பணிகளில் இது சுமார் 1.7 முதல் 4 மடங்கு வரை மெதுவாகச் செயல்படும். இதற்கு வலுவான தீர்வு, ஒவ்வொரு tenant-க்கும் ஒரு தனி machine-ஐப் பயன்படுத்துவதாகும். இது disposable VM-ல் coding agents-ஐ இயக்குவது போன்ற அதே வாதமாகும்.

இரண்டு மாதங்கள் பழமையான ஒரு திட்டத்தில் நீங்கள் உருவாக்கலாமா?

தனிப்பட்ட பயன்பாட்டிற்கான build box-க்கு, தகுந்த முன்னெச்சரிக்கைகளுடன் இதைச் செய்யலாம்: SANDBOXD_REF-ஐ pin செய்யவும், /var/lib/sandboxed-ஐ backup எடுக்கவும், மேலும் நீங்கள் முக்கியமாகக் கருதும் ஒவ்வொரு application-ஐயும் ஒரு git remote-க்கு push செய்யவும். வாடிக்கையாளர் பயன்படுத்தும் எதற்கும், 1.0 version வரும் வரை காத்திருக்கவும் அல்லது பாதிப்புகள் ஏற்பட்டால் அதைச் சரிசெய்ய நிதி ஒதுக்கவும். ஏனெனில், 0.x version-கள் எந்த நேரத்திலும் மாறக்கூடும் என்று அதன் பராமரிப்பாளர்கள் தெளிவாகக் கூறியுள்ளனர். ஆகஸ்ட் 2026 நிலவரப்படி, பராமரிப்பாளர்கள் 79 டாலர் மாதக் கட்டணத்தில் managed install சேவையையும் வழங்குகிறார்கள். ஒரு திட்டம் தொடர்ந்து நீடிப்பதற்கான காரணம் உள்ளதா என்பதை மதிப்பிடும்போது, இதைக் கருத்தில் கொள்வது அவசியம்.

இந்த ஆபத்தை ஏற்றுக்கொள்வதற்கு அதன் வெளியீடே காரணம். sandboxd ஒரு சாதாரண git repository-ல் சாதாரண application-ஐ உருவாக்குகிறது. எனவே, அந்தத் திட்டம் நின்றுபோனாலும், உங்களிடம் code இருக்கும், wrapper-ஐ மட்டுமே நீங்கள் இழப்பீர்கள். உங்கள் திட்டத்தின் உரிமையைக் கொண்ட ஒரு hosted builder-ஐ விட இது மிகவும் சிறந்த நிலை. இந்த ஆண்டு உங்கள் server-ல் எவற்றை நிறுவலாம் என்பது குறித்த விரிவான பார்வைக்கு, 2026-ல் எவற்றை self-host செய்வது பயனுள்ளது என்பதைப் பார்க்கவும்.

FAQ

sandboxd-க்குத் தேவையான குறைந்தபட்ச server விவரக்குறிப்புகள் என்ன?

2 vCPU மற்றும் 4 GB RAM இருந்தால் போதுமானது என்று திட்டம் குறிப்பிடுகிறது; இது control plane, Traefik மற்றும் ஒரு சிறிய sandbox-ஐ இயக்க உதவும். ஒரே நேரத்தில் பல செயலிகளை இயக்க விரும்பினால் 8 GB RAM மற்றும் 40 GB disk-ஐப் பயன்படுத்தவும். ஏனெனில், இயங்கும் ஒவ்வொரு sandbox-ம் ஒரு முழுமையான Node அல்லது Python toolchain-ஐக் கொண்டிருக்கும், மேலும் ஒவ்வொரு workspace-ம் தனது சொந்த dependency tree-ஐ disk-ல் வைத்திருக்கும். host-ல் நினைவகம் குறையும் போது, sandboxd-ன் pressure reaper நினைவகத்தை விடுவிக்க sandbox-களை நிறுத்திவிடும். ஒரு build அதன் container-ன் நினைவக வரம்பைத் தாண்டினால், அது kernel-ஆல் நிறுத்தப்படும்: docker ps -a அதற்கான exit code 137-ஐக் காட்டும்.

Dify அல்லது OpenHands-லிருந்து sandboxd எவ்வாறு வேறுபடுகிறது?

இவை வெவ்வேறு வெளியீடுகளை உருவாக்குகின்றன. Dify, chat interfaces மற்றும் retrieval pipelines போன்ற runtime-ல் model-ஐ அழைக்கும் செயலிகளை உருவாக்குகிறது. OpenHands உங்களிடம் ஏற்கனவே உள்ள repository-ஐத் திருத்தி, கட்டளைகளை இயக்கி, குறியீட்டில் மாற்றங்களைப் பரிந்துரைக்கிறது. sandboxd ஒரு prompt-லிருந்து புதிய திட்டத்தை உருவாக்கி, அதை அதன் சொந்த container-க்குள் build செய்து, ஒரு preview URL-ல் வழங்குகிறது. இதன் விளைவாகக் கிடைக்கும் சாதாரண web application இயங்குவதற்கு எந்த model-ம் தேவையில்லை.

agent எழுதும் குறியீடு உண்மையில் எங்கே சேமிக்கப்படுகிறது?

அது container image-க்குள் அல்ல, host filesystem-ல் சேமிக்கப்படுகிறது. ஒவ்வொரு செயலிக்கும் /var/lib/sandboxed/workspaces/<id>/-ல் ஒரு directory ஒதுக்கப்பட்டு, அது sandbox-க்குள் bind mount செய்யப்படுகிறது; கோப்புகள் உள்ளே /home/sandbox/workspace/app-ல் தோன்றும். Control plane-ன் நிலை, அதே data directory-ல் state/ என்ற ஒற்றை SQLite கோப்பில் இருக்கும். நீங்கள் console-ன் Git tab மூலமாகவோ அல்லது /v1/apps/<id>/git/commit மற்றும் /git/push endpoints மூலமாகவோ git remote-க்கு commit மற்றும் push செய்யலாம். private remote-களுக்கான token, sandbox-க்கு வழங்கப்படாமல், control plane-ஆல் குறியாக்கப்பட்டு (encrypted) சேமிக்கப்படுகிறது.

sandboxd-ஐ இணையத்தில் வெளிப்படுத்துவது பாதுகாப்பானதா?

Preview URL-களையும் console-ஐயும் வெளிப்படுத்தலாம், ஆனால் control plane API-ஐ ஒருபோதும் வெளிப்படுத்த வேண்டாம். அந்த API host-ல் Docker-ஐ இயக்குவதால், அது root-க்கு இணையானது; எனவேதான் அது முன்னிருப்பாக 127.0.0.1:9090-ல் இணைகிறது. சுய-வழங்கி (self-hosted) build-ல் sandbox-களுக்கு வெளிப்படையான network egress உள்ளது. அதாவது, agent எழுதும் குறியீடு உங்கள் local network மற்றும் cloud metadata endpoints-ஐ அணுக முடியும். எனவே, பாதுகாக்கப்பட வேண்டிய பிற சாதனங்கள் உங்கள் network-ல் இருந்தால், host firewall விதிகளைச் சேர்க்கவும். நீங்கள் நம்பாத நபர்களிடமிருந்து வரும் prompts-க்கு, container எல்லையை மட்டும் நம்பியிருக்காமல், ஒவ்வொரு பயனர் அல்லது வாடிக்கையாளருக்கும் தனித்தனி host-ஐப் பயன்படுத்தவும்.