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

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

Self-hosting Rakazo का अर्थ है एक Linux सर्वर पर पाँच चीजें चलाना: PostgreSQL, एक Graphile Worker process, API, web app, और हर सक्रिय bot के लिए एक sandbox container। Rakazo, Grok Bot का एक open-source विकल्प है, जिसे elie222 द्वारा Apache 2.0 licence के तहत प्रकाशित किया गया है। प्रत्येक bot को अपना thread, अपना computer, अपनी memory और अपना history मिलता है, और यह peers या अल्पकालिक subagents को spawn कर सकता है।

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

अगस्त 2026 तक Rakazo early 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 को active रखने की योजना बना रहे हैं, तो 8 GB से शुरुआत करें, और जब bot काम कर रहा हो तो docker stats के साथ वास्तविक संख्या मापें। Sandbox के अंदर का browser ही memory की खपत बढ़ाता है, इसलिए spec sheet आपको सही जानकारी नहीं देगी। Agent work के लिए सर्वर का आकार निर्धारित करने की सामान्य विधि के लिए, 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 कोई 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 एक ऐसा label है जिसे maintainer कभी भी बदल सकता है, इसलिए इनमें से कोई भी उस tree की पहचान नहीं करता जिस पर आप वापस लौट सकें। एक commit identifier कभी नहीं बदलता। इसे अपने अन्य server विवरणों के साथ कहीं लिख लें, क्योंकि जब कोई upgrade system को खराब कर देता है, तो सबसे सस्ता समाधान git checkout <old commit> और rebuild करना होता है, और यह तभी काम करता है जब आपको पता हो कि कौन सा 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 पैकेज आमतौर पर इससे पुराना होता है, इसलिए इसे 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 group में जोड़ें और एक नया login shell खोलें। पहले यह समझ लें कि इससे क्या अधिकार मिलते हैं: docker की सदस्यता मशीन पर root के समान है, क्योंकि इस group का कोई भी सदस्य ऐसा container शुरू कर सकता है जो host filesystem को mount करता हो।

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

cp .env.example .env
chmod 600 .env

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

सर्वर पर कौन सा sandbox प्रदाता सुरक्षित है?

यह वह सेटिंग है जिसे सही रखना सबसे महत्वपूर्ण है। SANDBOX_PROVIDER में .env चार मान (values) लेता है।

• 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 में कोडिंग एजेंट चलाने के पीछे भी है: किसी एजेंट द्वारा गलत कार्य करने पर सुरक्षित रहने का सबसे सस्ता तरीका यह है कि उसकी मशीन का मूल्य शून्य हो।

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 कर सकें।

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

रिपॉजिटरी में एक प्रोडक्शन 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 का उपयोग करें। यदि आप चाहें तो बाद में इसे ढीला कर सकते हैं।

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

Backups

Postgres और data/ डायरेक्टरी ही पूरा instance हैं।

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

backup.sh, Postgres का dump लेता है और data/ को archive करता है। जिस मशीन पर आप निर्भर हैं, उसके लिए infra/compose/backup-prod.sh को /usr/local/sbin/rakazo-backup के रूप में इंस्टॉल करें और रिपॉजिटरी द्वारा प्रदान किए गए timer का उपयोग करें, ताकि rotation अपने आप हो जाए। डेटाबेस वाली डिस्क पर रखा गया बैकअप वास्तव में बैकअप नहीं है, इसलिए इसे मशीन से बाहर कहीं और कॉपी करें। इसके बाद, जरूरत पड़ने से पहले एक बार इसे किसी spare सर्वर पर 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

सबसे पहले बैकअप लें। Migrations केवल आगे की ओर होती हैं, और beta वर्ज़न में कोई ऐसा reverse path नहीं होता जिस पर आप भरोसा कर सकें। अपडेट करने से पहले अपने pinned SHA और नए SHA के बीच के commits को पढ़ें, क्योंकि इतने नए प्रोजेक्ट में अक्सर बिना किसी पूर्व सूचना के environment variables के नाम बदल दिए जाते हैं, और एक missing 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 को न्यूनतम आवश्यकता मानें, और यदि desktops आपके अपने मशीन पर चलते हैं तो इससे अधिक RAM का उपयोग करें।

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

नहीं। desktop bot के commands को सीधे API और worker host पर चलाता है। यह उस user के रूप में चलता है जो process को execute कर रहा है, जिससे उस 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 को भी re-point किया जा सकता है, इसलिए इनमें से कोई भी उस tree की पहचान नहीं करता जिस पर आप वापस लौट सकें। commit ID को 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 करें।