Rakazo-வை சொந்தமாக VPS-ல் நிறுவுவது எப்படி?

Rakazo self-hosting-ல் உண்மையில் என்ன இயங்குகிறது

Rakazo-வை self-hosting செய்வது என்பது ஒரு Linux server-ல் ஐந்து விஷயங்களை இயக்குவதாகும்: PostgreSQL, ஒரு Graphile Worker process, API, web app, மற்றும் இயங்கும் ஒவ்வொரு bot-க்கும் ஒரு sandbox container. Rakazo என்பது Grok Bot-க்கு மாற்றாக elie222 என்பவரால் Apache 2.0 உரிமத்தின் கீழ் வெளியிடப்பட்ட ஒரு open-source மென்பொருளாகும். ஒவ்வொரு bot-க்கும் தனித்தனி thread, கணினி, memory மற்றும் வரலாறு ஒதுக்கப்படும்; அது மற்ற peers-ஐ அல்லது குறுகிய கால subagents-ஐ உருவாக்க முடியும்.

இந்த கடைசி அம்சம் காரணமாகவே, இதை ஒரு desktop-ல் இயக்காமல் VPS (virtual private server)-ல் இயக்குவது அவசியம். memory-ஐத் தக்கவைத்துக்கொண்டு திட்டமிடப்பட்ட பணிகளைச் செய்யும் ஒரு bot, நீங்கள் தூங்கும்போது கூட அணுகக்கூடியதாக இருக்க வேண்டும். laptop-ஐ suspend செய்யும்போது, அந்த queue நின்றுவிடும்.

ஆகஸ்ட் 2026 நிலவரப்படி Rakazo ஆரம்பக்கட்ட beta நிலையில் உள்ளது, எனவே இதை ஒரு முழுமையான தயாரிப்பாகக் கருதாமல், செயல்பாட்டில் உள்ள ஒரு அமைப்பாகக் கருதவும். இதன் stack முழுவதும் TypeScript-ல் உள்ளது: web app-க்கு React 19 மற்றும் Vite, API-க்கு Hono, Postgres உடன் Prisma, கணக்குகளுக்கு Better Auth, மற்றும் background பணிகளுக்கு Graphile Worker. Graphile Worker தனது queue-வை Postgres-க்குள்ளேயே சேமிப்பதால், Redis அல்லது இரண்டாவது தரவுத்தளத்தை இயக்க வேண்டிய அவசியமில்லை. .env.example என்பது WAKEUP_DRIVER=graphile-ஐ அமைக்கிறது, அதாவது ஒரு bot விழித்தெழுவது என்பது Postgres-ஆல் ஆதரிக்கப்படும் ஒரு பணியாகும். Postgres-ஐ நிறுத்தினால், திட்டமிடப்பட்ட அனைத்து bot செயல்பாடுகளும் அதனுடன் நின்றுவிடும். பிறரது தயாரிப்பை இயக்குவதற்குப் பதிலாக, நீங்களே ஒரு agent-ஐ உருவாக்க விரும்பினால், கூறுகளைக் கொண்டு சொந்தமாக agent உருவாக்குதல் என்பது மற்றொரு வழியாகும்.

1 GB திட்டம் ஏன் இதற்குப் போதாது

செயல்முறைகளை (processes) எண்ணிப் பாருங்கள். Postgres ஒன்று. API ஒரு Node செயல்முறை. Worker இரண்டாவது. Web app மூன்றாவது. Sandbox supervisor நான்காவது. அதன் பிறகு, இயங்கும் ஒவ்வொரு bot-ம் ஒரு graphical Linux desktop மற்றும் browser-ஐக் கொண்ட container-ஐ வைத்திருக்கும்.

இந்தத் திட்டத்தின் சொந்த self-host ஆவணத்தில் ஒரு உண்மையான புள்ளிவிவரம் உள்ளது: E2B bot desktop-களை நிர்வகிக்கும்போது, API, worker மற்றும் Postgres ஆகியவற்றுக்கு 2 vCPU மற்றும் 4 GB கொண்ட machine போதுமானது. இது control plane-க்கு மட்டுமேயான அளவு, இதன் கடினமான பகுதிகள் வேறொரு இடத்தில் ஹோஸ்ட் செய்யப்படுகின்றன. நீங்கள் SANDBOX_PROVIDER=docker-ஐ அமைத்தால், அந்த desktop-கள் உங்கள் VPS-க்கு மாறிவிடும், எனவே 4 GB என்பது இலக்காக இல்லாமல் அடிப்படைத் தேவையாகிவிடும். ஒன்றுக்கு மேற்பட்ட bot-களை இயக்கத் திட்டமிட்டால் 8 GB-ல் தொடங்குங்கள், மேலும் ஒரு bot இயங்கும்போது docker stats மூலம் உண்மையான அளவீட்டைச் சரிபார்க்கவும். Sandbox-க்குள் இருக்கும் browser தான் memory பயன்பாட்டை அதிகரிக்கும், எனவே spec sheet-ஐ மட்டும் நம்பி முடிவு செய்ய முடியாது. Agent பணிகளுக்காக ஒரு server-ஐத் தேர்வு செய்யும் பொதுவான முறைக்கு, ஒரு agent VPS-க்கு உண்மையில் எவ்வளவு RAM மற்றும் CPU தேவை என்ற கட்டுரை அளவீடுகளை விரிவாக விளக்குகிறது.

ஒரு அமைப்பு இதை மோசமடையாமல் தடுக்கிறது. .env.example ஆனது SANDBOX_IDLE_MS=600000-ஐ ஒரு குறிப்புடன் வழங்குகிறது; அது குறிப்பிட்ட idle மில்லி விநாடிகளுக்குப் பிறகு E2B கணினிகளை இடைநிறுத்துகிறது அல்லது Docker கணினிகளை நிறுத்துகிறது. பத்து நிமிடங்கள் செயலற்று இருந்தால் கணினி நீக்கப்படும். ஏற்றுக்கொள்ளப்பட்ட குறைந்தபட்ச மதிப்பு 30000 ஆகும். இது இல்லையென்றால், நீங்கள் திறந்த ஒவ்வொரு bot-ம் நிரந்தரமாக memory-ஐப் பிடித்துக் கொண்டிருக்கும்.

Disk அளவும் முக்கியம். Sandbox image, Node modules மற்றும் Postgres volume ஆகியவை ஒரே disk-ஐப் பகிர்ந்துகொள்வதால், 40 GB என்பது தொடங்குவதற்குச் சரியான அளவாகும்.

Clone செய்வதற்கு முன் ஒரு version-ஐ pin செய்யவும்

Rakazo மிக வேகமாக மேம்படுத்தப்படுகிறது, மேலும் main என்பது ஒரு release அல்ல. 16 August 2026 நிலவரப்படி, இந்த repository-ல் ஒரே ஒரு tag மட்டுமே உள்ளது, அது v0.1.0-beta ஆகும். இது 13 August 2026 அன்று வெளியிடப்பட்டது மற்றும் இது ஒரு prerelease என குறிக்கப்பட்டுள்ளது.

git clone https://github.com/elie222/rakazo.git
cd rakazo
git checkout 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb
git log -1 --format='%H %ci'

அந்த commit-தான் v0.1.0-beta சுட்டிக்காட்டும் இடமாகும். branch அல்லது tag-ஐப் பயன்படுத்துவதற்குப் பதிலாக, அந்த commit-ஐ pin செய்யவும். அடுத்த git pull-ன் போது branch மாறக்கூடும், மேலும் tag என்பது ஒரு maintainer எப்போது வேண்டுமானாலும் மாற்றக்கூடிய ஒரு label ஆகும். எனவே, இவை இரண்டுமே நீங்கள் மீண்டும் திரும்ப வரக்கூடிய ஒரு குறிப்பிட்ட tree-ஐ அடையாளம் காட்டாது. ஒரு commit identifier மாறாது. உங்களுடைய server தகவல்களுடன் இதையும் குறித்து வைத்துக்கொள்ளுங்கள். ஏனெனில், ஒரு upgrade தோல்வியடையும் போது, அதைச் சரிசெய்வதற்கான எளிய வழி git checkout <old commit> செய்து மீண்டும் உருவாக்குவதுதான். எந்த commit சரியாக வேலை செய்தது என்பது தெரிந்தால் மட்டுமே இது சாத்தியமாகும்.

தேவைகள்: Node 22, pnpm 9, மற்றும் Docker

node -v
pnpm -v
docker --version

package.json, "engines": { "node": ">=22" } மற்றும் "packageManager": "pnpm@9.15.0" ஆகியவற்றை வரையறுக்கிறது, எனவே node -v ஆனது v22 அல்லது அதற்கு மேற்பட்ட பதிப்பை அச்சிட வேண்டும். Ubuntu archive-ல் உள்ள Node package பொதுவாக பழைய பதிப்பாகவே இருக்கும், எனவே NodeSource அல்லது nvm மூலம் நிறுவவும். pnpm ஆனது corepack வழியாக Node-உடன் வருகிறது:

corepack enable
corepack prepare pnpm@9.15.0 --activate

Docker Engine மற்றும் compose plugin ஆகியவை மீதமுள்ள தேவைகளைப் பூர்த்தி செய்கின்றன. உங்கள் user-க்கு daemon-ஐ அணுகும் அனுமதி இருக்க வேண்டும். docker ps கட்டளை permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock என்று பதிலளித்தால், உங்கள் user-ஐ docker குழுவில் சேர்த்துவிட்டு, புதிய login shell-ஐத் திறக்கவும். இதன் விளைவுகளை முதலில் புரிந்துகொள்ளவும்: docker குழுவில் உறுப்பினராக இருப்பது, அந்த கணினியில் root பயனர் உரிமையைப் பெறுவதற்குச் சமம். ஏனெனில், அக்குழுவில் உள்ள எவரும் host filesystem-ஐ mount செய்யும் container-ஐத் தொடங்க முடியும்.

.env கோப்பை உள்ளமைத்து, Postgres-ஐத் தொடங்கவும்

cp .env.example .env
chmod 600 .env

எந்தவொரு சேவையும் நெட்வொர்க்குடன் இணைக்கப்படுவதற்கு முன்பு, இரண்டு மதிப்புகளை மாற்ற வேண்டும். .env.example ஆனது BETTER_AUTH_SECRET=replace-with-32-plus-character-secret மற்றும் ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase ஆகியவற்றை வழங்குகிறது. மேம்பாட்டுச் சூழலுக்கு (development) வெளியே இந்த placeholder மதிப்புகளைப் பயன்படுத்தினால் Rakazo நிராகரித்துவிடும். எனவே, களஞ்சியத்தில் (repository) பகிரப்பட்ட ரகசியக் குறியீட்டில் இயங்குவதைத் தவிர்க்க, முழுமையற்ற உள்ளமைவு கொண்ட deploy தோல்வியடையும்.

openssl rand -base64 48
openssl rand -hex 32

அதன்பிறகு, தரவுத்தளத்தைத் தனியாகத் தொடங்கி, migrations-ஐ இயக்கவும்.

docker compose --env-file .env -f infra/compose/docker-compose.yml up postgres -d
pnpm install
pnpm db:generate
pnpm db:migrate
pnpm sandbox:build

pnpm sandbox:build ஆனது bot கணினி பிம்பத்தை (image) உருவாக்குகிறது, இது package.json-ல் docker build -t rakazo/computer:local infra/sandboxes/computer என வரையறுக்கப்பட்டுள்ளது. இது ஒரு வரைகலை (graphical) பிம்பம் என்பதால், முதல்முறை உருவாக்கும்போது அதிக தரவுகளைப் பதிவிறக்கம் செய்யும், எனவே இதற்கு நேரம் எடுக்கும். docker image ls rakazo/computer கட்டளையைப் பயன்படுத்தி அது பதிவேற்றப்பட்டதை உறுதிப்படுத்தவும்; இது ஒரு வரி வெளியீட்டைத் தர வேண்டும்.

Compose கோப்பானது Postgres-ஐ 127.0.0.1:5433:5432-ல் வெளியிடுகிறது, இது loopback-க்கு மட்டுமே உரியது. அதை அப்படியே விடவும். மேம்பாட்டுச் சான்றுகள் (development credentials) rakazo:rakazo என உள்ளன, அவை களஞ்சியத்தில் உள்ளன. இணையத்திலிருந்து அணுகக்கூடிய Postgres port மற்றும் பொதுவான கடவுச்சொல் இருந்தால், சில மணிநேரங்களிலேயே ஸ்கேனர்கள் அதைக் கண்டறிந்துவிடும். Production compose கோப்பானது அதற்குப் பதிலாக POSTGRES_PASSWORD-ஐ வாசிக்கும், எனவே நீங்கள் அந்த நிலையை அடையும்போது அதை ஒரு சீரற்ற சரமாக (random string) அமைக்கவும்.

முதல் முறை இயக்குதல்

pnpm dev

இது நான்கு விஷயங்களைத் தொடங்குகிறது: port 3100-ல் API, Graphile Worker, 5173-ல் Vite web app, மற்றும் 7091-ல் sandbox supervisor. செயலி http://127.0.0.1:5173-ல் உள்ளது, அங்கு நீங்கள் sign-in பக்கத்தைக் காண்பீர்கள்.

நீங்கள் VPS-ல் இருக்கும்போது அந்த இயந்திரத்தின் முன்னால் அமர்ந்திருக்க மாட்டீர்கள், எனவே அதை அணுக 5173-ஐ public-ஆக வெளியிடக்கூடாது. அதற்குப் பதிலாக, உங்கள் சொந்த இயந்திரத்திலிருந்து SSH (secure shell) மூலம் ports-ஐ forward செய்யவும்.

ssh -L 5173:127.0.0.1:5173 -L 3100:127.0.0.1:3100 you@your-server

இதை இயக்குவதற்கான இரண்டு வழிகளுக்கும் இடையே உள்ள வித்தியாசத்தில் கவனமாக இருக்கவும். pnpm dev, Vite-ஐ host-ல் உள்ளூரில் (locally) இயக்கும். Compose கோப்பின் web service, 5173:5173-ஐ அனைத்து interface-களிலும் வெளியிடுகிறது (publish). முழுமையான development compose stack-ஐ ஒரு public VPS-ல் இயக்கினால் செயலி வெளிப்படையாகத் தெரியும், எனவே நீங்கள் தொடர்ந்து இயங்க வைக்கும் எதற்கும் production கோப்பையும் அதன் reverse proxy-யையும் பயன்படுத்தவும்.

server-ல் எந்த sandbox provider பாதுகாப்பானது?

இது சரியாக அமைக்கப்பட வேண்டிய மிக முக்கியமான அமைப்பாகும். .env-ல் உள்ள SANDBOX_PROVIDER நான்கு மதிப்புகளைக் கொள்கிறது.

• docker என்பது இயல்புநிலை (default) அமைப்பாகும். ஒவ்வொரு bot-உம் உங்கள் machine-ல் தனித்தனி container-ல் இயங்கும், இது pnpm sandbox:build உருவாக்கிய image-லிருந்து கட்டமைக்கப்படுகிறது. இதுவே மிக வேகமான self-hosted அமைப்பாகும்.
• e2b என்பது bot-களை E2B-ல் இயக்குகிறது, இதற்கு E2B_API_KEY தேவைப்படுகிறது. பொது அல்லது பல பயனர்கள் பயன்படுத்தும் deployments-க்கு இதைப் பயன்படுத்தவே திட்டம் பரிந்துரைக்கிறது, ஏனெனில் இது உங்கள் API மற்றும் database இயங்கும் host-லிருந்து bot-களைத் தனித்து வைக்கிறது.
• desktop என்பது bot-ன் கட்டளைகளை நேரடியாக API மற்றும் worker host-ல் இயக்குகிறது. இந்த repository-ன் அறிவுறுத்தல் மிகத் தெளிவானது: பொது அல்லது பகிரப்பட்ட server-ல் இதைப் பயன்படுத்த வேண்டாம்.
• fake என்பது சோதனைகளுக்கான in-process emulator ஆகும். இது ஒரு runtime அல்ல.

Desktop எச்சரிக்கையை அப்படியே எடுத்துக்கொள்ளுங்கள். Desktop mode-ல் எந்தவிதமான isolation எல்லையும் இல்லை, எனவே bot-ஆனது API process-ஐ இயக்கும் பயனரின் உரிமைகளுடன் shell கட்டளைகளை இயக்குகிறது. அந்தப் பயனரின் home directory, SSH keys, cloud credentials மற்றும் .env ஆகிய அனைத்தும் bot-க்குக் கிடைக்கும். bot படிக்கும் ஒரு web page-ல் உள்ள உரை உங்கள் server-ல் ஒரு கட்டளையாக மாறக்கூடும். Server-ல் Desktop mode-ஐப் பயன்படுத்துவது, உங்கள் credentials-ஐ bot-க்குக் கொடுப்பதற்குச் சமம். நீங்கள் நேரடியாகப் பயன்படுத்தும் machine-ல் மட்டும் இதைச் செய்யுங்கள், அல்லது இதைத் தவிர்க்கவும்.

docker என்பது ஒரு உண்மையான எல்லை, ஆனால் அது முழுமையானது அல்ல. ஒவ்வொரு bot-க்கும் தனித்தனி container இருப்பதால், ஒரு bot மற்றொரு bot-ன் கோப்புகளைப் படிக்க முடியாது. இருப்பினும், அந்த container-களை உருவாக்கும் supervisor, /var/run/docker.sock-ஐ mount செய்கிறது. host Docker socket-ஐக் கட்டுப்படுத்துவது என்பது host-ஐயே கட்டுப்படுத்துவதாகும். எனவே supervisor-ஐப் பாதுகாப்பாக வைத்திருங்கள். .env.example, SANDBOX_SUPERVISOR_TOKEN-ஐ ஒரு விருப்பத்தேர்வுள்ள தனி service credential-ஆக ஆவணப்படுத்துகிறது. இது காலியாக இருக்கும்போது BETTER_AUTH_SECRET என இயல்புநிலையாக அமையும். அதாவது, அந்த secret-ஐ அதன் placeholder-லேயே விட்டுவிடுவது, container-ஐ உருவாக்கும் service-ஐ GitHub-ல் எவரும் படிக்கக்கூடிய ஒரு string மூலம் பாதுகாப்பற்றதாக்குகிறது. இரண்டு மதிப்புகளையும் சரியாக அமைக்கவும். இங்குள்ள மிக வலுவான பிரிவினைக்கு, e2b-ஐப் பயன்படுத்தவும் அல்லது Rakazo-விற்கு வேறு எந்தத் தரவும் இல்லாத ஒரு தனி machine-ஐ வழங்கவும். coding agents-ஐ disposable VM-ல் இயக்குவது என்பதன் பின்னணியிலும் இதே காரணம் தான் உள்ளது: ஒரு agent தவறு செய்யும்போது அதிலிருந்து தப்பிக்க, அதன் machine-ன் மதிப்பு பூஜ்ஜியமாக இருப்பதே மலிவான வழியாகும்.

Model API keys எங்கே வைக்கப்பட வேண்டும்?

Rakazo-வில் நிர்வகிக்கப்படும் model billing கிடையாது. நீங்கள் உங்கள் சொந்த key-ஐப் பயன்படுத்த வேண்டும். .env.example ஆனது PI_DEFAULT_PROVIDER=openrouter-ஐ அமைக்கிறது, எனவே OPENROUTER_API_KEY என்பது இதற்கான வழக்கமான இடமாகும்; provider keys-ம் அதே அமைப்பின் மூலமே செயல்படுகின்றன.

Key-ஐ .env-ல் வைத்திருக்கவும், அதை git-ல் commit செய்யும் எந்தக் கோப்பிலும் சேர்க்க வேண்டாம். Repository-ல் உள்ள இரண்டு compose கட்டளைகளும் --env-file .env-ஐ கடத்துகின்றன, எனவே git கண்காணிக்கும் YAML கோப்புகளில் எழுதப்படாமலேயே மதிப்புகள் containers-ஐச் சென்றடைகின்றன. நீங்கள் OPENROUTER_API_KEY-ஐ காலியாக விட்டுவிட்டு, onboarding-ன் போது app-ல் key-ஐ உள்ளிடலாம். இதனால்தான் ENCRYPTION_KEY-க்கு வழங்கப்பட்ட placeholder-க்கு பதிலாக ஒரு உண்மையான random மதிப்பு தேவைப்படுகிறது.

ஒரு bot இதைப் பயன்படுத்துவதற்கு முன்பே, provider தளத்தில் அந்த key-க்கு ஒரு spending limit-ஐ அமைக்கவும். ஒரு bot loop-ல் சிக்கினால் அது செலவை ஏற்படுத்தும்; நீங்கள் கண்காணிப்பதைச் சார்ந்திருக்காத ஒரே பாதுகாப்பு அம்சம் இந்த per-key limit மட்டுமே. இந்த key-க்கு ஒரு தனிப் பெயரை வழங்கவும், அப்போதுதான் தேவைப்பட்டால் அதை மட்டும் உங்களால் revoke செய்ய முடியும்.

Development mode-லிருந்து நிரந்தரமாக இயக்கும் நிலைக்கு மாறுதல்

இந்த repository-ல் production compose file ஒன்று உள்ளது. இது Postgres, API, worker, web app மற்றும் தானாகவே TLS (transport layer security) certificates-ஐப் பெறும் Caddy ஆகியவற்றை இயக்குகிறது. bot computers-க்கு இது E2B-ஐ எதிர்பார்க்கிறது.

sudo DEPLOY_USER=deploy bash infra/compose/harden-host.sh
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build

harden-host.sh ஆனது SSH password login-ஐ முடக்குகிறது, SSH, HTTP மற்றும் HTTPS-க்கான UFW (uncomplicated firewall) விதிகளை அமைக்கிறது, fail2ban-ஐ இயக்குகிறது மற்றும் AppArmor profiles-ஐ அமல்படுத்துகிறது. இதை இயக்குவதற்கு முன் படித்துப் பார்க்கவும், ஏனெனில் இது நீங்கள் login செய்யும் முறையை மாற்றும். இது இயங்கும்போது மற்றொரு SSH session-ஐத் திறந்து வைத்திருக்கவும்.

Production .env-க்கு development-ஐ விட கூடுதல் வசதிகள் தேவை. self-host ஆவணத்தில் இதற்கான குறைந்தபட்சத் தேவைகள் பட்டியலிடப்பட்டுள்ளன.

NODE_ENV=production
RAKAZO_HOST=app.example.com
BETTER_AUTH_URL=https://app.example.com
WEB_ORIGIN=https://app.example.com
API_URL=https://app.example.com
POSTGRES_PASSWORD=<random>
BETTER_AUTH_SECRET=<random>
ENCRYPTION_KEY=<random>
E2B_API_KEY=<your key>
OPENROUTER_API_KEY=<your key>
SANDBOX_PROVIDER=e2b
AGENT_RUNTIME=pi
DATA_DIR=/data

முதல் up-க்கு முன்பாக, server-ஐ நோக்கி ஒரு A record-ஐ point செய்யவும். RAKAZO_HOST-ல் உள்ள பெயருக்காக Caddy ஒரு certificate-ஐக் கோரும். அந்தப் பெயர் இந்த server-ஐச் சென்றடையவில்லை என்றாலோ அல்லது port 80 வெளிப்புறத் தொடர்புக்கு மூடப்பட்டிருந்தாலோ, அந்தக் கோரிக்கை தோல்வியடையும்.

மேலும் SIGNUP_ALLOWLIST=you@example.com-ஐ அமைக்கவும். SIGNUPS_ENABLED=true என்பது default மதிப்பு என்பதால், public name-ல் உள்ள ஒரு instance, அதைக் கண்டறியும் எவரிடமிருந்தும் பதிவுகளை ஏற்கும், மேலும் ஒவ்வொரு புதிய கணக்கிற்கும் ஒரு computer ஒதுக்கப்படும். முதலில் allowlist-ஐப் பயன்படுத்தவும். தேவைப்பட்டால் பிறகு அதைத் தளர்த்திக்கொள்ளலாம்.

Repository-ல் உள்ள docs/self-host.md-ஐ production அமைப்புகளுக்கான ஆதாரமாகக் கருதவும், ஏனெனில் code மாறும்போது அதுவும் மாறும், ஆனால் இந்த வழிகாட்டி மாறாது. Compose இந்த வேலையைச் செய்வதால், வழக்கமான விதிகள் பொருந்தும். மேலும், ஒரு stack-ஐ மாதக்கணக்கில் அப்படியே இயங்கவிடும்போது ஏன் --env-file மற்றும் named volumes முக்கியம் என்பதை the Docker Compose basics for a VPS விளக்குகிறது.

Backups

Postgres மற்றும் data/ கோப்பகம் மட்டுமே முழு instance-ஐயும் உள்ளடக்கியவை.

./scripts/backup.sh
./scripts/restore.sh backups/BACKUP_TIMESTAMP

backup.sh என்பது Postgres-ஐ dump செய்து data/-ஐ archive செய்கிறது. நீங்கள் சார்ந்திருக்கும் ஒரு machine-க்கு, repository வழங்கும் timer-ஐப் பயன்படுத்தி infra/compose/backup-prod.sh-ஐ /usr/local/sbin/rakazo-backup ஆக நிறுவவும்; அப்போதுதான் உங்கள் தலையீடு இன்றி rotation தானாக நடக்கும். தரவுத்தளம் இருக்கும் அதே disk-ல் இருக்கும் backup, உண்மையான backup ஆகாது; எனவே அதை அந்த machine-லிருந்து வெளியே நகலெடுக்கவும். பின்னர், உங்களுக்குத் தேவைப்படுவதற்கு முன்பே, ஒரு spare server-ல் அதை ஒருமுறை restore செய்து சரிபார்க்கவும்.

ஏன் இது தோல்வியடைகிறது மற்றும் நீங்கள் எதைக் காண்பீர்கள்

pnpm db:migrate தரவுத்தளத்தை அடைய முடியவில்லை. 127.0.0.1:5433-ல் உள்ள தரவுத்தள சேவையகத்தை அணுக முடியவில்லை என்று இடம்பெயர்வு (migration) தெரிவிக்கிறது. Postgres container இயங்காமல் இருக்கலாம் அல்லது அது இயங்கினாலும் இன்னும் தயாராகாமல் இருக்கலாம். docker compose --env-file .env -f infra/compose/docker-compose.yml ps-ஐ இயக்கி, postgres சேவை 'healthy' என்று காட்டுகிறதா என்று பாருங்கள், ஏனெனில் compose கோப்பில் மூன்று வினாடிகளுக்கு ஒருமுறை இயங்கும் health check கொடுக்கப்பட்டுள்ளது. ஒரு container தொடர்ந்து மறுதொடக்கம் (loop) ஆகிறது என்றால், pgdata volume வெவ்வேறு நற்சான்றிதழ்களுடன் (credentials) உருவாக்கப்பட்டிருக்கலாம் என்று பொருள். docker compose ... down -v அதை நீக்குகிறது, அதனுடன் தரவுகளும் நீக்கப்படும்.

போர்ட் ஏற்கனவே பயன்பாட்டில் உள்ளது. 5433-ஐ வேறொரு சேவை பயன்படுத்தும்போது Postgres-ஐத் தொடங்க முயற்சித்தால் bind: address already in use பிழை ஏற்படும். பெரும்பாலும் நீங்கள் நிறுத்த மறந்துவிட்ட பழைய Rakazo stack-ஆக இது இருக்கலாம். sudo ss -lntp | grep 5433 அந்தச் செயல்முறையின் (process) பெயரைத் தெரிவிக்கும்.

போட்டிற்கு கணினி கிடைக்கவில்லை. SANDBOX_PROVIDER=docker மற்றும் rakazo/computer:local படம் (image) இல்லையென்றால், தொடங்குவதற்கு எதுவும் இருக்காது. docker image ls rakazo/computer அதை ஒரே வரியில் விளக்கும், pnpm sandbox:build அதைச் சரிசெய்யும். மேற்பார்வையாளரால் (supervisor) Docker socket-ஐ அணுக முடியாவிட்டால், அதால் container-களை உருவாக்க முடியாது, மேலும் அந்தச் செய்தி பாதையைக் குறிப்பிடும்: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock.

நீண்ட கட்டளை பாதியிலேயே நின்றுவிடுகிறது. .env.example ஆனது SANDBOX_COMMAND_TIMEOUT_MS=300000-ஐ அமைக்கிறது, எனவே ஒரு பாட்டின் கணினிக்குள் இருக்கும் ஒரு கட்டளை ஐந்து நிமிடங்களுக்குப் பிறகு துண்டிக்கப்படும். sandbox செயலிழந்துவிட்டது என்று கருதுவதற்குப் பதிலாக, மெதுவான உருவாக்கங்களுக்கு (slow builds) இதை அதிகரிக்கவும்.

pnpm install குழப்பமான வழிகளில் செயலிழக்கிறது. மற்ற எதையும் சரிபார்க்கும் முன் node -v-ஐச் சரிபார்க்கவும். பணிப்புலம் (workspace) >=22-ஐ அறிவிக்கிறது, பழைய Node பதிப்பு பதிப்பு குறித்த செய்தியைத் தருவதற்குப் பதிலாக சார்பு குறியீட்டில் (dependency code) தோல்வியடையும்.

உள்ளூர் கணினியில் உள்நுழைவு வேலை செய்கிறது, ஆனால் டொமைன் வழியாக வேலை செய்யவில்லை. BETTER_AUTH_URL, WEB_ORIGIN மற்றும் API_URL ஆகிய அனைத்தும் முகவரிப் பட்டியில் (address bar) உள்ள அதே பொதுவான மூலத்தைக் (public origin) கொண்டிருக்க வேண்டும், இதில் scheme-ம் அடங்கும். அவற்றில் ஏதேனும் ஒன்றில் எஞ்சியிருக்கும் பழைய http://127.0.0.1:5173 தான் அமர்வு (session) நிலைக்காமல் இருப்பதற்கு வழக்கமான காரணமாகும்.

Pinned checkout-ஐ மேம்படுத்துதல்

Self-host ஆவணத்தில் உள்ள மேம்படுத்தல் வழிமுறை சுருக்கமானது: புதிய source-ஐ pull செய்யவும், database migration-ஐ இயக்கவும், API மற்றும் worker-ஐ restart செய்யவும்.

./scripts/backup.sh
git fetch --all
git checkout NEW_COMMIT_SHA
pnpm install
pnpm --filter @rakazo/db migrate
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build

முதலில் backup எடுக்கவும். Migrations முன்னோக்கி மட்டுமே செல்லும், beta பதிப்பில் நீங்கள் நம்பகமான reverse path எதையும் பெற முடியாது. புதிய மாற்றங்களைச் செய்வதற்கு முன், உங்கள் தற்போதைய pinned SHA மற்றும் புதிய SHA-க்கு இடைப்பட்ட commits-ஐ வாசிக்கவும். ஏனெனில், இவ்வளவு புதிய திட்டங்களில் environment variables பெயர்கள் முன்னறிவிப்பின்றி மாற்றப்படலாம்; விடுபட்ட variable இருந்தால், service தொடங்கிவிட்டு உடனடியாக நின்றுவிடும். Rakazo-வை இயக்குவது சரியான முடிவா என்று நீங்கள் இன்னும் தீர்மானிக்கவில்லை என்றால், self-hosted AI agents பற்றிய தொகுப்பு இந்த வகையில் வேறு என்னென்ன உள்ளன என்பதையும், ஒவ்வொன்றையும் பராமரிக்க எவ்வளவு செலவாகும் என்பதையும் விளக்குகிறது.

FAQ

1 GB VPS-ல் என்னால் Rakazo-வை இயக்க முடியுமா?

முடியாது. Postgres, API, worker, sandbox supervisor மற்றும் web app ஆகிய அனைத்தும் ஒரே நேரத்தில் இயங்குகின்றன. மேலும், SANDBOX_PROVIDER=docker மூலம் ஒவ்வொரு active bot-ம் ஒரு graphical desktop மற்றும் browser-ஐக் கொண்ட container-ஐ உருவாக்குகிறது. E2B மூலம் bot desktop-கள் நிர்வகிக்கப்படும்போது மட்டுமே, API, worker மற்றும் Postgres-க்கு 2 vCPU மற்றும் 4 GB RAM போதுமானது என்று திட்டத்தின் ஆவணங்கள் குறிப்பிடுகின்றன. Control plane-க்கு குறைந்தபட்சம் 4 GB RAM தேவை; desktop-கள் உங்கள் server-லேயே இயங்கினால், இன்னும் அதிக RAM தேவைப்படும்.

Server-ல் desktop sandbox provider பாதுகாப்பானதா?

இல்லை. desktop, bot-ன் கட்டளைகளை நேரடியாக API மற்றும் worker host-ல் இயக்குகிறது. அந்த process-ஐ இயக்கும் user-ன் கோப்புகள் மற்றும் credentials-ஐ அணுகும் வாய்ப்பு இதற்கு உண்டு. பொதுவான அல்லது பகிரப்பட்ட server-களில் இதைப் பயன்படுத்த வேண்டாம் என்று repository அறிவுறுத்துகிறது. ஒவ்வொரு bot-க்கும் தனித்தனி container-ஐப் பயன்படுத்த docker-ஐயும், ஒன்றுக்கும் மேற்பட்ட பயனர்கள் உள்நுழையும்போது e2b-ஐயும் பயன்படுத்தவும்.

Rakazo-வின் எந்தப் பதிப்பை நான் நிறுவ வேண்டும்?

16 ஆகஸ்ட் 2026 நிலவரப்படி, 13 ஆகஸ்ட் 2026 அன்று வெளியிடப்பட்ட v0.1.0-beta என்ற ஒரே ஒரு tag மட்டுமே உள்ளது; இது ஒரு prerelease ஆகும். main-ஐப் பின்தொடர்வதை விட, அது சுட்டிக்காட்டும் 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb என்ற commit-ஐப் பயன்படுத்தவும். Branch-கள் மாறக்கூடியவை மற்றும் tag-கள் மாற்றப்படலாம் என்பதால், அவை நிலையான பதிப்பைக் குறிக்காது. எந்த commit சரியாக வேலை செய்தது என்பதைப் பதிவு செய்து வைத்துக்கொள்ளுங்கள்; அப்போதுதான் தேவைப்படும்போது முந்தைய நிலைக்குத் திரும்ப முடியும்.

எனது OpenRouter API key-ஐ எங்கே பதிவிட வேண்டும்?

அதை .env கோப்பில் OPENROUTER_API_KEY ஆகச் சேர்க்கவும். Version control-க்கு அனுப்பும் compose கோப்பில் இதை ஒருபோதும் சேர்க்க வேண்டாம். Repository-ல் உள்ள இரண்டு compose கட்டளைகளும் --env-file .env-ஐப் பயன்படுத்துகின்றன, எனவே YAML கோப்பில் எழுதாமலேயே அந்த மதிப்பு container-களுக்குச் சென்றுவிடும். நீங்கள் அதை காலியாக விட்டுவிட்டு, app-ஐத் தொடங்கும் போது (onboarding) உள்ளேயும் பதிவிடலாம். Provider தளத்தில் அந்த key-க்கு ஒரு செலவு வரம்பை (spending limit) நிர்ணயிக்கவும், ஏனெனில் bot ஒரு loop-ல் சிக்கினால், ஏதேனும் தடுக்கும் வரை அது model-ஐத் தொடர்ந்து அழைத்துக்கொண்டே இருக்கும்.

எனக்கு domain name மற்றும் TLS தேவையா?

முதல் சோதனைக்கு மேல் எதையும் செய்ய வேண்டுமென்றால், ஆம். Production compose கோப்பு Caddy-ஐ இயக்கி தானாகவே certificates-ஐப் பெறுகிறது. மேலும், RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN மற்றும் API_URL ஆகிய அனைத்தும் ஒரே பொது HTTPS origin-ஐக் கொண்டிருக்க வேண்டும். முதல்முறை சோதிக்க domain தேவையில்லை: pnpm dev-ஐ இயக்கி, port 5173-ஐ public-ஆகத் திறப்பதற்குப் பதிலாக SSH மூலம் forward செய்யவும்.