ஆல் Matt Connor 2026-10-12

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

உங்கள் சொந்த VPS-ல் sandboxd-ஐ நிறுவி இயக்குவதற்கான வழிகாட்டி. Docker அமைப்பு, HTTPS preview URL, RAM மேலாண்மை மற்றும் stale sandboxes-ஐ நீக்கும் முறைகளை விரிவாகக் காண்போம்.

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-ஐ உருவாக்கும் முன் இதைக் கவனத்தில் கொள்ள வேண்டும்.

விளக்கப்படம்GitHub stars and forks, read from the GitHub API on 4 August 2026

tool

github_stars

forks

sandboxd

875

OpenHands

83,091

10,711

Dify

151,320

23,886

இந்த விளக்கப்படத்தின் தரவு

[
  {
    "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-ல், மற்றவர்கள் அதன் பிழைகளைக் கண்டறிய இரண்டு மாதங்களே ஆகியுள்ளது.

சர்வர் தேவைப்படும் வளங்கள் மற்றும் பற்றாக்குறையால் ஏற்படும் பாதிப்புகள்

இந்தத் திட்டத்திற்கு 2 vCPU மற்றும் 4 GB RAM தொடங்குவதற்குப் போதுமானது என்று குறிப்பிடப்பட்டுள்ளது. இது control plane மற்றும் ஒரு சிறிய sandbox-க்கு சரியாக இருக்கும், ஆனால் ஒரே நேரத்தில் இருவர் பணிபுரிய இது போதாது. நினைவகத்தை (memory) பகுதிகளாகப் பிரித்து திட்டமிடுங்கள். Traefik மற்றும் Go control plane ஆகியவை சிறியவை. இயங்கும் ஒவ்வொரு sandbox-ம் முழுமையான Node அல்லது Python toolchain-ஐக் கொண்டிருக்கும். ஒரு npm install மற்றும் அதைத் தொடர்ந்து நடக்கும் production build-ன் போதுதான் உச்சகட்ட பயன்பாடு இருக்கும். சில செயலிகளைத் தொடர்ந்து இயக்க 8 GB RAM கொண்ட சர்வரைத் திட்டமிடுங்கள். Swap-ஐத் திறனாகக் கருதாமல் ஒரு பாதுகாப்பு வலையாக மட்டும் பயன்படுத்துங்கள், ஏனெனில் 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-ன் நினைவகம் குறையும்போது sandbox-களை நிறுத்தும் pressure reaper-ஐ sandboxd இயக்குகிறது. எனவே, சிறிய சர்வர்களில் நீங்கள் preview-ஐப் பார்த்துக்கொண்டிருக்கும்போதே sandbox திடீரென மறையலாம். கோப்புகள் பாதுகாப்பாக இருக்கும், preview URL-க்கு அடுத்த கோரிக்கை வரும்போது அது மீண்டும் இயங்கும். ஆனால், container நின்றபோது இயங்கிக்கொண்டிருந்த பணி மீண்டும் தொடராது.

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

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

இந்த வழிகாட்டி குறிப்பிடும் v0.3.6 பதிப்பில், இயல்புநிலை தரவு அடைவு (default data directory) /var/lib/sandboxed ஆகும், இதில் கூடுதல் e சேர்க்கப்பட்டுள்ளது. அங்கு /var/lib/sandboxd என்று தட்டச்சு செய்தால் எந்தப் பயனும் இருக்காது, ஐந்து நிமிடங்கள் குழப்பமே மிஞ்சும். இது v0.3.9 (25 ஆகஸ்ட் 2026) பதிப்பில் மாற்றப்பட்டது. புதிய நிறுவல்கள் (installers) புதியவற்றை /var/lib/sandboxd-ல் வைக்கும், மேலும் ஏற்கனவே அங்குள்ள நிறுவல்களுக்கு மட்டுமே /var/lib/sandboxed-ஐப் பயன்படுத்தும். பிந்தைய பதிப்பில் அமைக்கப்பட்ட சர்வர்களில், கீழே உள்ள ஒவ்வொரு கட்டளையிலும் e இல்லாத பாதையைப் பயன்படுத்தவும்.

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

Compose plugin-உடன் கூடிய Docker Engine மற்றும் git ஆகியவை முதலில் server-ல் இருக்க வேண்டும். 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 பிழையுடன் நிறுவி நின்றுவிடும். இந்த வழிகாட்டியில் உள்ள கட்டளைகள் docker compose-ஐப் பயன்படுத்துவதால், plugin-ஐ நிறுவுவதே எளிமையான தீர்வாகும்.

நிறுவி என்பது 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 என்பது $HOME/.sandboxd/src-க்குள் நிறுவி checkout செய்யும் git ref ஆகும், இது இயல்பாக main-ஐக் கொண்டிருக்கும். இதை மாற்றாமல் விட்டால், அன்றைய தினம் merge செய்யப்பட்ட code-ஐ அது நிறுவும். ஜூலை 2026-ல் மட்டும் ஆறு releases-ஐ வெளியிட்ட ஒரு project-க்கு இது முக்கியமானது. எனவே, version-ஐ pin செய்து, changelog-ஐப் படித்த பிறகு திட்டமிட்டு upgrade செய்யவும். அக்டோபர் 12, 2026 நிலவரப்படி, புதிய release v0.3.22 ஆகும்; இது இங்கே pin செய்யப்பட்டுள்ள v0.3.6-ஐ விட பதினாறு releases முந்தையது.

இந்த script source code-ஐ 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 உடன் கூடிய உண்மையான டொமைனில் அமைத்தல்

ஒவ்வொரு 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-ஐ உலகிற்குத் திறக்காமல் வைத்திருக்கவும்: அடிப்படை ufw firewall விதிகள் என்பதைப் பார்க்கவும். ஒரு முன்னோட்ட hostname-ஐக் கணிப்பவர் எவரும் அந்த app-ஐ அணுக முடியும் என்பதை நினைவில் கொள்க, எனவே முன்னோட்டங்களை பொதுவானதாகவே கருதவும்.

நீங்கள் டொமைன், DNS மற்றும் சான்றிதழ் அமைப்புகளைத் தவிர்க்க விரும்பினால், பராமரிப்பாளர்கள் இப்போது sandboxd Cloud-ஐ வழங்குகிறார்கள். இது உங்கள் server-க்கு sandboxd.io-ன் கீழ் ஒரு பொதுவான HTTPS முகவரியை வழங்குகிறது. அக்டோபர் 2026 நிலவரப்படி, ஒரு server-க்கு மாதம் 9.99 டாலர்கள் அல்லது அறிமுகச் சலுகையுடன் 4.99 டாலர்கள் கட்டணமாகும். v0.3.6 pin-ஐப் பயன்படுத்துவதற்கு முன்பு, அதற்குத் தேவையான release எது என்பதைச் சரிபார்க்கவும்.

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

Host-ல், data directory-க்கு அடியில் இது சேமிக்கப்படுகிறது. v0.3.6 நிறுவலில் ஒவ்வொரு workspace-ம் /var/lib/sandboxed/workspaces/<id>/-ல் உள்ள ஒரு சாதாரண directory ஆகும்; இது container-க்குள் bind mount செய்யப்படுகிறது, மேலும் app-ன் கோப்புகள் sandbox-க்குள் /home/sandbox/workspace/app-ல் அமைகின்றன. Control plane-ன் நிலை state/sandboxd.db-ல் உள்ள ஒரே ஒரு SQLite கோப்பாக உள்ளது, மேலும் குறியாக்கம் செய்யப்பட்ட (encrypted) agent credentials agent-auth/-ல் உள்ளன. எதையும் container layer-க்குள் மறைத்து வைக்கவில்லை என்பதால், ஒரு backup என்பது அந்த directory-ன் நகல் மற்றும் அந்த database கோப்பு மட்டுமே. VPS-ல் restic backups இவை இரண்டையும் கையாளுகிறது.

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

Git ஏற்றுமதி என்பது தனியாகச் சேர்க்கப்பட்டதல்ல, உள்ளமைக்கப்பட்ட வசதியாகும். 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>-ஐ எடுத்துக்கொள்ளும். main, master மற்றும் நீங்கள் இறக்குமதி செய்த branch ஆகியவை நிராகரிக்கப்படும், எனவே remote பக்கத்தில் merge செய்யவும்.

ஒரு private remote-க்கு personal access token தேவை, இதை console-ல் Settings, Git credentials பிரிவில் ஒருமுறை அமைக்க வேண்டும். இது குறியாக்கம் செய்யப்பட்டு 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-ஐயே பாதிக்கும் அபாயம் கொண்டது.

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

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

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

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

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

FAQ

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

control plane, Traefik மற்றும் ஒரு சிறிய sandbox ஆகியவற்றை இயக்க 2 vCPU மற்றும் 4 GB RAM போதுமானது என்று இந்தத் திட்டம் குறிப்பிடுகிறது. ஒரே நேரத்தில் பல செயலிகளை இயக்க விரும்பினால் 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-ல் சேமிக்கப்படுகிறது. v0.3.6 நிறுவலில் ஒவ்வொரு செயலிக்கும் /var/lib/sandboxed/workspaces/<id>/-ல் ஒரு directory ஒதுக்கப்படுகிறது (v0.3.9 அல்லது அதற்குப் பிந்தைய புதிய நிறுவல்களில் /var/lib/sandboxd/workspaces/<id>/). இது அதன் 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 branch-க்கு commit மற்றும் push செய்யலாம். private remotes-க்கான 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 எல்லையை மட்டும் நம்பியிருக்காமல், ஒவ்வொரு tenant-க்கும் ஒரு தனி host-ஐப் பயன்படுத்தவும்.

இந்தக் கட்டுரை பயனுள்ளதாக இருந்ததா?

#sandboxd#ai-agents #self-hosted#app-builder#docker