ஆல் Matt Connor 2026-08-16

SandBase agent runtime-ஐ நீங்களே host செய்வது எப்படி?

Q: Runtime-ஐ public port-ல் வெளிப்படுத்துவது பாதுகாப்பானதா?

இயல்புநிலை அமைப்பில் இது பாதுகாப்பானது அல்ல. இது 127.0.0.1:3000-ல் bind ஆகி, authentication இல்லாமலேயே தொடங்குகிறது. இதைச் சரிசெய்ய, bind address-ஐ மாற்றுவது தீர்வாகாது. ஒரு API key-ஐ உருவாக்கவும் அல்லது MANAGED_AGENTS_API_KEY-ஐ அமைக்கவும்; இது bearer-token authentication-ஐச் செயல்படுத்தும். பிறகு, TLS-க்காக nginx அல்லது Caddy-ஐ முன்னால் வைத்து, firewall-ல் port 3000-ஐ மூடிவிடவும். இதன் மூலம் proxy வழியாக மட்டுமே உள்ளே நுழைய முடியும்.

Q: Local, Docker மற்றும் Kubernetes sandboxes-க்கு இடையே உள்ள வேறுபாடு என்ன?

local, tool code-ஐ host-ல் உள்ள runtime-ன் child process-ஆக, runtime user-ன் அனுமதியுடன், எந்தவிதமான தனிமைப்படுத்தலும் (isolation) இன்றி இயக்குகிறது. docker, ஒவ்வொரு session-க்கும் தனித்தனி container-ஐ வழங்குகிறது. இதில் தனித்தனி filesystem, memory limit மற்றும் CPU share இருக்கும்; session முடிந்ததும் இது நீக்கப்படும். kubernetes, session-ஐ ஒரு pod-ஆக இயக்கி, kubectl exec மூலம் கட்டுப்படுத்துகிறது. இதற்கு runtime image-க்குள் kubectl-ம், target namespace-ல் pods மற்றும் exec subresource-க்கான RBAC அனுமதியும் தேவை.

Q: நான் எதை backup எடுக்க வேண்டும்?

Workspace-ல் உள்ள .managed-agents/ directory-ஐ backup எடுக்க வேண்டும். இதில் config.yaml, agents, sessions, credential vault entries மற்றும் memory entries கொண்ட data.db SQLite database, அத்துடன் பதிவேற்றப்பட்ட கோப்புகள், skill packages மற்றும் session snapshots ஆகியவை உள்ளன. SQLite தரவுத்தளம் நகலெடுக்கும்போது மாற்றப்படாமல் இருக்க, நகலெடுப்பதற்கு முன் service-ஐ நிறுத்தவும். ${OPENAI_API_KEY} எனக் குறிப்பிடப்படும் provider API keys இந்த backup-ல் இருக்காது, எனவே அவற்றைத் தனியாகச் சேமிக்கவும்.

SandBase Harness v0.3.2-ஐ உங்கள் சொந்த VPS-ல் நிறுவுவது எப்படி என்று அறிக. Agent YAML அமைப்பு, MCP servers, sandbox modes மற்றும் Anthropic SDK-ஐ இணைக்கும் முறைகளை விளக்குகிறோம்.

SandBase agent runtime-ஐ நீங்களே host செய்யும்போது கிடைக்கும் வசதிகள்

SandBase agent runtime-ஐ நீங்களே host செய்வது என்பது, SandBase Harness-ஐ உங்கள் சொந்த server-ல் இயக்குவதைக் குறிக்கும். இதனால் sessions, credentials, memory மற்றும் audit trails ஆகியவை பிறரது server-களில் இல்லாமல், உங்கள் disk-லேயே சேமிக்கப்படும். இது ஒரு Node service ஆகும். இது 127.0.0.1:3000-ல் listening செய்கிறது, /v1 HTTP API மற்றும் web console-ஐ வழங்குகிறது, மேலும் தனது நிலையை (state) உங்கள் agent கோப்புகளுக்கு அருகிலேயே SQLite-ல் பராமரிக்கிறது.

/v1 API-ஆனது, hosted managed-agent API-ஆகிய Claude Managed Agents (CMA)-ன் வடிவமைப்பைப் பின்பற்றியே உருவாக்கப்பட்டுள்ளது. இதுவே இந்த runtime-ன் சிறப்பம்சமாகும்: நீங்கள் Anthropic SDK-ஐப் பயன்படுத்தி code எழுதி, அதன் baseURL-ஐ உங்கள் சொந்த server-க்கு point செய்யலாம்; பின்னர் அதே code-ஐத் தேவைப்பட்டால் hosted deployment-க்கு மாற்றிக்கொள்ளலாம்.

SandBase Harness எந்தவொரு model-ஐயும் உள்ளடக்கி (ship) வருவதில்லை. இது ஒரு model-ஐ அழைக்கும் (call) பணியைச் செய்கிறது. ஆகஸ்ட் 2026 நிலவரப்படி, இது OpenAI, Anthropic மற்றும் OpenAI-compatible endpoints-ஐ ஆதரிக்கிறது. இது self-hosted gateways மற்றும் DeepSeek V4 போன்ற providers-க்கும் பொருந்தும். நீங்கள் இதற்காக ஒரு API key-ஐ வழங்க வேண்டும் அல்லது OpenAI API-ஐ ஆதரிக்கும் ஒரு local server-ஐ வைத்திருக்க வேண்டும்.

நீங்கள் தொடங்குவதற்கு முன் தேவையானவை

குறைந்தபட்சம் 2 GB RAM கொண்ட Ubuntu 24.04 இயங்கும் ஒரு VPS. TypeScript build என்பது நிறுவலில் மிகவும் அதிக வளங்களை எடுத்துக்கொள்ளும் படியாகும்.
Node.js 22 அல்லது அதற்குப் புதிய பதிப்பு, மற்றும் npm 10 அல்லது அதற்குப் புதிய பதிப்பு. இவை இரண்டும் இந்த project-ஆல் குறிப்பிடப்பட்டுள்ள கட்டாயக் குறைந்தபட்சத் தேவைகள்.
git, மற்றும் நீங்கள் பயன்படுத்தத் திட்டமிட்டுள்ள model provider-க்கான API key.
Docker, இது session-க்கு ஒரு container sandbox தேவைப்பட்டால் மட்டுமே அவசியம்.

Ubuntu 24.04 அதன் சொந்த repository-ல் Node 18.19-ஐக் கொண்டுள்ளது, இது குறைந்தபட்சத் தேவையை விடக் குறைவு என்பதால், Node-ஐ NodeSource-லிருந்து பெறவும்.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git
node -v
npm -v

node -v கட்டளை v22 அல்லது அதற்கு மேற்பட்ட பதிப்பையும், npm -v கட்டளை 10 அல்லது அதற்கு மேற்பட்ட பதிப்பையும் காட்ட வேண்டும். ஒருவேளை node -v இன்னும் v18.19.1 என்று காட்டினால், distribution package இன்னும் நிறுவப்பட்டிருக்கிறது மற்றும் அது PATH-ல் முன்னுரிமை பெறுகிறது என்று அர்த்தம். நீங்கள் தொடரும் முன் அதை நீக்கவும், ஏனெனில் build செயல்முறை shell கண்டறியும் எந்த node-ஐப் பயன்படுத்துகிறதோ அதையே அடிப்படையாகக் கொண்டு இயங்கும்.

v0.3.2 tag-லிருந்து SandBase-ஐ நிறுவுதல்

ஒரு moving branch-லிருந்து அல்லாமல், எப்போதும் ஒரு tag-லிருந்து மட்டுமே நிறுவவும். main-ன் bare clone-ஐப் பயன்படுத்தினால், ஒரு மணி நேரத்திற்கு முன்பு சேர்க்கப்பட்ட மாற்றங்கள் உங்களுக்குக் கிடைக்கும்; கீழே உள்ள config keys அதனுடன் ஒத்துப்போகாமல் போகலாம். 16 August 2026 நிலவரப்படி v0.3.2 தற்போதைய tag ஆகும்.

sudo install -d -o "$USER" -g "$USER" /opt/sandbase
cd /opt/sandbase
git clone --branch v0.3.2 --depth 1 https://github.com/sandbaseai/sandbase-harness.git
cd sandbase-harness
npm ci
npm run build

npm install-ஐப் பயன்படுத்தாமல், npm ci-ஐப் பயன்படுத்தவும். ci, committed lockfile-ல் உள்ள துல்லியமான பதிப்புகளை நிறுவுகிறது, எனவே உங்கள் tree, maintainers சோதித்த அதே tree-யுடன் ஒத்துப்போகும். npm install புதிய பதிப்புகளைத் தேடி நிறுவும், இதனால் pinned tag-ன் நோக்கம் சிதைந்துவிடும்.

இப்போது ஒரு workspace-ஐ உருவாக்கவும். Workspace என்பது உங்கள் agent கோப்புகள் மற்றும் runtime state-ஐ வைத்திருக்கும் ஒரு தனி directory ஆகும். இதை source checkout-க்கு வெளியே வைத்திருப்பதன் மூலம், உங்கள் தரவுகளைப் பாதிக்காமல் புதிய tag-ஐ pull செய்ய முடியும்.

mkdir -p /opt/sandbase/workspace
cd /opt/sandbase/workspace
node /opt/sandbase/sandbase-harness/dist/index.js init
node /opt/sandbase/sandbase-harness/dist/index.js start

init, workspace-க்குள் ஒரு .managed-agents/ directory-ஐ உருவாக்குகிறது. start, http://127.0.0.1:3000/dashboard-ல் console-ஐயும், http://127.0.0.1:3000/v1-ல் API-யையும் இயக்குகிறது. இவை உங்கள் laptop-லிருந்து இன்னும் அணுக முடியாத நிலையில் இருக்கும்; இது சரியானதே, இதைப் பற்றி கீழே விரிவாகக் காண்போம். இப்போதைக்கு SSH வழியாக console-ஐ அணுகவும்:

ssh -N -L 3000:127.0.0.1:3000 you@your-server

அந்த நீண்ட node .../dist/index.js path-ஐப் பயன்படுத்துவது கடினமாக இருப்பதால், அதற்கு ஒரு பெயரை இடவும்.

alias sandbase='node /opt/sandbase/sandbase-harness/dist/index.js'

கீழே உள்ள கட்டளைகள் அந்த அடிப்படையில் sandbase <command> என எழுதப்பட்டுள்ளன.

npm மூலம் இதை நிறுவ வேண்டாம்

இந்தத் திட்டத்தின் சொந்த நிறுவல் ஆவணத்திலேயே இது குறிப்பிடப்பட்டுள்ளது: npm-ல் காணப்படும் unscoped managed-agents தொகுப்பு இந்தத் திட்டத்தைச் சேர்ந்தது அல்ல. எனவே, npx managed-agents மற்றும் npm install -g managed-agents ஆகியவற்றை இயக்குவது, நீங்கள் எதிர்பார்க்கும் runtime-க்கு தொடர்பில்லாத ஒன்றையே பதிவிறக்கும். பராமரிப்பாளர்கள் அதிகாரப்பூர்வமான scoped தொகுப்பை அறிவிக்கும் வரை, GitHub-ல் உள்ள tagged source-லிருந்து நிறுவுங்கள். இது இந்தத் திட்டத்தின் வரலாற்றில் ஒரு சிறிய குறிப்பு அல்ல: பழைய npm quick start முறைக்கு மாற்றாக, pinned tagged-source பாதையைப் பயன்படுத்துவதற்காகவே v0.3.1 பதிப்பு முக்கியமாக உருவாக்கப்பட்டது.

Workspace-ஐ ஒரு model provider-உடன் இணைத்தல்

init, .managed-agents/config.yaml-ஐ எழுதுகிறது. முழு workspace-க்கும் ஒரு provider மட்டுமே அமைக்கப்படும், அதன் பிறகு தனிப்பட்ட agents தங்களுக்குத் தேவையான model ID-களைத் தேர்வு செய்துகொள்ளும்.

model:
  provider: openai
  api_key: ${OPENAI_API_KEY}
storage:
  metadata:
    provider: sqlite
    options: {}
  artifacts:
    provider: local
    options:
      base_path: files

${OPENAI_API_KEY} படிவம், process environment-லிருந்து மதிப்பை எடுத்துக்கொள்கிறது. எனவே, இந்த key configuration கோப்பிலோ அல்லது அதன் backup-களிலோ இடம்பெறாது. இதை root பயனர் மட்டுமே படிக்கக்கூடிய ஒரு environment கோப்பில் வைக்கவும்; ஏனெனில், privileges குறைப்பதற்கு முன்பே systemd, EnvironmentFile=-ஐ root பயனராகவே படிக்கிறது.

sudo install -d -m 750 /etc/sandbase
sudo touch /etc/sandbase/runtime.env
sudo chmod 600 /etc/sandbase/runtime.env

அந்தக் கோப்பை ஒரு editor-ல் திறந்து, OPENAI_API_KEY=sk-... என்ற வரியைச் சேர்க்கவும். Provider keys-ஐ இங்கே வைக்க வேண்டும். ஒரு session-ன் போது agent பயன்படுத்தும் ரகசியத் தகவல்கள் (secrets), runtime-ன் credential vaults-ல் இருக்க வேண்டும். இது வேறுபட்ட பாதிப்பு எல்லைகளைக் கொண்ட ஒரு தனிப்பட்ட சிக்கலாகும். எனவே, production token-ஐ எங்கு பதிவேற்றுவதற்கு முன்பும் AI agents-லிருந்து ரகசியங்களை விலக்கி வைத்தல் என்ற கட்டுரையை வாசிப்பது அவசியம்.

Agent YAML: mcp_servers, tools மற்றும் அனுமதி கொள்கைகள்

Agents என்பவை workspace-ல் உள்ள agents/ directory-ல் YAML கோப்புகளாக வரையறுக்கப்படுகின்றன. runtime-ன் இந்த பகுதியில்தான் நீங்கள் அதிக நேரம் செலவிடுவீர்கள்.

name: Incident commander
description: Triages alerts and coordinates response.
model: gpt-4o
system: |-
  You are an on-call incident commander.
mcp_servers:
  - name: sentry
    type: url
    url: https://mcp.sentry.dev/mcp
tools:
  - type: agent_toolset_20260401
    default_config:
      permission_policy: { type: always_ask }
    configs:
      - name: bash
        permission_policy: { type: always_ask }
  - type: mcp_toolset
    mcp_server_name: sentry
metadata:
  template: incident-commander

இதை load செய்து, அது சரியாகச் சேர்ந்துள்ளதா எனச் சரிபார்க்கவும்:

sandbase reload
sandbase list
sandbase chat agent_assistant --message "hello"

reload, seed YAML-ஐ SQLite-க்குள் இறக்குமதி செய்கிறது. list இப்போது அந்த agent-ஐ அதன் ID-யுடன் காட்ட வேண்டும். list-ல் அது தெரியவில்லை என்றால், கோப்பு parse செய்யப்படவில்லை என்று அர்த்தம்; அதற்கான காரணம் .managed-agents/logs/runtime.log-ல் குறிப்பிடப்பட்டிருக்கும்.

mcp_servers, MCP (model context protocol) endpoints-ஐ அறிவிக்கிறது. type: url என்பது, runtime வேறொரு இடத்தில் இயங்கும் server-உடன் HTTP மூலம் தொடர்பு கொள்கிறது என்று பொருள். எனவே, நீங்கள் ஏற்கனவே இயக்கும் எதையும் இங்கே பயன்படுத்தலாம்; runtime இயங்கும் அதே VPS-ல் உள்ள MCP servers-உம் இதில் அடங்கும்.

ஒரு server-ஐ அறிவிப்பது மட்டும் அதன் கருவிகளை (tools) agent-க்கு வழங்கிவிடாது. tools பட்டியல் அதைச் செய்கிறது; இதில் உள்ள mcp_toolset பதிவின் mcp_server_name, மேலே உள்ள name-உடன் பொருந்த வேண்டும். MCP கருவிகள் இல்லாதது போல agent செயல்பட்டால், வேறு எதையும் சோதிக்கும் முன் அந்த இரண்டு strings-களையும் எழுத்து வாரியாக ஒப்பிட்டுப் பார்க்கவும்.

agent_toolset_20260401 என்பது உள்ளமைக்கப்பட்ட (built-in) tool set ஆகும். இதில் உள்ள தேதி சார்ந்த suffix ஒரு schema version ஆகும்; எனவே, அதனுடன் இணைக்கப்பட்ட (pinned) ஒரு agent, தான் உருவாக்கப்பட்டபோது இருந்த tool definitions-ஐயே தொடர்ந்து பயன்படுத்தும். default_config அந்தத் தொகுப்பில் உள்ள அனைத்து கருவிகளுக்கும் கொள்கையை (policy) அமைக்கிறது. configs-க்குக் கீழ் உள்ள ஒவ்வொரு பதிவும், ஒரு கருவியை அதன் பெயரைக் கொண்டு மாற்றியமைக்கிறது (உதாரணத்திற்கு bash).

permission_policy என்பது, ஒரு சாதாரண model call-ஐ விட runtime எதனால் சிறந்தது என்பதைக் காட்டும் இடமாகும். always_ask, session-ஐ நிறுத்தி வைத்து, ஒரு call இயங்குவதற்கு முன் மனிதரின் ஒப்புதலுக்காகக் காத்திருக்கும். always_allow அதை அனுமதிக்கிறது. bash-ஐ always_ask என அமைத்தால், நீங்கள் துல்லியமான கட்டளையைப் பார்க்கும் வரை agent-ஆல் எந்த shell கட்டளையையும் இயக்க முடியாது. Claude Code-ஐ VPS-ல் பாதுகாப்பாக இயக்குவது போன்ற அதே கட்டுப்பாட்டை இது உங்களுக்கு வழங்குகிறது.

மூன்று sandbox முறைகள் மற்றும் அவை ஒவ்வொன்றும் பொருந்தும் சூழல்கள்

குறியீட்டை இயக்கும் tool calls ஒரு sandbox-க்குள் இயங்குகின்றன. இதற்கான backend, அந்த environment-ன் config object-ல் உள்ள sandbox_provider மூலமாகவோ அல்லது console-ல் உள்ள Settings மற்றும் Sandbox பகுதியிலோ தேர்ந்தெடுக்கப்படுகிறது. Environment-கள் POST /v1/environments API மூலம் உருவாக்கப்படுகின்றன.

local என்பது runtime-ன் ஒரு child process-ஆக, host-ல், runtime-ன் சொந்த பயனர் உரிமையுடன் குறியீட்டை இயக்குகிறது. இதுவே இயல்புநிலை (default) அமைப்பாகும். நீங்கள் மட்டுமே பயனராக இருக்கும்போதும், agent நீங்கள் வைத்திருக்கும் கோப்புகளை மட்டுமே வாசிக்கும்போதும் இது போதுமானது. இது ஒரு தனிமைப்படுத்தப்பட்ட (isolation) சூழல் அல்ல. கோப்புகளை நீக்கும் ஒரு tool call உங்கள் கோப்புகளை நீக்கிவிடும், மேலும் /etc/sandbase/runtime.env-ஐ வாசிக்கும் ஒரு tool call உங்கள் provider key-ஐயும் வாசித்துவிடும்.

docker ஒவ்வொரு session-க்கும் ஒரு container-ஐத் தொடங்குகிறது.

{
  "sandbox_provider": "docker",
  "image": "node:22-slim",
  "resources": { "memory": "1g", "cpu": 1 }
}

இந்த session-க்கு எனத் தனி filesystem, memory அளவு மற்றும் CPU பங்கு ஒதுக்கப்படும். Session முடிந்ததும் அந்த container நீக்கப்படும். நீங்கள் எழுதாத குறியீட்டை ஒரு agent இயக்கும்போது, உடனடியாக இந்த முறைக்கு மாறவும். இதில் உள்ள சிக்கல் என்னவென்றால், runtime பயனருக்கு Docker socket-க்கான அணுகல் தேவைப்படும். docker குழுவில் உறுப்பினராக இருப்பது, host-ல் root பயனர் உரிமையைப் பெறுவதற்குச் சமம். ஒவ்வொரு session-க்கும் தனி container என்பது ஒரு run-க்கு ஒரு container கொண்ட self-hosted agent sandboxes போன்றதே. எனவே, ஒரு escaped process எதை அடைய முடியும் என்பது குறித்த காரணங்கள் இதற்கும் அப்படியே பொருந்தும்.

kubernetes என்பது session workload-ஐ ஒரு pod-ஆக இயக்கி, அதை kubectl exec மற்றும் kubectl cp மூலம் கட்டுப்படுத்துகிறது. Runtime image-ல் kubectl இருக்க வேண்டும். மேலும், அதன் ServiceAccount-க்கு target namespace-ல் உள்ள pod-களை உருவாக்க, நீக்க, பெற, பட்டியலிட மற்றும் கண்காணிக்க RBAC (role-based access control) அனுமதி தேவை. அதனுடன் exec subresource அனுமதியும் அவசியம். நீங்கள் ஏற்கனவே ஒரு cluster-ஐப் பயன்படுத்தினால் மட்டுமே இந்த முறையை அமைப்பது பயனுள்ளதாக இருக்கும்.

runtime ஏன் 127.0.0.1-ல் பிணைக்கப்பட்டுள்ளது (bound)?

ஏனெனில் இது authentication முடக்கப்பட்ட நிலையில் தொடங்குகிறது. குறைந்தது ஒரு API key இருக்கும்போது மட்டுமே runtime bearer-token authentication-ஐ செயல்படுத்துகிறது, மேலும் புதிய init எதையும் உருவாக்குவதில்லை. அந்த default நிலையில் 0.0.0.0-ல் பிணைப்பது, shell tools மற்றும் உங்கள் provider key-ஐக் கொண்ட ஒரு authentication இல்லாத agent runtime-ஐ பொது இணையத்தில் (public internet) வைப்பதற்குச் சமம்.

எனவே, இதை அணுகக்கூடியதாக மாற்ற விரும்பினால், bind address-ஐ மாற்றாமல் விட்டுவிட்டு, பின்வரும் இரண்டு விஷயங்களைச் செய்யுங்கள்.

முதலில், authentication-ஐச் செயல்படுத்துங்கள். service environment கோப்பில் MANAGED_AGENTS_API_KEY-ஐ அமைக்கவும், அல்லது POST /v1/api-keys மூலம் ஒரு key-ஐ உருவாக்கவும்; இது ஒருமுறை மட்டுமே secret_key புலத்தைக் காட்டும், அதன் பிறகு மீண்டும் காட்டாது. அதன் பிறகு, clients ஒவ்வொரு கோரிக்கையிலும் (request) Authorization: Bearer <key>-ஐ அனுப்ப வேண்டும்.

இரண்டாவதாக, ஒரு reverse proxy-ஐ முன்னால் வைத்து, அங்கு TLS (transport layer security)-ஐ முடிவுக்குக் கொண்டு வாருங்கள் (terminate). runtime வடிவமைப்பிலேயே plain HTTP-ஐ மட்டுமே வழங்குகிறது, எனவே certificates-ஐக் கையாள வேறொரு கருவியை இது எதிர்பார்க்கிறது.

server {
    listen 443 ssl;
    server_name agents.example.com;

    ssl_certificate     /etc/letsencrypt/live/agents.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agents.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

அவற்றில் இரண்டு வரிகள் அலங்காரத்திற்காக இல்லை. proxy_buffering off முக்கியமானது, ஏனெனில் sessions server-sent events (SSE) வழியாகத் தொடர்ச்சியாகச் செல்கின்றன (stream). buffering செயல்பாட்டில் இருந்தால், அதன் buffer நிறையும் வரை nginx பதிலை நிறுத்தி வைக்கும். இதனால் agent வேலை செய்யும்போது console-ல் எதுவும் தெரியாது, வேலை முடிந்ததும் அனைத்தும் ஒரே நேரத்தில் திரையில் தோன்றும். proxy_read_timeout 3600s முக்கியமானது, ஏனெனில் default கால அளவு 60 வினாடிகள் மட்டுமே. எனவே, ஒரு நிமிடம் அல்லது அதற்கு மேல் stream அமைதியாக இருந்தால், proxy அந்த இணைப்பைத் துண்டித்துவிடும். இது runtime செயலிழந்தது போன்ற பிழையைக் காட்டும்.

Firewall-ல், 22 மற்றும் 443 ஆகிய ports-ஐத் திறந்து வையுங்கள். 3000-ஐ மூடியே வைத்திருங்கள், ஏனெனில் proxy இதை loopback வழியாகவே அணுகுகிறது, எனவே பெட்டிக்கு (box) வெளியே இருந்து எவரும் இதை அணுக வேண்டிய அவசியமில்லை.

Anthropic SDK-ஐ உங்கள் சொந்த server-க்கு திருப்புதல்

இந்த runtime ஒரு CMA-வடிவிலான /v1 surface-ஐ செயல்படுத்துகிறது, எனவே ஒரு Anthropic SDK client ஒரு field-ஐ மட்டும் மாற்றி இதனுடன் தொடர்பு கொள்கிறது.

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  apiKey: process.env.MANAGED_AGENTS_API_KEY ?? 'local-dev-key',
  baseURL: 'http://127.0.0.1:3000'
});

இது Claude Managed Agents clients அனுப்பும் beta headers-களையும் ஏற்கிறது, அவை anthropic-beta: managed-agents-2026-04-01 மற்றும் anthropic-beta: agent-memory-2026-07-22 ஆகும். உள்ளூர் runtime-க்கு இவை கட்டாயமில்லை. hosted deployment-க்காக எழுதப்பட்ட code, எவ்வித மாற்றமுமின்றி இங்கே இயங்குவதற்காகவே இவை உள்ளன.

இணக்கத்தன்மை (compatibility) முழுமையானது அல்ல, நெருக்கமானது மட்டுமே. ஒரு surface உள்ளது என்று கருதுவதற்கு முன், checkout-ல் உள்ள docs/api-matrix.md-ஐ வாசிக்கவும். ஏனெனில், client-side custom tools உட்பட, தற்போதைய event-result protocol-க்கு மேல் பெயரிடப்பட்ட பதிவு (named registration) தேவைப்படும் இடைவெளிகளை இந்த project ஆவணப்படுத்தியுள்ளது.

Plain HTTP-ம் சிறப்பாகச் செயல்படும், runtime இயங்குகிறதா என்பதை உறுதிப்படுத்த இதுவே விரைவான வழி:

curl -N -X POST http://127.0.0.1:3000/v1/sessions/SESSION_ID/messages \
  -H "Content-Type: application/json" \
  -d '{"content": "Hello", "stream": true}'

சரியான response என்பது தொடர்ந்து வந்து கொண்டிருக்கும் events-ன் stream ஆகும். connection துண்டிக்கப்பட்டால், முழு turn-ஐயும் மீண்டும் இயக்குவதற்குப் பதிலாக, நீங்கள் கடைசியாகப் பார்த்த event-லிருந்து தொடரவும்:

curl -N http://127.0.0.1:3000/v1/sessions/SESSION_ID/events/stream \
  -H "Last-Event-ID: EVENT_ID"

இந்த resumable stream-ன் காரணமாகவே, laptop-ஐ மூடினாலும் ஒரு session நீடிக்கிறது. events server-ல் சேமிக்கப்படுவதால், client ஒரே நகலை வைத்திருப்பதற்குப் பதிலாக, ஒரு log-ஐ மீண்டும் இயக்குகிறது.

நற்சான்றிதழ்கள், நினைவகம் மற்றும் தணிக்கை தடயங்கள் வட்டில் எங்கு சேமிக்கப்படுகின்றன

Runtime-க்கு சொந்தமான அனைத்தும் workspace-ல் உள்ள .managed-agents/ கோப்பகத்தின் கீழ் உள்ளன.

.managed-agents/
├── config.yaml
├── data.db
├── logs/runtime.log
├── files/
├── skills/
├── snapshots/
└── sandbox/

data.db என்பது SQLite மெட்டாடேட்டா ஆகும்: இதில் agents, sessions, credential vault பதிவுகள், memory store பதிவுகள் மற்றும் API keys ஆகியவை அடங்கும்.
files/ பதிவேற்றப்பட்ட கோப்பு பைட்டுகளைக் கொண்டுள்ளது மற்றும் skills/ பதிவேற்றப்பட்ட skill packages-ஐக் கொண்டுள்ளது.
snapshots/ session workspace snapshots-ஐக் கொண்டுள்ளது, மற்றும் sandbox/ local-mode sessions-ன் working directories-ஐக் கொண்டுள்ளது.
ஏதேனும் ஒன்று எந்தவித அறிகுறியுமின்றி செயல்படவில்லை என்றால், முதலில் பார்க்க வேண்டிய இடம் logs/runtime.log ஆகும்.

Credential vaults என்பது ரகசியங்களின் தொகுப்பாகும், ஒவ்வொன்றும் environment_variable போன்ற auth_type மூலம் சேர்க்கப்பட்டு, session உருவாக்கப்படும்போது vault_ids வழியாக இணைக்கப்படுகிறது. Memory stores என்பது நீங்கள் ஒரு memory_store ஆக session-ல் mount செய்யும் பெயரிடப்பட்ட பதிவுகளைக் கொண்டுள்ளது, இதற்கு தனித்துவமான அணுகல் அமைப்புகள் மற்றும் அறிவுறுத்தல்கள் இருக்கும். இவை இரண்டும் data.db-ல் சேமிக்கப்படுகின்றன; இதுவே ஒரு சாதாரண model call-க்கும் இதற்கும் உள்ள வித்தியாசம்: runtime அமர்வுகளுக்கு இடையிலும் தகவல்களை நினைவில் கொள்கிறது, மேலும் என்ன நடந்தது என்பதைப் பதிவு செய்கிறது.

இது ஒரே கோப்பகமாக இருப்பதால், முழுவதையும் ஒரே தொகுப்பாக backup எடுக்கவும்.

sudo systemctl stop sandbase
sudo tar czf /root/sandbase-$(date +%F).tgz -C /opt/sandbase/workspace .managed-agents
sudo systemctl start sandbase

முதலில் service-ஐ நிறுத்தவும். Runtime எழுதிக்கொண்டிருக்கும்போது SQLite database-ஐ நகலெடுப்பது, restore செய்யும்போது திறக்க முடியாத கோப்பை உருவாக்கக்கூடும்; இது உங்களுக்குத் தேவைப்படும் நாளில் தெரியவரும். நீங்கள் agent YAML-ஐ git-லும், state-ஐ வேறு இடத்திலும் வைத்திருக்க விரும்பினால், deployment ஆவணம் start-ல் --data-dir மூலம் state இருப்பிடத்தை மாற்றியமைக்க அனுமதிக்கிறது.

Restore செய்வது இதற்கு நேர்மாறானது: புதிய கணினியில் அதே tag-ஐ checkout செய்யவும், archive-ஐ workspace-ல் விரிக்கவும், பின் service-ஐத் தொடங்கவும். நீங்கள் ${OPENAI_API_KEY} படிவத்தைப் பயன்படுத்தியிருந்தால், உங்கள் provider key அந்த archive-ல் இருக்காது, எனவே அதைத் தனியாகப் பாதுகாப்பாக வைத்திருக்கவும்.

systemd-ன் கீழ் இயக்குதல்

Runtime-க்கு எனத் தனி user-ஐ உருவாக்கவும். இதன் மூலம் local sandbox mode-ல் உள்ள ஒரு கருவி உங்களைப் போலவே செயல்படுவதைத் தடுக்கலாம்.

sudo adduser --system --group --no-create-home --home /opt/sandbase sandbase
sudo chown -R sandbase:sandbase /opt/sandbase

இதை /etc/systemd/system/sandbase.service என்ற பெயரில் சேமிக்கவும்.

[Unit]
Description=SandBase Harness runtime
After=network-online.target

[Service]
User=sandbase
Group=sandbase
WorkingDirectory=/opt/sandbase/workspace
EnvironmentFile=/etc/sandbase/runtime.env
ExecStart=/usr/bin/node /opt/sandbase/sandbase-harness/dist/index.js start --host 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

இந்தத் திட்டத்தின் deployment உதாரணம் PATH-ல் உள்ள ஒரு managed-agents binary-ஐ அழைக்கிறது. Tagged-source நிறுவல் இதை உருவாக்காது, எனவே ExecStart ஆனது உருவாக்கப்பட்ட entry point-க்கு எதிராக node-ஐ இயக்குகிறது.

sudo systemctl daemon-reload
sudo systemctl enable --now sandbase
sudo systemctl status sandbase
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/dashboard

சரியான முடிவானது status-லிருந்து active (running) மற்றும் curl-லிருந்து 200 ஆகும். வேறு ஏதேனும் முடிவு வந்தால், முதலில் journalctl -u sandbase -n 50-ஐயும், இரண்டாவதாக .managed-agents/logs/runtime.log-ஐயும் வாசிக்கவும். enable --now என்பது மிக முக்கியமான பகுதியாகும், ஏனெனில் கைமுறையாகத் தொடங்கப்பட்ட process, அடுத்த முறை reboot செய்த பிறகு இயங்காது.

எவை செயலிழக்கின்றன மற்றும் நீங்கள் காணும் செய்திகள்

npm run build எந்த பிழைச் செய்தியும் இன்றி npm-ஆல் நிறுத்தப்படுகிறது. 1 GB VPS-ல், TypeScript compile செய்யும்போது kernel-ன் out-of-memory killer அதை நிறுத்திவிடுகிறது. இது npm-க்குத் தெரியாமல் kernel log-ல் பதிவாகும். journalctl -k | grep -i "out of memory" கட்டளையைப் பயன்படுத்தி இதை உறுதிப்படுத்தவும்; இது நிறுத்தப்பட்ட node process-ன் பெயரை ஒரு வரியில் காட்டும். Swap-ஐச் சேர்க்கவும் அல்லது அதிக திறன் கொண்ட instance-ல் build செய்து dist/ கோப்பை நகலெடுக்கவும்.

Error: listen EADDRINUSE: address already in use 127.0.0.1:3000. வேறொரு process ஏற்கனவே அந்த port-ஐப் பயன்படுத்துகிறது. sudo ss -lntp | grep 3000 அந்த process-ன் பெயரைத் தெரிவிக்கும். அந்த process-ஐ நிறுத்தவும் அல்லது --port 3001 கட்டளையுடன் runtime-ஐத் தொடங்கி proxy-ஐப் புதுப்பிக்கவும்.

உங்கள் மடிக்கணினியிலிருந்து dashboard ஏற்றப்படவில்லை. இது இயல்பான செயல்பாடே, ஏனெனில் runtime loopback-ல் மட்டுமே இணைகிறது. மேலே உள்ள SSH tunnel-ஐப் பயன்படுத்தவும் அல்லது reverse proxy அமைப்பை முடிக்கவும். --host 0.0.0.0 கட்டளையைப் பயன்படுத்தி இதைச் சரிசெய்ய முயற்சிக்க வேண்டாம், ஏனெனில் key உருவாக்கப்படும் வரை authentication முடக்கப்பட்டிருக்கும்.

Docker sandboxes permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock பிழையுடன் தோல்வியடைகின்றன. sandbase பயனர் docker குழுவில் இல்லை. sudo usermod -aG docker sandbase கட்டளையைப் பயன்படுத்தி இதைச் சரிசெய்து service-ஐ restart செய்யவும். நீங்கள் வழங்கிய அனுமதியைப் புரிந்துகொள்ளுங்கள்: அந்த குழு host-ல் root அதிகாரத்தைக் கொண்டது, எனவே runtime-க்குத் தனிப் பயனர் உருவாக்கியதன் நோக்கத்தின் ஒரு பகுதியை இது நீக்கிவிடுகிறது.

Kubernetes sandboxes Error from server (Forbidden) பிழையுடன் தோல்வியடைகின்றன. ServiceAccount-க்கு pod அனுமதிகள் அல்லது exec subresource இல்லை. kubectl auth can-i create pods/exec -n <namespace> கட்டளையைப் பயன்படுத்தி நேரடியாகச் சரிபார்க்கவும்; இது yes அல்லது no என்ற பதிலை அளிக்கும்.

API key சேர்த்த பிறகு ஒவ்வொரு கோரிக்கையும் 401 பிழையைத் தருகிறது. முதல் key உருவாக்கப்பட்டவுடன் authentication செயல்பாட்டுக்கு வந்துவிடும்; இது API-க்கு மட்டுமல்லாமல் console-க்கும் பொருந்தும். Authorization: Bearer <key> கட்டளையை அனுப்பவும். ஒருவேளை key-ஐத் தொலைத்துவிட்டால், புதிய ஒன்றை உருவாக்கவும், ஏனெனில் secret_key ஒருமுறை மட்டுமே காட்டப்படும், அது படிக்கக்கூடிய வடிவில் சேமிக்கப்படாது.

MCP server-ன் கருவிகள் session-ல் தோன்றவில்லை. mcp_servers-ல் உள்ள name-க்கு எதிராக tools தொகுதியில் உள்ள mcp_server_name-ஐச் சரிபார்க்கவும். பின்னர், curl -i <url> கட்டளையைப் பயன்படுத்தி server-லிருந்து அந்த URL-ஐ அணுக முடிகிறதா என்று பார்க்கவும். URL-வகை MCP server ஒரு network dependency ஆகும்; உங்கள் மடிக்கணினியை விட VPS-ல் பெயர்களைத் தீர்க்கும் (resolve) முறையும் traffic செல்லும் பாதையும் மாறுபடும்.

FAQ

OpenAI அல்லது Anthropic key இல்லாமல் என்னால் SandBase Harness-ஐ இயக்க முடியுமா?

முடியும், உங்களிடம் OpenAI-க்கு இணக்கமான (compatible) endpoint இருந்தால் இதைச் செய்யலாம். இந்த runtime, OpenAI, Anthropic மற்றும் OpenAI-க்கு இணக்கமான பிற providers-ஐ ஆதரிக்கிறது. எனவே, OpenAI API-ஐ ஏற்கும் எந்தவொரு local server-ம் வேலை செய்யும். .managed-agents/config.yaml-ல் workspace provider-ஐ அமைத்து, api_key மற்றும் endpoint-ஐ அதற்குச் சுட்டிக்காட்டவும். இந்த runtime-ல் சொந்தமாக எந்த model-ம் இல்லை, எனவே அழைப்புகளுக்குப் பதிலளிக்க ஏதேனும் ஒரு சேவை அவசியம்.

Runtime-ஐ public port-ல் வெளிப்படுத்துவது பாதுகாப்பானதா?

இயல்புநிலை அமைப்பில் இது பாதுகாப்பானது அல்ல. இது 127.0.0.1:3000-ல் bind ஆகி, authentication இல்லாமலேயே தொடங்குகிறது. இதைச் சரிசெய்ய, bind address-ஐ மாற்றுவது தீர்வாகாது. ஒரு API key-ஐ உருவாக்கவும் அல்லது MANAGED_AGENTS_API_KEY-ஐ அமைக்கவும்; இது bearer-token authentication-ஐச் செயல்படுத்தும். பிறகு, TLS-க்காக nginx அல்லது Caddy-ஐ முன்னால் வைத்து, firewall-ல் port 3000-ஐ மூடிவிடவும். இதன் மூலம் proxy வழியாக மட்டுமே உள்ளே நுழைய முடியும்.

Local, Docker மற்றும் Kubernetes sandboxes-க்கு இடையே உள்ள வேறுபாடு என்ன?

local, tool code-ஐ host-ல் உள்ள runtime-ன் child process-ஆக, runtime user-ன் அனுமதியுடன், எந்தவிதமான தனிமைப்படுத்தலும் (isolation) இன்றி இயக்குகிறது. docker, ஒவ்வொரு session-க்கும் தனித்தனி container-ஐ வழங்குகிறது. இதில் தனித்தனி filesystem, memory limit மற்றும் CPU share இருக்கும்; session முடிந்ததும் இது நீக்கப்படும். kubernetes, session-ஐ ஒரு pod-ஆக இயக்கி, kubectl exec மூலம் கட்டுப்படுத்துகிறது. இதற்கு runtime image-க்குள் kubectl-ம், target namespace-ல் pods மற்றும் exec subresource-க்கான RBAC அனுமதியும் தேவை.

நான் எதை backup எடுக்க வேண்டும்?

Workspace-ல் உள்ள .managed-agents/ directory-ஐ backup எடுக்க வேண்டும். இதில் config.yaml, agents, sessions, credential vault entries மற்றும் memory entries கொண்ட data.db SQLite database, அத்துடன் பதிவேற்றப்பட்ட கோப்புகள், skill packages மற்றும் session snapshots ஆகியவை உள்ளன. SQLite தரவுத்தளம் நகலெடுக்கும்போது மாற்றப்படாமல் இருக்க, நகலெடுப்பதற்கு முன் service-ஐ நிறுத்தவும். ${OPENAI_API_KEY} எனக் குறிப்பிடப்படும் provider API keys இந்த backup-ல் இருக்காது, எனவே அவற்றைத் தனியாகச் சேமிக்கவும்.

main branch-க்கு பதிலாக v0.3.2 tag-ஐ ஏன் clone செய்ய வேண்டும்?

Tag என்பது ஒரு நிலையான tree ஆகும். எனவே, நீங்கள் படிக்கும் config keys மற்றும் CLI commands உங்களுக்குக் கிடைக்கும். main அடிக்கடி மாறக்கூடியது, மேலும் ஒரு வழிகாட்டி எழுதப்பட்டதற்கும் நீங்கள் அதை இயக்கும் காலத்திற்கும் இடையில் ஒரு config key-ன் பெயர் மாறக்கூடும். மேலும், npm-ல் உள்ள unscoped managed-agents package இந்த project-ஐச் சேர்ந்தது அல்ல என்றும், npx managed-agents தவறான ஒன்றை install செய்யும் என்றும் project எச்சரிக்கிறது. Release v0.3.1, npm quick start-க்கு பதிலாக pinned tagged-source பாதையைப் பயன்படுத்துவதற்காகவே உருவாக்கப்பட்டது.

#ai-agents #mcp #self-hosting #sandboxing#anthropic-sdk

Built for exactly this: a fresh Ubuntu 24.04 KVM VPS with root.

SSD Nodes-ன் 15 ஆண்டுகள், அனைத்திற்கும் 15% தள்ளுபடி: எந்தத் திட்டமும், எந்தக் கட்டணச் சுழற்சியும், புதிய மற்றும் ஏற்கனவே உள்ள வாடிக்கையாளர்களும். முழு root access, 4TB தரவு பரிமாற்றம், 14 நாள் பணம் திரும்பப் பெறும் உத்தரவாதம்.

செலுத்தும் பக்கத்தில் LEARN15 குறியீடு உங்களுக்காகப் பயன்படுத்தப்படும்.

எனது 15% தள்ளுபடியைப் பெறுக →