SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

Rakazo स्वतःच्या VPS वर कसे होस्ट करावे?

Rakazo ला तुमच्या स्वतःच्या VPS वर Node 22, pnpm, Postgres आणि Docker Compose वापरून कसे सेट करावे हे जाणून घ्या. सँडबॉक्स निवड, की हँडलिंग आणि सर्व्हरच्या योग्य आकाराची माहिती.

Rakazo self-hosting मध्ये नक्की काय चालते

Rakazo self-hosting म्हणजे एका Linux सर्व्हरवर पाच गोष्टी चालवणे: PostgreSQL, एक Graphile Worker प्रक्रिया, API, वेब ॲप आणि प्रत्येक सक्रिय बॉटसाठी एक सँडबॉक्स कंटेनर. Rakazo हा Grok Bot ला एक ओपन-सोर्स पर्याय आहे, जो elie222 द्वारे Apache 2.0 परवान्याअंतर्गत प्रकाशित केला आहे. प्रत्येक बॉटला स्वतःचा थ्रेड, स्वतःचे संगणक संसाधन, स्वतःची मेमरी आणि स्वतःचा इतिहास मिळतो, आणि तो समकक्षांना (peers) किंवा अल्पकालीन सब-एजंट्सना तयार करू शकतो.

शेवटच्या मुद्द्यामुळेच हे डेस्कटॉपवर न चालवता VPS (virtual private server) वर चालवणे आवश्यक आहे. जो बॉट मेमरी राखून ठेवतो आणि नियोजित कामे करतो, तो तुम्ही झोपलेले असतानाही उपलब्ध असणे गरजेचे आहे. लॅपटॉप स्लीप मोडमध्ये गेल्यावर रांग (queue) खंडित होते.

ऑगस्ट 2026 पर्यंत Rakazo हे अर्ली बीटा टप्प्यात आहे, त्यामुळे याकडे एक पूर्ण झालेले उत्पादन म्हणून न पाहता एक कार्यरत सेटअप म्हणून पहा. संपूर्ण स्टॅक TypeScript मध्ये आहे: वेब ॲपसाठी React 19 आणि Vite, API साठी Hono, Prisma सह Postgres, अकाउंट्ससाठी Better Auth आणि बॅकग्राउंड जॉब्ससाठी Graphile Worker. Graphile Worker आपली रांग Postgres मध्ये साठवते, त्यामुळे Redis किंवा इतर कोणत्याही दुसऱ्या डेटा स्टोअरची गरज नाही. .env.example हे WAKEUP_DRIVER=graphile सेट करते, ज्याचा अर्थ असा की बॉट सुरू होणे ही एक Postgres-आधारित प्रक्रिया आहे. Postgres थांबवले की सर्व नियोजित बॉट क्रिया देखील थांबतात. जर तुम्हाला दुसऱ्याचे उत्पादन चालवण्याऐवजी स्वतःचे एजंट सुटे भाग जोडून तयार करायचे असतील, तर घटक वापरून स्वतःचा एजंट तयार करणे हा दुसरा मार्ग आहे.

1 GB चा प्लॅन यासाठी अपुरा का आहे

प्रक्रियेची संख्या मोजा. Postgres ही एक प्रक्रिया आहे. API ही एक Node प्रक्रिया आहे. वर्कर ही दुसरी प्रक्रिया आहे. वेब ॲप ही तिसरी प्रक्रिया आहे. सँडबॉक्स सुपरवायझर ही चौथी प्रक्रिया आहे. त्यानंतर प्रत्येक चालू असलेल्या बॉटसाठी एक कंटेनर असतो, ज्यामध्ये ग्राफिकल Linux डेस्कटॉप आणि ब्राउझर असतो.

प्रकल्पाच्या स्वतःच्या self-host दस्तऐवजात एक स्पष्ट आकडा दिला आहे: जेव्हा E2B बॉट डेस्कटॉप्स सांभाळते, तेव्हा API, वर्कर आणि Postgres साठी 2 vCPU आणि 4 GB मशीन पुरेशी असते. हा आकडा केवळ कंट्रोल प्लेनसाठी आहे, ज्यामध्ये जड भाग इतरत्र होस्ट केलेला असतो. जर तुम्ही SANDBOX_PROVIDER=docker सेट केले, तर ते डेस्कटॉप तुमच्या VPS वर हलवले जातात, त्यामुळे 4 GB ही मर्यादा नसून किमान आवश्यकता बनते. जर तुम्हाला एकापेक्षा जास्त बॉट सक्रिय ठेवायचे असतील, तर 8 GB पासून सुरुवात करा आणि बॉट काम करत असताना docker stats वापरून प्रत्यक्ष मेमरी वापराचे मोजमाप करा. सँडबॉक्समधील ब्राउझरमुळे मेमरीचा वापर वाढतो, त्यामुळे केवळ स्पेसिफिकेशन शीट पाहून याचा अंदाज येणार नाही. एजंट वर्कसाठी सर्व्हरच्या क्षमतेचे नियोजन करण्याच्या सामान्य पद्धतीसाठी, एजंट VPS ला प्रत्यक्ष किती RAM आणि CPU ची गरज असते यामध्ये मोजमापाची सविस्तर माहिती दिली आहे.

एक सेटिंग ही परिस्थिती बिघडण्यापासून वाचवते. .env.example मध्ये SANDBOX_IDLE_MS=600000 सोबत अशी टिप्पणी असते की, ठराविक मिलीसेकंद निष्क्रिय राहिल्यानंतर ते E2B कॉम्प्युटर्सना पॉज करते किंवा Docker कॉम्प्युटर्सना थांबवते. दहा मिनिटे निष्क्रिय राहिल्यास कॉम्प्युटर बंद होतो. यासाठी स्वीकार्य किमान मूल्य 30000 आहे. याशिवाय, तुम्ही उघडलेला प्रत्येक बॉट कायमस्वरूपी मेमरी व्यापून ठेवेल.

डिस्कची क्षमताही महत्त्वाची आहे. सँडबॉक्स इमेज, Node मॉड्यूल्स आणि Postgres व्हॉल्यूम एकाच डिस्कवर असतात, त्यामुळे 40 GB ही एक योग्य सुरुवात आहे.

क्लोन करण्यापूर्वी आवृत्ती पिन करा

Rakazo वेगाने विकसित होत आहे आणि main ही कोणतीही अधिकृत release नाही. 16 ऑगस्ट 2026 पर्यंत, रिपॉझिटरीमध्ये केवळ एकच टॅग आहे, v0.1.0-beta, जो 13 ऑगस्ट 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 निर्देश करतो. ब्रांच किंवा टॅगऐवजी कमिट पिन करा. पुढील git pull वर ब्रांच बदलू शकते आणि टॅग ही एक हलवता येण्याजोगी लेबल आहे जी मेंटेनर कधीही बदलू शकतो, त्यामुळे यापैकी कशावरूनही तुम्ही पूर्वीच्या स्थितीत परत जाऊ शकत नाही. कमिट आयडेंटिफायर कधीही बदलत नाही. तुमचा कमिट आयडेंटिफायर तुमच्या इतर सर्व्हर माहितीसोबत लिहून ठेवा, कारण जेव्हा अपग्रेडमुळे सिस्टिममध्ये बिघाड होतो, तेव्हा स्वस्त उपाय म्हणजे git checkout <old 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 आर्काइव्हमधील Node पॅकेज सहसा जुने असते, म्हणून NodeSource किंवा nvm वापरून ते इन्स्टॉल करा. pnpm हे corepack द्वारे Node सोबत येते:

corepack enable
corepack prepare pnpm@9.15.0 --activate

Docker Engine आणि compose प्लगइन उर्वरित गरजा पूर्ण करतात, आणि तुमच्या युजरला daemon पर्यंत पोहोचता येणे आवश्यक आहे. जर docker ps ने permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock असे उत्तर दिले, तर तुमच्या युजरला docker ग्रुपमध्ये जोडा आणि नवीन लॉगिन शेल सुरू करा. याचे परिणाम आधी समजून घ्या: docker मधील सदस्यत्व हे मशीनवर root असण्यासारखेच आहे, कारण त्या ग्रुपमधील कोणीही असा कंटेनर सुरू करू शकतो जो होस्ट फाइलसिस्टमला माउंट करतो.

.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 समाविष्ट आहेत. डेव्हलपमेंट सोडून इतर ठिकाणी Rakazo या प्लेसहोल्डर व्हॅल्यूज स्वीकारत नाही, त्यामुळे रिपॉझिटरीमध्ये प्रकाशित असलेल्या सिक्रेटवर चालण्याऐवजी अर्धवट कॉन्फिगर केलेले डिप्लॉयमेंट स्पष्टपणे अयशस्वी होते.

openssl rand -base64 48
openssl rand -hex 32

त्यानंतर डेटाबेस स्वतंत्रपणे सुरू करा आणि मायग्रेशन्स रन करा.

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 हे बॉट कॉम्प्युटर इमेज बिल्ड करते, जी package.json मध्ये docker build -t rakazo/computer:local infra/sandboxes/computer म्हणून परिभाषित केली आहे. ही एक ग्राफिकल इमेज असल्याने, पहिल्या बिल्डमध्ये खूप डेटा डाउनलोड होतो आणि वेळ लागतो. ती इमेज तयार झाली आहे का हे docker image ls rakazo/computer वापरून तपासा, ज्याद्वारे एक ओळ आउटपुटमध्ये दिसली पाहिजे.

कॉम्पोज फाईल Postgres ला 127.0.0.1:5433:5432 म्हणून पब्लिश करते, जे फक्त लूपबॅकसाठी आहे. ते तसेच राहू द्या. डेव्हलपमेंट क्रेडेंशियल्स rakazo:rakazo आहेत, जी रिपॉझिटरीमध्ये आहेत. इंटरनेटवरून ॲक्सेस करता येणारा आणि पब्लिश केलेला पासवर्ड असलेला Postgres पोर्ट काही तासांतच स्कॅनर्सना सापडतो. प्रोडक्शन कॉम्पोज फाईल त्याऐवजी POSTGRES_PASSWORD वाचते, त्यामुळे तुम्ही तिथे पोहोचल्यावर ती व्हॅल्यू एका रँडम स्ट्रिंगवर सेट करा.

पहिली रन

pnpm dev

हे चार घटक सुरू करते: पोर्ट 3100 वर API, Graphile Worker, 5173 वर Vite वेब ॲप आणि 7091 वर सँडबॉक्स सुपरवायझर. ॲप http://127.0.0.1:5173 वर उपलब्ध आहे आणि तुम्हाला तिथे साइन-इन पेज दिसेल.

VPS वर काम करताना तुम्ही त्या मशीनसमोर प्रत्यक्ष नसता, त्यामुळे 5173 पोर्ट सार्वजनिकरीत्या उघडू नका. त्याऐवजी तुमच्या स्वतःच्या मशीनवरून SSH (secure shell) द्वारे पोर्ट फॉरवर्ड करा.

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

हे चालवण्याच्या दोन पद्धतींमधील फरक लक्षात घ्या. pnpm dev हे Vite ला होस्टवर स्थानिक पातळीवर बाइंड करून चालवते. compose फाईलमधील web सर्व्हिस 5173:5173 ला सर्व इंटरफेसवर पब्लिश करते. जर तुम्ही पूर्ण डेव्हलपमेंट compose स्टॅक सार्वजनिक VPS वर सुरू केला, तर ॲप उघड होईल. त्यामुळे, जे काही तुम्ही चालू ठेवणार असाल, त्यासाठी प्रोडक्शन फाईल आणि तिच्या reverse proxy चा वापर करा.

सर्व्हरवर कोणता सँडबॉक्स प्रोव्हायडर सुरक्षित आहे?

ही एक सेटिंग आहे जी योग्य असणे आवश्यक आहे. SANDBOX_PROVIDER मधील .env चार मूल्ये घेते.

  • docker हे डीफॉल्ट आहे. प्रत्येक बॉटला तुमच्या मशीनवर स्वतःचे कंटेनर मिळते, जे pnpm sandbox:build ने तयार केलेल्या इमेजपासून बनवलेले असते. हे सर्वात जलद self-hosted सेटअप आहे.
  • e2b हे E2B वर बॉट कॉम्प्युटर्स चालवते आणि त्यासाठी E2B_API_KEY ची आवश्यकता असते. सार्वजनिक किंवा मल्टी-युजर डिप्लॉयमेंटसाठी प्रोजेक्ट याची शिफारस करतो, कारण ते बॉट कॉम्प्युटर्सना तुमच्या API आणि डेटाबेस चालवणाऱ्या होस्टपासून वेगळे ठेवते.
  • desktop हे बॉटचे कमांड्स थेट API आणि वर्कर होस्टवर चालवते. रिपॉझिटरीच्या सूचना स्पष्ट आहेत: सार्वजनिक किंवा शेअर केलेल्या सर्व्हरवर याचा वापर करू नका.
  • fake हे चाचण्यांसाठी एक इन-प्रोसेस एम्युलेटर आहे. हे रनटाइम नाही.

डेस्कटॉपवरील त्या इशाऱ्याकडे गांभीर्याने पहा. डेस्कटॉप मोडमध्ये कोणतीही आयसोलेशन बाउंड्री नसते, त्यामुळे बॉट API प्रोसेस चालवणाऱ्या युजरच्या अधिकारात शेल कमांड्स चालवतो. यामध्ये त्या युजरची होम डिरेक्टरी, SSH कीज, क्लाउड क्रेडेंशियल्स आणि त्या युजरचे .env यांचा समावेश असतो. बॉटने वाचलेल्या वेब पेजमधील मजकूर तुमच्या सर्व्हरवर कमांड बनू शकतो. सर्व्हरवर डेस्कटॉप मोड वापरल्यामुळे बॉट तुमच्या क्रेडेंशियल्सचा ताबा घेऊ शकतो. हे फक्त अशा मशीनवर वापरा जिथे तुम्ही स्वतः काम करता, अन्यथा वापरू नका.

docker ही एक वास्तविक बाउंड्री आहे, परंतु ती परिपूर्ण नाही. एक बॉट दुसऱ्या बॉटच्या फाइल्स वाचू शकत नाही, कारण प्रत्येकाचे स्वतःचे कंटेनर असते. तथापि, जे सुपरवायझर हे कंटेनर तयार करतात, ते /var/run/docker.sock माउंट करतात आणि होस्ट Docker सॉकेटवर नियंत्रण असणे म्हणजे संपूर्ण होस्टवर नियंत्रण असणे होय. त्यामुळे सुपरवायझरला खाजगी ठेवा. .env.example मध्ये SANDBOX_SUPERVISOR_TOKEN हे एक ऐच्छिक स्वतंत्र सर्व्हिस क्रेडेंशियल म्हणून नमूद केले आहे, जे रिकामे असल्यास डीफॉल्टनुसार BETTER_AUTH_SECRET असते. याचा अर्थ असा की, ते सिक्रेट त्याच्या प्लेसहोल्डरवर ठेवल्यास कंटेनर तयार करणारी सर्व्हिस अशा स्ट्रिंगद्वारे सुरक्षित राहते जी GitHub वर कोणीही वाचू शकते. दोन्ही मूल्ये सेट करा. येथे उपलब्ध असलेल्या सर्वात मजबूत विलगीकरणासाठी, e2b वापरा किंवा Rakazo ला असे मशीन द्या ज्यामध्ये इतर काहीही महत्त्वाचे नसेल. डिस्पोजेबल VM मध्ये कोडिंग एजंट्स चालवण्यामागे हेच तर्क आहे: एजंटने काही चुकीचे केल्यास होणारे नुकसान टाळण्याचा सर्वात स्वस्त मार्ग म्हणजे त्या मशीनची किंमत शून्य असणे.

मॉडेल API keys कुठे ठेवाव्यात?

Rakazo कडे मॉडेल बिलिंगची कोणतीही व्यवस्था नाही. तुम्हाला तुमची स्वतःची key वापरावी लागेल. .env.example हे PI_DEFAULT_PROVIDER=openrouter सेट करते, म्हणून OPENROUTER_API_KEY हे यासाठी नेहमीचे ठिकाण आहे आणि प्रोव्हायडरच्या keys याच सेटिंगद्वारे काम करतात.

Key नेहमी .env मध्ये ठेवा आणि ती अशा कोणत्याही फाईलमध्ये ठेवू नका जी तुम्ही commit करता. रिपॉझिटरीमधील दोन्ही compose कमांड्स --env-file .env पास करतात, त्यामुळे git द्वारे ट्रॅक केल्या जाणाऱ्या YAML फाईलमध्ये न लिहिताही या व्हॅल्यूज कंटेनरपर्यंत पोहोचतात. तुम्ही OPENROUTER_API_KEY रिकामे ठेवून ऑनबोर्डिंग दरम्यान ॲपमध्ये key पेस्ट करू शकता. हे आणखी एक कारण आहे की ENCRYPTION_KEY साठी डिफॉल्ट प्लेसहोल्डरऐवजी एक खरोखर यादृच्छिक (random) व्हॅल्यू असणे आवश्यक आहे.

बॉट वापरण्यापूर्वी प्रोव्हायडरच्या साईटवर जाऊन त्या key साठी खर्चाची मर्यादा (spending limit) सेट करा. जर बॉट लूपमध्ये अडकला तर तो खर्च करत राहील, आणि प्रति-key मर्यादा हाच एकमेव असा उपाय आहे जो तुमच्या सतत देखरेखीवर अवलंबून नाही. या key ला एक वेगळे नाव द्या जेणेकरून गरज पडल्यास तुम्ही ती स्वतंत्रपणे रद्द (revoke) करू शकाल.

डेव्हलपमेंट मोडमधून प्रत्यक्ष वापरासाठी (production) स्थलांतर

या रिपॉझिटरीमध्ये एक production compose फाईल दिली आहे. ती Postgres, API, worker, web app आणि TLS (transport layer security) प्रमाणपत्रांसाठी Caddy चालवते, जी आपोआप मिळवली जातात. बॉट कॉम्प्युटर्ससाठी हे 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 पासवर्ड लॉगिन बंद करते, SSH, HTTP आणि HTTPS साठी UFW (uncomplicated firewall) नियम सेट करते, fail2ban सुरू करते आणि AppArmor प्रोफाइल्स लागू करते. हे चालवण्यापूर्वी नीट वाचा, कारण यामुळे तुमच्या लॉगिन करण्याच्या पद्धतीत बदल होतो. हे स्क्रिप्ट चालत असताना दुसरे एक SSH सत्र सुरू ठेवा.

Production .env ला डेव्हलपमेंटच्या तुलनेत अधिक गोष्टींची आवश्यकता असते. सेल्फ-होस्ट डॉक्युमेंटेशनमध्ये याच्या किमान गरजांची यादी दिली आहे.

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 पूर्वी सर्व्हरवर एक A record पॉइंट करा. Caddy RAKAZO_HOST मधील नावासाठी प्रमाणपत्राची विनंती करते. जर ते नाव या सर्व्हरवर रिझॉल्व्ह होत नसेल किंवा पोर्ट 80 बाहेरून बंद असेल, तर ही विनंती अयशस्वी होते.

तसेच SIGNUP_ALLOWLIST=you@example.com सेट करा. SIGNUPS_ENABLED=true हे डीफॉल्ट आहे, त्यामुळे सार्वजनिक नावावरील इन्स्टन्सवर कोणीही नोंदणी करू शकते आणि प्रत्येक नवीन खात्याला एक कॉम्प्युटर मिळतो. सुरुवातीला allowlist वापरा. नंतर गरज वाटल्यास ते शिथिल करा.

रिपॉझिटरीमधील docs/self-host.md लाच production सेटिंग्जसाठी अधिकृत माना, कारण ते कोडनुसार बदलत राहते आणि हे मार्गदर्शक बदलत नाही. Compose सर्व काम करत असल्याने, सामान्य नियम लागू होतात आणि the Docker Compose basics for a VPS मध्ये --env-file आणि named volumes चे महत्त्व स्पष्ट केले आहे, जे अशा स्टॅकसाठी महत्त्वाचे आहे जो तुम्ही अनेक महिने तसाच चालू ठेवणार आहात.

बॅकअप्स

Postgres आणि data/ डिरेक्टरी मिळून संपूर्ण इन्स्टन्स तयार होतो.

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

backup.sh हे Postgres चे डंप घेते आणि data/ आर्काइव्ह करते. ज्या मशीनवर तुम्ही अवलंबून आहात, त्यावर infra/compose/backup-prod.sh ला /usr/local/sbin/rakazo-backup म्हणून इन्स्टॉल करा. रिपॉझिटरीमध्ये दिलेल्या टायमरचा वापर करा, जेणेकरून रोटेशन आपोआप होईल. डेटाबेस असलेल्या डिस्कवरच ठेवलेला बॅकअप हा खरा बॅकअप नसतो, त्यामुळे तो मशीनच्या बाहेर कॉपी करा. गरज पडण्यापूर्वी एकदा तो दुसऱ्या सर्व्हरवर रिस्टोअर करून तपासा.

हे अपयशी का ठरते आणि तुम्हाला काय दिसेल

pnpm db:migrate डेटाबेसपर्यंत पोहोचू शकत नाही. मायग्रेशन रिपोर्ट करते की ते 127.0.0.1:5433 वरील डेटाबेस सर्व्हरशी संपर्क साधू शकत नाही. एकतर Postgres कंटेनर सुरू नाही, किंवा तो सुरू आहे पण अद्याप तयार झालेला नाही. docker compose --env-file .env -f infra/compose/docker-compose.yml ps चालवा आणि postgres सर्व्हिस 'healthy' असल्याचे तपासा, कारण compose फाईलमध्ये दर तीन सेकंदांनी चालणारी हेल्थ चेक सुविधा दिली आहे. जर कंटेनर सतत रीस्टार्ट होत असेल, तर याचा अर्थ सहसा असा होतो की pgdata व्हॉल्यूम चुकीच्या क्रेडेन्शियल्ससह तयार केला गेला आहे. docker compose ... down -v ते साफ करते आणि त्यासोबतचा डेटाही काढून टाकते.

पोर्ट आधीच वापरात आहे. जेव्हा एखादी दुसरी प्रक्रिया 5433 पोर्ट वापरत असते, तेव्हा Postgres सुरू करताना bind: address already in use एरर येते. सहसा तुम्ही थांबवायला विसरलेली जुनी Rakazo स्टॅक यासाठी कारणीभूत असते. sudo ss -lntp | grep 5433 कमांड वापरून ती प्रक्रिया कोणती आहे ते शोधा.

बॉटला संगणक मिळत नाही. SANDBOX_PROVIDER=docker आणि rakazo/computer:local इमेज नसल्यास, सुरू करण्यासाठी काहीही उरत नाही. docker image ls rakazo/computer या प्रश्नाचे उत्तर एका ओळीत देते आणि pnpm sandbox:build ते दुरुस्त करते. जर सुपरवायझर Docker सॉकेटपर्यंत पोहोचू शकत नसेल, तर तो कंटेनर तयार करू शकत नाही आणि मेसेजमध्ये हा पाथ दिसतो: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock.

दीर्घकाळ चालणारी कमांड मध्येच थांबते. .env.example मुळे SANDBOX_COMMAND_TIMEOUT_MS=300000 सेट होते, त्यामुळे बॉटच्या संगणकातील एखादी कमांड पाच मिनिटांनंतर आपोआप बंद होते. सँडबॉक्स क्रॅश झाला आहे असे समजण्याऐवजी, संथ बिल्ड्ससाठी ही मर्यादा वाढवा.

pnpm install गोंधळात टाकणाऱ्या पद्धतीने बंद पडते. इतर काहीही करण्यापूर्वी node -v तपासा. वर्कस्पेसमध्ये >=22 घोषित केलेले असते आणि जुने Node व्हर्जन असल्यास ते एरर मेसेज देण्याऐवजी थेट डिपेंडन्सी कोडमध्ये अपयशी ठरते.

साइन-इन स्थानिक पातळीवर काम करते पण डोमेनद्वारे नाही. BETTER_AUTH_URL, WEB_ORIGIN आणि API_URL या सर्वांमध्ये ॲड्रेस बारमधील पब्लिक ओरिजिन (स्कीमसह) समान असणे आवश्यक आहे. यापैकी एका ठिकाणी राहिलेली जुनी http://127.0.0.1:5173 व्हॅल्यू हे सत्र टिकून न राहण्याचे मुख्य कारण असते.

पिन केलेल्या चेकआउटचे अपडेट करणे

सेल्फ-होस्ट डॉक्युमेंटेशनमधील अपग्रेड प्रक्रिया थोडक्यात आहे: नवीन सोर्स कोड पुल करा, डेटाबेस मायग्रेशन रन करा आणि API व वर्कर पुन्हा सुरू करा.

./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

प्रथम बॅकअप घ्या. मायग्रेशन्स नेहमी पुढे जातात आणि बीटा आवृत्तीमध्ये तुम्ही खात्रीशीरपणे वापरू शकाल असा कोणताही रिव्हर्स पाथ (परत जाण्याचा मार्ग) नसतो. नवीन कमिट्स स्वीकारण्यापूर्वी तुमच्या सध्याच्या पिन केलेल्या SHA आणि नवीन SHA मधील कमिट्स वाचून घ्या. कारण इतक्या नवीन प्रोजेक्टमध्ये अनेकदा पूर्वसूचना न देता एन्व्हायर्नमेंट व्हेरिएबल्सची नावे बदलली जातात. एखादा व्हेरिएबल गहाळ असल्यास सर्व्हिस सुरू होते आणि लगेच बंद पडते. जर तुम्ही अजूनही Rakazo वापरणे योग्य आहे की नाही हे ठरवत असाल, तर self-hosted AI agents चा आढावा या श्रेणीतील इतर पर्याय आणि त्यांच्या देखभालीचा खर्च याबद्दल माहिती देते.

FAQ

मी 1 GB च्या VPS वर Rakazo चालवू शकतो का?

नाही. Postgres, API, worker, sandbox supervisor आणि web app हे सर्व एकाच वेळी चालतात. तसेच SANDBOX_PROVIDER=docker मुळे प्रत्येक सक्रिय bot एक कंटेनर तयार करतो ज्यामध्ये ग्राफिकल डेस्कटॉप आणि ब्राउझर असतो. प्रकल्पाच्या अधिकृत दस्तऐवजानुसार, जेव्हा E2B बॉट डेस्कटॉप होस्ट करते, तेव्हाच API, worker आणि Postgres साठी 2 vCPU आणि 4 GB RAM पुरेशी असते. कंट्रोल प्लेनसाठी 4 GB RAM ही किमान मर्यादा समजा आणि जेव्हा डेस्कटॉप तुमच्या मशीनवर चालतात तेव्हा अधिक RAM वापरा.

सर्व्हरवर डेस्कटॉप सँडबॉक्स प्रोव्हायडर सुरक्षित आहे का?

नाही. desktop हे बॉटचे कमांड्स थेट API आणि worker होस्टवर चालवते. हे त्या प्रक्रियेला (process) चालवणाऱ्या युजरच्या अधिकाराने चालते, त्यामुळे त्या युजरच्या फाइल्स आणि क्रेडेंशियल्स धोक्यात येऊ शकतात. रिपॉझिटरीमध्ये सार्वजनिक किंवा शेअर केलेल्या सर्व्हरवर याचा वापर न करण्याचा सल्ला दिला आहे. प्रत्येक बॉटसाठी स्वतंत्र कंटेनर वापरण्यासाठी docker वापरा, किंवा एकापेक्षा जास्त लोक साइन इन करत असतील तर e2b वापरा.

मी Rakazo ची कोणती आवृत्ती इन्स्टॉल करावी?

16 ऑगस्ट 2026 पर्यंत, 13 ऑगस्ट 2026 रोजी प्रकाशित झालेली आणि 'prerelease' म्हणून चिन्हांकित केलेली v0.1.0-beta ही एकच टॅग उपलब्ध आहे. main ट्रॅक करण्याऐवजी, ती ज्या कमिटला (commit) निर्देशित करते, त्या 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb ला चेकआउट करा. ब्रांच तुमच्या नकळत बदलू शकते आणि टॅग पुन्हा रिपॉइंट केला जाऊ शकतो, त्यामुळे यापैकी कशावरूनही तुम्ही नेमक्या कोणत्या स्थितीत परत जाऊ शकता हे निश्चित होत नाही. कमिट आयडी नोंदवून ठेवा, कारण कोणती आवृत्ती व्यवस्थित काम करत होती हे माहित असेल तरच रोलबॅक करणे शक्य असते.

माझी OpenRouter API key मी कुठे टाकू?

ती .env मध्ये OPENROUTER_API_KEY म्हणून टाका. ती कधीही अशा compose फाइलमध्ये टाकू नका जी तुम्ही रिपॉझिटरीमध्ये कमिट करता. रिपॉझिटरीमधील दोन्ही compose कमांड्स --env-file .env पास करतात, त्यामुळे ट्रॅक केलेल्या YAML फाइलमध्ये न लिहिताही ही व्हॅल्यू कंटेनरपर्यंत पोहोचते. तुम्ही हे रिकामेही ठेवू शकता आणि ऑनबोर्डिंग दरम्यान ॲपमध्ये की पेस्ट करू शकता. प्रोव्हायडरच्या वेबसाइटवर की साठी खर्चाची मर्यादा (spending limit) सेट करा, कारण लूपमध्ये अडकलेला बॉट मॉडेलला सतत कॉल करत राहतो जोपर्यंत त्याला कोणी थांबवत नाही.

मला डोमेन नेम आणि TLS ची गरज आहे का?

पहिल्या चाचणीनंतरच्या कोणत्याही वापरासाठी, हो. प्रोडक्शन compose फाइल Caddy चालवते आणि आपोआप प्रमाणपत्रे मिळवते. तसेच RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN आणि API_URL या सर्वांचा पब्लिक HTTPS ओरिजिन एकच असणे आवश्यक आहे. सुरुवातीला पाहण्यासाठी तुम्ही डोमेन वगळू शकता: pnpm dev चालवा आणि पोर्ट 5173 पब्लिश करण्याऐवजी SSH द्वारे फॉरवर्ड करा.