Rakazo को अपने VPS पर कैसे host करें: पूरी गाइड

Rakazo वास्तव में क्या self-host करता है

Rakazo अपनी बुनियादी सेवाओं और विकास कार्यों के लिए निम्नलिखित stack का उपयोग करता है:

• Reverse Proxy: Nginx, जो TLS termination और routing को संभालता है।
• Container Runtime: Docker और Docker Compose, जो सभी services को isolated environment में चलाने के लिए उपयोग किए जाते हैं।
• Version Control: Gitea, जो निजी repositories को host करने के लिए एक हल्का विकल्प है।
• Monitoring: Grafana और Prometheus, जो server metrics और uptime को track करते हैं।
• Database: PostgreSQL, जिसे विभिन्न applications के लिए backend के रूप में उपयोग किया जाता है।
• Automation: Watchtower, जो container images के अपडेट होने पर उन्हें स्वचालित रूप से restart करने के लिए उपयोग किया जाता है।

यह setup सुनिश्चित करता है कि सभी services सुरक्षित रहें और उन्हें आसानी से manage किया जा सके।

Rakazo को self-host करना
Rakazo को self-host करने का अर्थ है एक Linux सर्वर पर पाँच चीजों को चलाना: PostgreSQL, एक Graphile Worker process, API, वेब ऐप, और हर सक्रिय bot के लिए एक sandbox container। Rakazo, Grok Bot का एक open-source विकल्प है, जिसे elie222 द्वारा Apache 2.0 licence के तहत प्रकाशित किया गया है। प्रत्येक bot को अपना thread, अपना computer, अपनी memory और अपना history मिलता है, और यह peers या कम समय तक चलने वाले subagents को spawn कर सकता है। यदि उस वाक्य में memory, subagent और tool call जैसे शब्द अपरिचित लग रहे हैं, तो agents वास्तव में कैसे काम करते हैं, इसका एक चरणबद्ध विवरण पहले पढ़ना उचित रहेगा, क्योंकि नीचे दी गई अधिकांश सेटिंग्स तभी समझ में आती हैं जब आप यह कल्पना कर सकें कि जागने पर एक bot क्या कर रहा होता है।

VPS पर deployment की आवश्यकता

यही कारण है कि इस तरह के कार्यों के लिए desktop के बजाय VPS (virtual private server) का उपयोग करना चाहिए। जो bot memory में data रखता है और scheduled कार्य करता है, उसे आपके सोने के दौरान भी उपलब्ध रहना चाहिए। यदि laptop suspend mode में चला जाता है, तो वह queue को drop कर देता है।

VPS का चयन और प्रबंधन

VPS का उपयोग करने से यह सुनिश्चित होता है कि आपकी services 24/7 चलती रहें। Desktop के विपरीत, VPS को suspend या hibernate नहीं किया जाता है।

• Availability: VPS हमेशा online रहता है, जिससे scheduled tasks बिना किसी रुकावट के चलते हैं।
• Reliability: Network connection स्थिर रहता है, जो background processes के लिए आवश्यक है।
• Resource Management: आप अपनी आवश्यकताओं के अनुसार RAM और CPU को scale कर सकते हैं।

FAQ

क्या मैं अपने घर के PC पर bot चला सकता हूँ?

तकनीकी रूप से हाँ, लेकिन यदि आपका PC suspend होता है या internet connection टूटता है, तो bot का काम रुक जाएगा। production environment के लिए VPS अधिक उपयुक्त है।

क्या VPS को manage करना कठिन है?

नहीं, बुनियादी Linux administration का ज्ञान होने पर VPS को manage करना सरल है। ssh के माध्यम से आप इसे कहीं से भी access कर सकते हैं।

क्या मुझे VPS के लिए static IP की आवश्यकता है?

VPS के साथ आमतौर पर एक static public IP मिलता है, जो DNS records को configure करने और services को public internet पर expose करने के लिए अनिवार्य है।

Rakazo का परिचय

अगस्त 2026 तक Rakazo शुरुआती beta चरण में है। इसे एक तैयार appliance के बजाय एक working setup के रूप में देखें। यह पूरा stack TypeScript पर आधारित है: web app के लिए React 19 और Vite, API के लिए Hono, Prisma के साथ Postgres, accounts के लिए Better Auth, और background jobs के लिए Graphile Worker का उपयोग किया गया है। Graphile Worker अपनी queue को Postgres के भीतर store करता है, इसलिए इसे चलाने के लिए Redis या किसी अन्य data store की आवश्यकता नहीं है। .env.example, WAKEUP_DRIVER=graphile को set करता है, जिसका अर्थ है कि bot का सक्रिय होना एक Postgres-backed job है। यदि आप Postgres को stop करते हैं, तो हर scheduled bot action भी रुक जाएगा। यदि आप किसी और के product को चलाने के बजाय components से अपना agent तैयार करना चाहते हैं, तो components से अपना agent बनाना दूसरा विकल्प है।

1 GB का प्लान इसे क्यों नहीं संभाल पाएगा

Processes की संख्या गिनें। Postgres एक है। API एक Node process है। Worker दूसरा है। Web app तीसरा है। Sandbox supervisor चौथा है। इसके बाद, हर चल रहा bot एक container रखता है जिसमें graphical Linux desktop और browser होता है।

प्रोजेक्ट का अपना self-host doc एक ईमानदार आंकड़ा देता है: 2 vCPU और 4 GB वाली मशीन API, worker और Postgres के लिए पर्याप्त है जब E2B bot desktops को संभालता है। यह केवल control plane के लिए आवश्यक संख्या है, जबकि भारी हिस्सा कहीं और host किया गया है। यदि आप SANDBOX_PROVIDER=docker सेट करते हैं, तो वे desktops आपके VPS पर आ जाते हैं, इसलिए 4 GB न्यूनतम आवश्यकता (floor) बन जाता है, न कि लक्ष्य। यदि आप एक से अधिक bot को सक्रिय रखने की योजना बना रहे हैं, तो 8 GB से शुरुआत करें, और जब bot काम कर रहा हो तो docker stats के साथ वास्तविक संख्या मापें। Sandbox के अंदर का browser ही memory की खपत बढ़ाता है, इसलिए spec sheet आपको सही जानकारी नहीं देगी। Agent के काम के लिए VPS का आकार निर्धारित करने की सामान्य विधि के लिए, agent VPS को वास्तव में कितनी RAM और CPU की आवश्यकता होती है में माप की प्रक्रिया विस्तार से दी गई है।

एक setting इसे और खराब होने से बचाती है। .env.example में SANDBOX_IDLE_MS=600000 इस टिप्पणी के साथ आता है कि यह E2B computers को pause कर देता है, या Docker वाले को उतने idle milliseconds के बाद बंद कर देता है। दस मिनट idle रहने पर computer हट जाता है। स्वीकार्य न्यूनतम मान 30000 है। इसके बिना, आपके द्वारा खोला गया हर bot हमेशा के लिए memory घेरे रखेगा।

Disk भी मायने रखती है। Sandbox image, Node modules और Postgres volume एक ही disk साझा करते हैं, इसलिए 40 GB एक उचित शुरुआती बिंदु है।

Clone करने से पहले एक version pin करें

Rakazo बहुत तेजी से विकसित हो रहा है और main कोई official release नहीं है। 16 August 2026 तक, repository में केवल एक tag, v0.1.0-beta मौजूद है, जिसे 13 August 2026 को publish किया गया था और इसे 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 एक ऐसा label है जिसे maintainer कभी भी बदल सकता है, इसलिए इनमें से कोई भी उस tree की पहचान नहीं करता जिस पर आप वापस आ सकें। एक commit identifier कभी नहीं बदलता। अपने अन्य server तथ्यों के साथ इसे भी लिख लें, क्योंकि जब कोई upgrade system को खराब कर देता है, तो सबसे सस्ता समाधान git checkout <old commit> और rebuild करना होता है, और यह तभी काम करता है जब आपको पता हो कि कौन सा commit सही ढंग से काम कर रहा था। इसे सटीक रूप से pin करना एक beta tax है, न कि कोई सार्वभौमिक नियम। जो project जानबूझकर releases जारी करते हैं, उन्हें एक published tag पर रखा जा सकता है, जैसा कि openGym जैसा एक छोटा self-hosted stack करता है।

आवश्यकताएं: Node 22, pnpm 9, और Docker

node -v
pnpm -v
docker --version

package.json में "engines": { "node": ">=22" } और "packageManager": "pnpm@9.15.0" घोषित हैं, इसलिए node -v को v22 या उससे अधिक version print करना चाहिए। Ubuntu archive में मौजूद Node package आमतौर पर इससे पुराना होता है, इसलिए इसे NodeSource या nvm से install करें। 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 group में जोड़ें और एक नया login shell खोलें। पहले यह समझ लें कि इससे क्या अधिकार मिलते हैं: docker group की सदस्यता मशीन पर root के बराबर है, क्योंकि इस group का कोई भी सदस्य ऐसा container start कर सकता है जो host filesystem को mount करता हो।

.env कॉन्फ़िगर करें, फिर Postgres शुरू करें

cp .env.example .env
chmod 600 .env

नेटवर्क पर कुछ भी expose करने से पहले दो values को बदलना अनिवार्य है। .env.example में BETTER_AUTH_SECRET=replace-with-32-plus-character-secret और ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase शामिल हैं। Rakazo डेवलपमेंट के बाहर इन placeholder values को स्वीकार नहीं करता है, इसलिए यदि कॉन्फ़िगरेशन अधूरा है, तो deployment चलने के बजाय विफल हो जाएगा, ताकि repository में प्रकाशित secret का उपयोग न हो।

openssl rand -base64 48
openssl rand -hex 32

इसके बाद database को अलग से शुरू करें और 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 computer image को build करता है, जिसे package.json में docker build -t rakazo/computer:local infra/sandboxes/computer के रूप में परिभाषित किया गया है। यह एक graphical image है, इसलिए पहली बार build करने में काफी डेटा डाउनलोड होता है और समय लगता है। पुष्टि करें कि यह docker image ls rakazo/computer के साथ आ गई है, जो एक row print करेगा।

Compose file, Postgres को 127.0.0.1:5433:5432 के रूप में publish करती है, जो केवल loopback तक सीमित है। इसे वैसा ही रहने दें। डेवलपमेंट credentials rakazo:rakazo हैं, जो repository में मौजूद हैं। यदि Postgres का port इंटरनेट से सुलभ हो और password प्रकाशित हो, तो scanners उसे कुछ ही घंटों में ढूंढ लेते हैं। Production compose file इसके बजाय POSTGRES_PASSWORD को पढ़ती है, इसलिए जब आप उस चरण पर पहुंचें, तो इसे एक random string पर सेट करें।

पहली बार चलाना

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 को हर इंटरफ़ेस पर पब्लिश करती है। यदि आप पब्लिक VPS पर पूरा डेवलपमेंट कंपोज़ स्टैक चलाते हैं, तो ऐप एक्सपोज़ हो जाएगा। इसलिए, जो कुछ भी आप रनिंग छोड़ते हैं, उसके लिए प्रोडक्शन फ़ाइल और उसके रिवर्स प्रॉक्सी का उपयोग करें।

सर्वर पर कौन सा सैंडबॉक्स प्रदाता सुरक्षित है?

यह वह एक सेटिंग है जिसे सही रखना आवश्यक है। SANDBOX_PROVIDER में .env के चार मान (values) होते हैं।

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

डेस्कटॉप चेतावनी को गंभीरता से लें। डेस्कटॉप मोड में कोई आइसोलेशन बाउंड्री नहीं होती है, इसलिए बॉट API प्रोसेस चलाने वाले यूज़र के रूप में शेल कमांड्स निष्पादित करता है। इसमें उस यूज़र की होम डायरेक्टरी, SSH कीज़, क्लाउड क्रेडेंशियल्स और .env का उपयोग होता है। वेब पेज का टेक्स्ट जिसे बॉट पढ़ता है, वह आपके सर्वर पर एक कमांड बन जाता है। सर्वर पर डेस्कटॉप मोड का उपयोग करने का अर्थ है कि बॉट आपके क्रेडेंशियल्स तक पहुँच प्राप्त कर सकता है। इसका उपयोग केवल उसी मशीन पर करें जिस पर आप स्वयं काम करते हैं, अन्यथा इसका उपयोग न करें। प्रदाताओं को बदलने से वेब पेज पाथ के चारों ओर एक कंटेनर बन जाता है, न कि वह पूरी तरह सुरक्षित होता है, और बॉट को अपना स्वयं का SearXNG सर्च बैकएंड देना सर्च साइड से उसी इंजेक्शन सरफेस को कवर करता है।

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

Model API keys कहाँ रखें?

Rakazo में कोई managed model billing नहीं है। आपको अपनी key स्वयं लानी होगी। .env.example, PI_DEFAULT_PROVIDER=openrouter को सेट करता है, इसलिए OPENROUTER_API_KEY ही सामान्य स्थान है, और provider keys भी इसी setting के माध्यम से काम करती हैं।

Key को .env में रखें और इसे किसी भी ऐसी file में न डालें जिसे आप commit करते हैं। repository में मौजूद दोनों compose commands, --env-file .env को pass करते हैं, इसलिए values बिना किसी ऐसी YAML file में लिखे containers तक पहुँच जाती हैं जिसे git track करता है। आप OPENROUTER_API_KEY को खाली भी छोड़ सकते हैं और onboarding के दौरान app में key paste कर सकते हैं, जो एक और कारण है कि ENCRYPTION_KEY को shipped placeholder के बजाय एक वास्तविक random value की आवश्यकता क्यों है।

Bot द्वारा उपयोग किए जाने से पहले provider के पास key पर spending limit सेट करें। यदि कोई bot loop में फंस जाता है, तो वह खर्च बढ़ा सकता है, और per-key limit ही एकमात्र ऐसा उपाय है जो आपके निरंतर निगरानी करने पर निर्भर नहीं है। इस key को अपना एक अलग नाम दें ताकि आप इसे अकेले revoke कर सकें। यदि आप इसे अपने बजाय किसी team के लिए set कर रहे हैं, तो OneCLI's one gateway in front of everyone's agent इसी समस्या का एक अलग समाधान है, क्योंकि यह provider keys को हर व्यक्ति के लिए अलग रखने के बजाय एक ही स्थान पर सुरक्षित रखता है।

डेवलपमेंट मोड से प्रोडक्शन में जाना

यह रिपॉजिटरी एक प्रोडक्शन compose फाइल प्रदान करती है जो Postgres, API, वर्कर, वेब ऐप और TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) सर्टिफिकेट्स के लिए 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 (अनकॉम्प्लिकेटेड फायरवॉल) नियम सेट करता है, fail2ban को चालू करता है और AppArmor प्रोफाइल लागू करता है। इसे चलाने से पहले पढ़ें, क्योंकि यह आपके लॉगिन करने के तरीके को बदल देता है। इसे चलाते समय एक दूसरा SSH सेशन खुला रखें।

प्रोडक्शन .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 रिकॉर्ड पॉइंट करें। Caddy RAKAZO_HOST में दिए गए नाम के लिए सर्टिफिकेट का अनुरोध करता है, और यदि वह नाम इस बॉक्स पर रिजॉल्व नहीं होता है या यदि पोर्ट 80 बाहर से बंद है, तो अनुरोध विफल हो जाता है।

SIGNUP_ALLOWLIST=you@example.com को भी सेट करें। SIGNUPS_ENABLED=true डिफ़ॉल्ट है, इसलिए पब्लिक नाम पर मौजूद इंस्टेंस उसे खोजने वाले किसी भी व्यक्ति से रजिस्ट्रेशन स्वीकार करता है, और प्रत्येक नए अकाउंट को एक कंप्यूटर मिलता है। पहले अलाउलिस्ट (allowlist) का उपयोग करें। यदि आप चाहें तो बाद में इसे ढीला कर सकते हैं। यदि आप पहले से ही एक ही बॉक्स पर कई सेवाएं चला रहे हैं और प्रति ऐप एक अलाउलिस्ट के बजाय लोगों की एक ही सूची रखना चाहते हैं, तो उनके सामने एक Authentik इंस्टेंस रखना उस निर्णय को प्रॉक्सी पर ले जाता है, हालांकि यह Rakazo के स्वयं के Better Auth अकाउंट्स को बदलने के बजाय उनके सामने स्थित होता है।

रिपॉजिटरी में docs/self-host.md को प्रोडक्शन सेटिंग्स के लिए आधिकारिक मानें, क्योंकि यह कोड के साथ बदलता रहता है और यह गाइड नहीं। चूंकि Compose सारा काम कर रहा है, इसलिए सामान्य नियम लागू होते हैं, और VPS के लिए Docker Compose की बुनियादी बातें बताती हैं कि जब कोई स्टैक ऐसा हो जिसे आप महीनों तक नहीं छूते, तो --env-file और नेम्ड वॉल्यूम क्यों अधिक महत्वपूर्ण हो जाते हैं।

Backups

Postgres और data/ directory ही पूरा instance हैं।

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

backup.sh Postgres को dump करता है और data/ को archive करता है। जिस machine पर आप निर्भर हैं, उसके लिए infra/compose/backup-prod.sh को /usr/local/sbin/rakazo-backup के रूप में install करें, साथ ही repository द्वारा प्रदान किया गया timer भी लगाएँ, ताकि rotation अपने आप होता रहे। database वाले disk पर ही रखा गया backup, backup नहीं होता है, इसलिए इसे server से बाहर copy करें। इसके बाद, जरूरत पड़ने से पहले, एक spare server पर इसे एक बार restore करके देखें।

यह विफल क्यों होता है और आपको क्या दिखाई देगा

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 इसे साफ़ कर देता है, और इसके साथ ही डेटा भी डिलीट हो जाता है।

पोर्ट पहले से ही उपयोग में है। Postgres को चालू करने पर bind: address already in use के साथ विफलता मिलती है जब 5433 पोर्ट पर कोई अन्य चीज़ चल रही होती है, अक्सर यह कोई पुराना 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 अक्सर उस सेशन का कारण होता है जो कभी भी स्थिर नहीं रहता।

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 start होने के तुरंत बाद exit हो जाएगी। यदि आप अभी भी यह तय कर रहे हैं कि क्या Rakazo आपके लिए सही विकल्प है, तो self-hosted AI agents का सारांश इस श्रेणी के अन्य विकल्पों और उन्हें चलाने की लागत के बारे में जानकारी देता है।

FAQ

क्या मैं 1 GB VPS पर Rakazo चला सकता हूँ?

नहीं। Postgres, API, worker, sandbox supervisor और web app सभी एक साथ चलते हैं, और SANDBOX_PROVIDER=docker के साथ प्रत्येक सक्रिय bot एक container चलाता है जिसमें graphical desktop और browser होता है। प्रोजेक्ट के अपने दस्तावेज़ों के अनुसार 2 vCPU और 4 GB RAM केवल तभी पर्याप्त हैं जब API, worker और Postgres चल रहे हों और E2B bot desktops को host कर रहा हो। control plane के लिए 4 GB RAM को न्यूनतम आवश्यकता मानें, और यदि desktops आपके अपने सर्वर पर चलते हैं तो इससे अधिक RAM का उपयोग करें।

क्या सर्वर पर desktop sandbox provider सुरक्षित है?

नहीं। desktop bot के commands को सीधे API और worker host पर चलाता है, उसी user के रूप में जो उस process को चला रहा है, जिससे उस user की files और credentials तक पहुँच आसान हो जाती है। repository में इसे public या shared सर्वर पर उपयोग न करने की सलाह दी गई है। प्रत्येक bot के लिए एक अलग container हेतु docker का उपयोग करें, या जब एक से अधिक व्यक्ति login करें तो e2b का उपयोग करें।

मुझे Rakazo का कौन सा version install करना चाहिए?

16 August 2026 तक केवल एक tag, v0.1.0-beta उपलब्ध है, जिसे 13 August 2026 को प्रकाशित किया गया था और यह एक prerelease है। main को track करने के बजाय उस commit को देखें जिसकी ओर यह इशारा करता है, यानी 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb। branch आपके काम के दौरान बदल सकती है और tag को फिर से point किया जा सकता है, इसलिए इनमें से कोई भी उस tree की पहचान नहीं करता जिस पर आप वापस लौट सकें। commit को record करें, क्योंकि rollback केवल तभी संभव है जब आपको पता हो कि कौन सा version काम कर रहा था।

मैं अपनी OpenRouter API key कहाँ रखूँ?

इसे .env में OPENROUTER_API_KEY के रूप में रखें, और इसे कभी भी ऐसी compose file में न डालें जिसे आप commit करते हैं। repository में दी गई दोनों compose commands --env-file .env को pass करती हैं, इसलिए यह value बिना tracked YAML में लिखे containers तक पहुँच जाती है। आप इसे खाली भी छोड़ सकते हैं और onboarding के दौरान app में key paste कर सकते हैं। provider के पास key पर spending limit सेट करें, क्योंकि loop में फंसा हुआ bot तब तक model को call करता रहेगा जब तक उसे रोका न जाए।

क्या मुझे domain name और TLS की आवश्यकता है?

पहले परीक्षण के बाद किसी भी चीज़ के लिए, हाँ। production compose file Caddy को चलाती है और स्वचालित रूप से certificates प्राप्त करती है, और RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN तथा API_URL सभी का public HTTPS origin एक ही होना चाहिए। पहली बार देखने के लिए आप domain छोड़ सकते हैं: pnpm dev चलाएं और port 5173 को publish करने के बजाय उसे SSH के माध्यम से forward करें।