Rakazo کو VPS پر self-host کرنے کا طریقہ

Rakazo کی self-hosting میں دراصل کیا چلتا ہے

Rakazo کی self-hosting کا مطلب ہے کہ ایک 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 ملتی ہے، اور وہ دوسرے bots یا مختصر مدت کے subagents شروع کر سکتا ہے۔

آخری نکتہ اس سروس کے لیے desktop کے بجائے VPS (virtual private server) استعمال کرنے کی وجہ ہے۔ جو bot memory رکھتا ہو اور scheduled کام چلاتا ہو، وہ اس وقت بھی قابل رسائی ہونا چاہیے جب آپ سو رہے ہوں۔ Suspend ہونے والا laptop queue کو روک دیتا ہے۔

August 2026 تک Rakazo ابتدائی beta میں ہے، اس لیے اسے مکمل appliance کے بجائے ایک عملی setup سمجھیں۔ پورا stack TypeScript پر مبنی ہے: web app کے لیے React 19 اور Vite، API کے لیے Hono، database کے لیے Prisma کے ساتھ Postgres، accounts کے لیے Better Auth، اور background jobs کے لیے Graphile Worker۔ Graphile Worker اپنی queue Postgres کے اندر محفوظ کرتا ہے، اس لیے Redis یا دوسرا data store چلانے کی ضرورت نہیں۔ .env.example، WAKEUP_DRIVER=graphile کو set کرتا ہے، جس کا مطلب ہے کہ bot کا بیدار ہونا Postgres-backed job ہے۔ Postgres روکنے سے ہر scheduled bot action بھی رک جاتا ہے۔ اگر آپ کسی اور کا product چلانے کے بجائے مختلف اجزا سے agent تیار کرنا چاہتے ہیں تو اپنا agent اجزا سے بنانا دوسرا راستہ ہے۔

یہ 1 GB plan اسے کیوں نہیں سنبھال سکتا

Processes شمار کریں۔ Postgres ایک process ہے۔ API ایک Node process ہے۔ worker دوسرا process ہے۔ web app تیسرا process ہے۔ sandbox supervisor چوتھا process ہے۔ اس کے بعد ہر running bot کے لیے ایک container چلتا ہے، جس میں graphical Linux desktop اور browser موجود ہوتا ہے۔

Project کی اپنی self-host دستاویز ایک واضح عدد دیتی ہے: 2 vCPU اور 4 GB والی machine API، worker اور Postgres کے لیے کافی ہے، جب E2B bot desktops کا انتظام خود کرتا ہو۔ یہ صرف control plane کے لیے درکار وسائل ہیں، جبکہ بھاری حصہ کسی دوسری جگہ host ہوتا ہے۔ SANDBOX_PROVIDER=docker set کرنے پر یہ desktops آپ کے VPS پر منتقل ہو جاتے ہیں، اس لیے 4 GB ہدف نہیں بلکہ کم از کم حد بن جاتی ہے۔ اگر آپ ایک سے زیادہ bot کو فعال رکھنا چاہتے ہیں تو 8 GB سے شروع کریں، اور bot کے کام کرنے کے دوران docker stats سے اصل استعمال ناپیں۔ Memory کا استعمال sandbox کے اندر موجود browser کی وجہ سے بڑھتا ہے، اس لیے spec sheet آپ کو درست عدد نہیں بتا سکتی۔ Agent کے کام کے لیے machine کے سائز کا عمومی طریقہ جاننے کے لیے agent VPS کو درکار RAM اور CPU کی مقدار میں پیمائش کا طریقہ تفصیل سے بیان کیا گیا ہے۔

ایک setting اس مسئلے کو مزید بڑھنے سے روکتی ہے۔ .env.example، SANDBOX_IDLE_MS=600000 کو اس comment کے ساتھ ship کرتا ہے کہ مقررہ idle milliseconds گزرنے کے بعد E2B computers کو pause، یا Docker computers کو stop کر دیا جائے۔ دس منٹ تک idle رہنے کے بعد computer ختم ہو جاتا ہے۔ قابل قبول کم از کم value 30000 ہے۔ اس کے بغیر آپ نے جتنے بھی bots کھولے ہوں، ہر ایک ہمیشہ memory محفوظ رکھے گا۔

Disk بھی اہم ہے۔ Sandbox image، Node modules اور Postgres volume ایک ہی disk استعمال کرتے ہیں، اس لیے 40 GB سے شروع کرنا مناسب ہے۔

clone کرنے سے پہلے version مقرر کریں

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 مقرر کریں۔ اگلے git pull پر branch آپ کے نیچے تبدیل ہو جاتی ہے، جبکہ tag ایک ایسا movable label ہے جسے maintainer دوبارہ کسی دوسری جگہ مقرر کر سکتا ہے۔ اس لیے ان میں سے کوئی بھی ایسی tree کی شناخت نہیں کرتا جس پر آپ واپس جا سکیں۔ commit identifier تبدیل نہیں ہو سکتا۔ اپنے commit identifier کو سرور سے متعلق دیگر معلومات کے ساتھ لکھ کر محفوظ کریں، کیونکہ upgrade ناکام ہونے پر آسان حل 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 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 کی رکنیت مشین پر root کے مساوی ہے، کیونکہ اس group میں شامل کوئی بھی شخص ایسا container شروع کر سکتا ہے جو host filesystem کو mount کرے۔

.env ترتیب دیں، پھر Postgres شروع کریں

cp .env.example .env
chmod 600 .env

کسی بھی چیز کو network کے سامنے رکھنے سے پہلے دو values تبدیل کرنا ضروری ہے۔ .env.example، BETTER_AUTH_SECRET=replace-with-32-plus-character-secret اور ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase فراہم کرتا ہے۔ Rakazo development کے علاوہ ان placeholder values کو مسترد کرتا ہے، اس لیے نامکمل configuration والا deployment واضح failure کے ساتھ رک جاتا ہے، بجائے اس کے کہ 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 بناتا ہے، جس کی تعریف package.json میں docker build -t rakazo/computer:local infra/sandboxes/computer کے طور پر کی گئی ہے۔ یہ graphical image ہے، اس لیے پہلی build میں بہت سا data download ہوتا ہے اور وقت لگتا ہے۔ docker image ls rakazo/computer سے تصدیق کریں کہ image صحیح طرح بن گئی ہے؛ اس command کو ایک row دکھانی چاہیے۔

Compose file Postgres کو 127.0.0.1:5433:5432 کے طور پر publish کرتی ہے، جو صرف loopback تک محدود ہے۔ اسے اسی طرح رہنے دیں۔ development credentials rakazo:rakazo ہیں اور repository میں موجود ہیں۔ published password کے ساتھ internet سے قابل رسائی Postgres port کو scanners چند گھنٹوں میں تلاش کر لیتے ہیں۔ production compose file اس کے بجائے POSTGRES_PASSWORD پڑھتی ہے، اس لیے وہاں پہنچنے پر اسے random string پر set کریں۔

پہلی بار چلانا

pnpm dev

اس سے چار چیزیں شروع ہوتی ہیں: port 3100 پر API، Graphile Worker، port 5173 پر Vite web app، اور port 7091 پر sandbox supervisor۔ ایپ http://127.0.0.1:5173 پر دستیاب ہے، جہاں sign-in page ظاہر ہونا چاہیے۔

VPS پر آپ اس مشین کے سامنے موجود نہیں ہوتے، اور اس تک پہنچنے کے لیے port 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 host پر Vite چلاتا ہے اور اسے مقامی طور پر bind کرتا ہے۔ compose file کی web service 5173:5173 کو ہر interface پر publish کرتی ہے۔ public VPS پر مکمل development compose stack شروع کرنے سے ایپ exposed ہو جاتی ہے، اس لیے جو چیز بھی چلتی چھوڑنی ہو اس کے لیے production file اور اس کا reverse proxy استعمال کریں۔

سرور پر کون سا sandbox provider محفوظ ہے؟

یہ وہ واحد setting ہے جسے درست کرنا ضروری ہے۔ SANDBOX_PROVIDER میں .env کی چار values ہوتی ہیں۔

• docker default ہے۔ ہر bot کو آپ کی machine پر اپنا container ملتا ہے، جو pnpm sandbox:build سے بنائی گئی image سے تیار ہوتا ہے۔ یہ self-hosted setup کا تیز ترین طریقہ ہے۔
• e2b bot computers کو E2B پر چلاتا ہے اور اسے E2B_API_KEY درکار ہوتا ہے۔ پروجیکٹ public یا multi-user deployments کے لیے اسی کی تجویز دیتا ہے، کیونکہ اس سے bot computers آپ کے API اور database چلانے والے host سے الگ رہتے ہیں۔
• desktop bot کے commands براہ راست API اور worker host پر چلاتا ہے۔ repository کی ہدایت واضح ہے: اسے public یا shared server پر استعمال نہ کریں۔
• fake tests کے لیے in-process emulator ہے۔ یہ runtime نہیں ہے۔

desktop warning کو حرف بہ حرف سنجیدہ لیں۔ desktop mode میں isolation boundary بالکل نہیں ہوتی۔ اس لیے bot، API process چلانے والے user کے طور پر shell commands چلاتا ہے، اور اسے اسی user کی home directory، اسی user کی SSH keys، اسی user کی cloud credentials اور اسی user کا .env حاصل ہوتا ہے۔ bot جس web page کو پڑھتا ہے اس کا text آپ کے server پر ایک command بن سکتا ہے۔ server پر desktop mode استعمال کرنے سے bot کے پاس آپ کی credentials آ سکتی ہیں۔ اسے صرف اس machine پر استعمال کریں جس کے سامنے آپ موجود ہوں، ورنہ بالکل استعمال نہ کریں۔

docker ایک حقیقی boundary ہے، لیکن مکمل نہیں۔ ایک bot دوسرے bot کی files نہیں پڑھ سکتا، کیونکہ ہر bot کا اپنا container ہوتا ہے۔ تاہم، وہ supervisor جو یہ containers بناتا ہے /var/run/docker.sock کو mount کرتا ہے، اور host Docker socket کا control دراصل host کا control ہے۔ اس لیے supervisor کو private رکھیں۔ .env.example، SANDBOX_SUPERVISOR_TOKEN کو ایک optional الگ service credential کے طور پر document کرتا ہے، جو خالی ہونے پر default طور پر BETTER_AUTH_SECRET بن جاتا ہے۔ اس کا مطلب ہے کہ اس secret کو اس کے placeholder پر چھوڑنے سے container-creating service ایک ایسی string سے محفوظ ہوتی ہے جسے GitHub پر ہر شخص پڑھ سکتا ہے۔ دونوں values set کریں۔ یہاں دستیاب مضبوط ترین separation کے لیے e2b استعمال کریں، یا Rakazo کے لیے ایسی machine مختص کریں جس پر کوئی اور چیز موجود نہ ہو۔ یہی وجہ disposable VM میں coding agents چلانے کے پیچھے بھی ہے: agent کے غلط اقدام سے نمٹنے کا سب سے سستا طریقہ یہ ہے کہ اس کی machine کی کوئی قدر نہ ہو۔

ماڈل API keys کہاں رکھی جاتی ہیں؟

Rakazo میں managed model billing نہیں ہے۔ آپ خود key فراہم کرتے ہیں۔ .env.example، PI_DEFAULT_PROVIDER=openrouter کو set کرتا ہے، اس لیے OPENROUTER_API_KEY معمول کی جگہ ہے، اور provider keys بھی اسی setting کے ذریعے کام کرتی ہیں۔

key کو .env میں رکھیں اور ایسی کسی file میں شامل نہ کریں جسے آپ commit کرتے ہیں۔ Repository میں موجود دونوں compose commands --env-file .env pass کرتی ہیں، اس لیے values containers تک پہنچ جاتی ہیں، مگر git کے زیرِ نگرانی YAML میں کبھی نہیں لکھی جاتیں۔ آپ OPENROUTER_API_KEY کو خالی بھی چھوڑ سکتے ہیں اور onboarding کے دوران app میں key paste کر سکتے ہیں۔ یہی ایک اور وجہ ہے کہ ENCRYPTION_KEY میں shipped placeholder کے بجائے واقعی random value ہونی چاہیے۔

Bot کے استعمال سے پہلے provider میں اس key کے لیے spending limit مقرر کریں۔ جو bot loop میں پھنس جائے، وہ خرچ کرتا رہتا ہے، اور per-key limit ہی ایسا واحد روکنے کا طریقہ ہے جو آپ کے نگرانی کرنے پر منحصر نہیں ہوتا۔ اس key کو الگ نام دیں تاکہ آپ صرف اسی key کو revoke کر سکیں۔

dev mode سے ایسی production deployment تک جانا جسے مسلسل چلتا چھوڑا جا سکے

Repository میں production compose file شامل ہے۔ یہ Postgres، API، worker، web app اور TLS (transport layer security) certificates کے لیے Caddy چلاتی ہے۔ Caddy یہ certificates خودکار طور پر حاصل کرتا ہے۔ اس configuration میں 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) rules مقرر کرتا ہے، fail2ban فعال کرتا ہے اور AppArmor profiles لاگو کرتا ہے۔ اسے چلانے سے پہلے پڑھیں، کیونکہ اس سے آپ کے login کرنے کا طریقہ تبدیل ہو جاتا ہے۔ اس کے چلتے وقت دوسری SSH session کھلی رکھیں۔

Production .env کو development والی configuration سے زیادہ چیزیں درکار ہوتی ہیں۔ Self-host documentation میں کم از کم مطلوبہ configuration درج ہے۔

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 کریں۔ Caddy RAKAZO_HOST میں موجود نام کے لیے certificate طلب کرتا ہے۔ اگر یہ نام اس server پر resolve نہ ہو، یا port 80 بیرونی network سے بند ہو، تو request ناکام ہو جاتی ہے۔

SIGNUP_ALLOWLIST=you@example.com بھی set کریں۔ SIGNUPS_ENABLED=true default ہے۔ اس لیے public name پر موجود instance ہر اس شخص سے registrations قبول کرتا ہے جو اسے تلاش کر لے، اور ہر نئے account کو ایک computer ملتا ہے۔ پہلے allowlist مقرر کریں۔ اگر چاہیں تو بعد میں پابندی کم کر دیں۔

Repository میں موجود docs/self-host.md کو production settings کے لیے مستند ماخذ سمجھیں، کیونکہ یہ code کے ساتھ تبدیل ہوتا رہتا ہے اور یہ guide تبدیل نہیں ہوتی۔ Compose چونکہ یہ کام انجام دے رہا ہے، اس لیے عام rules لاگو ہوتے ہیں۔ VPS کے لیے Docker Compose کی بنیادی باتیں وضاحت کرتی ہیں کہ جب stack کو کئی ماہ تک بغیر مداخلت چلتا چھوڑنا ہو تو --env-file اور named volumes زیادہ اہم کیوں ہو جاتے ہیں۔

بیک اپس

Postgres اور data/ ڈائریکٹری پورے 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 database تک نہیں پہنچ سکتا۔ Migration رپورٹ کرتی ہے کہ database server 127.0.0.1:5433 پر قابل رسائی نہیں ہے۔ یا تو Postgres container چل نہیں رہا، یا چل رہا ہے لیکن ابھی ready نہیں ہوا۔ docker compose --env-file .env -f infra/compose/docker-compose.yml ps چلائیں اور دیکھیں کہ postgres service کی حالت healthy ظاہر ہو، کیونکہ compose file میں اس کے لیے health check موجود ہے جو ہر تین seconds بعد چلتا ہے۔ جو container مسلسل restart loop میں رہے، اس کا عام مطلب یہ ہے کہ pgdata volume مختلف credentials کے ساتھ بنایا گیا تھا۔ docker compose ... down -v اسے صاف کرتا ہے، اور اس کے ساتھ data بھی delete ہو جاتا ہے۔

Port پہلے ہی استعمال ہو رہا ہے۔ جب کوئی دوسری process 5433 پر قابض ہو تو Postgres شروع کرنے پر bind: address already in use آتا ہے۔ عموماً وجہ کوئی پرانا Rakazo stack ہوتا ہے جسے آپ stop کرنا بھول گئے ہوں۔ sudo ss -lntp | grep 5433 process کا نام دکھاتا ہے۔

کسی bot کو computer نہیں ملتا۔ SANDBOX_PROVIDER=docker کے ساتھ rakazo/computer:local image نہ ہو تو شروع کرنے کے لیے کچھ موجود نہیں ہوتا۔ docker image ls rakazo/computer ایک ہی line میں اس کی وجہ بتاتا ہے، اور pnpm sandbox:build اسے درست کرتا ہے۔ اگر supervisor Docker socket تک نہیں پہنچ سکتا تو یہ containers بھی create نہیں کر سکتا، اور message path دکھاتا ہے: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock۔

طویل command درمیان میں رک جاتی ہے۔ .env.example، SANDBOX_COMMAND_TIMEOUT_MS=300000 مقرر کرتا ہے، اس لیے bot کے computer کے اندر چلنے والی ایک command پانچ minutes کے بعد روک دی جاتی ہے۔ Slow builds کے لیے اس قدر کو بڑھائیں؛ یہ فرض نہ کریں کہ sandbox crash ہو گیا ہے۔

pnpm install غیر واضح انداز میں ناکام ہوتا ہے۔ کسی اور چیز سے پہلے node -v چیک کریں۔ Workspace میں >=22 درج ہے، اور پرانا Node version کے بارے میں message دینے کے بجائے dependency code میں ناکام ہوتا ہے۔

Sign-in مقامی طور پر کام کرتا ہے، لیکن domain کے ذریعے نہیں۔ BETTER_AUTH_URL، WEB_ORIGIN اور API_URL، سب میں address bar کے عین مطابق public origin ہونا چاہیے، scheme سمیت۔ ان میں سے کسی ایک میں موجود پرانا http://127.0.0.1:5173 عموماً اس session کی وجہ بنتا ہے جو برقرار نہیں رہتا۔

پن کیے گئے checkout کو اپ ڈیٹ کرنا

self-host دستاویز میں upgrade کا طریقہ مختصر ہے: نیا 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 میں واپسی کا ایسا راستہ نہیں ہوتا جس پر آپ بھروسا کر سکیں۔ اپنے pinned SHA اور نئے SHA کے درمیان موجود commits کو apply کرنے سے پہلے پڑھیں، کیونکہ اتنے نئے project میں environment variables کے نام بغیر اطلاع تبدیل ہو سکتے ہیں، اور missing variable ایسی service کی صورت میں ظاہر ہوتا ہے جو start ہونے کے بعد فوراً exit ہو جاتی ہے۔ اگر آپ ابھی یہ فیصلہ کر رہے ہیں کہ Rakazo چلانا بھی مناسب ہے یا نہیں، تو self-hosted AI agents کا جائزہ میں اسی زمرے کے دوسرے اختیارات اور انہیں فعال رکھنے کی لاگت بیان کی گئی ہے۔

FAQ

کیا میں Rakazo کو 1 GB VPS پر چلا سکتا ہوں؟

نہیں۔ Postgres، API، worker، sandbox supervisor اور web app سب ایک ہی وقت میں چلتے ہیں، اور SANDBOX_PROVIDER=docker کے ساتھ ہر فعال bot ایک ایسا container شامل کرتا ہے جس میں graphical desktop اور browser موجود ہوتا ہے۔ پروجیکٹ کی اپنی دستاویز کے مطابق 2 vCPU اور 4 GB صرف API، worker اور Postgres کے لیے کافی ہیں، جب bot desktops کی میزبانی E2B کرے۔ control plane کے لیے 4 GB کو کم از کم ضرورت سمجھیں، اور جب desktops آپ کی مشین پر چلیں تو اس سے زیادہ میموری استعمال کریں۔

کیا desktop sandbox provider سرور پر محفوظ ہے؟

نہیں۔ desktop bot کے commands براہ راست API اور worker host پر چلاتا ہے۔ یہ اسی process کو چلانے والے user کے طور پر چلتا ہے، اس لیے اس user کی files اور credentials تک رسائی رکھتا ہے۔ repository میں اسے public یا shared server پر استعمال نہ کرنے کی ہدایت ہے۔ ہر bot کے لیے الگ container کے لیے docker استعمال کریں، یا ایک سے زیادہ افراد کے sign in کرنے پر e2b استعمال کریں۔

مجھے Rakazo کا کون سا version install کرنا چاہیے؟

16 August 2026 تک ایک ہی tag موجود ہے: v0.1.0-beta۔ یہ 13 August 2026 کو شائع ہوا تھا اور prerelease کے طور پر نشان زد ہے۔ main کو track کرنے کے بجائے اس tag کے بتائے ہوئے commit، 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb، کو checkout کریں۔ branch آپ کے نیچے بدل سکتی ہے، اور tag کو دوبارہ کسی دوسرے commit کی طرف point کیا جا سکتا ہے۔ اس لیے دونوں میں سے کوئی بھی ایسا tree متعین نہیں کرتا جس پر آپ واپس جا سکیں۔ commit record کریں، کیونکہ rollback صرف اسی وقت ممکن ہے جب آپ کو معلوم ہو کہ کون سا commit کام کر رہا تھا۔

میں اپنی OpenRouter API key کہاں رکھوں؟

اسے .env میں OPENROUTER_API_KEY کے طور پر رکھیں، اور اسے کبھی بھی commit کی جانے والی compose file میں شامل نہ کریں۔ 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 کی ضرورت ہے؟

پہلے test سے آگے کے کسی بھی استعمال کے لیے ہاں۔ production compose file Caddy چلاتی ہے اور certificates خودکار طور پر حاصل کرتی ہے، جبکہ RAKAZO_HOST، BETTER_AUTH_URL، WEB_ORIGIN اور API_URL سب میں ایک ہی public HTTPS origin ہونا چاہیے۔ پہلے جائزے کے لیے آپ domain کو چھوڑ سکتے ہیں: pnpm dev چلائیں اور اسے publish کرنے کے بجائے port 5173 کو SSH کے ذریعے forward کریں۔