آموزش نصب و راه اندازی Rakazo روی VPS

آنچه Rakazo در حالت self-hosting واقعاً اجرا می‌کند

Self-hosting برای Rakazo به معنای اجرای پنج مورد روی یک سرور Linux است: PostgreSQL، یک پردازش Graphile Worker، رابط API، برنامه وب و یک container سندباکس برای هر باتی که فعال است. Rakazo یک جایگزین متن‌باز برای Grok Bot است که توسط elie222 تحت مجوز Apache 2.0 منتشر شده است. هر بات رشته (thread)، فضای محاسباتی، حافظه و تاریخچه اختصاصی خود را دارد و می‌تواند همتایان یا زیر-عامل‌های (subagents) کوتاه‌مدت ایجاد کند.

دلیل اینکه این سرویس باید روی یک VPS (سرور مجازی خصوصی) اجرا شود و نه روی دسکتاپ، همین بخش آخر است. باتی که حافظه را نگه می‌دارد و کارهای زمان‌بندی‌شده را اجرا می‌کند، باید در زمانی که شما خواب هستید نیز در دسترس باشد. لپ‌تاپی که به حالت تعلیق (suspend) می‌رود، صف پردازش را متوقف می‌کند.

Rakazo تا اوت 2026 در مرحله بتای اولیه است، بنابراین با آن به عنوان یک پیکربندی عملیاتی برخورد کنید، نه یک محصول نهایی. کل پشته (stack) از نوع TypeScript است: React 19 و Vite برای برنامه وب، Hono برای API، Postgres به همراه Prisma، Better Auth برای حساب‌های کاربری و Graphile Worker برای کارهای پس‌زمینه. Graphile Worker صف خود را درون Postgres ذخیره می‌کند، بنابراین نیازی به Redis یا هیچ پایگاه داده دومی برای اجرا نیست. .env.example مقدار WAKEUP_DRIVER=graphile را تنظیم می‌کند، که به این معنی است که بیدار شدن یک بات، یک job مبتنی بر Postgres است. اگر Postgres را متوقف کنید، تمام فعالیت‌های زمان‌بندی‌شده بات‌ها نیز با آن متوقف می‌شود. اگر ترجیح می‌دهید به جای اجرای محصول شخص دیگر، عامل خود را از قطعات مختلف سرهم کنید، ساخت عامل شخصی از اجزای سازنده مسیر جایگزین شماست.

چرا یک پلن 1 GB برای این کار کافی نیست

تعداد پردازش‌ها را بشمارید. Postgres یک پردازش است. API یک پردازش Node است. Worker پردازش دوم است. برنامه وب پردازش سوم است. ناظر sandbox پردازش چهارم است. سپس هر بات در حال اجرا، یک کانتینر دریافت می‌کند که شامل یک دسکتاپ گرافیکی Linux و یک مرورگر است.

مستندات self-host خود پروژه یک عدد صادقانه ارائه می‌دهد: یک ماشین با 2 vCPU و 4 GB رم برای API، Worker و Postgres کافی است زمانی که E2B میزبان دسکتاپ‌های بات باشد. این عدد فقط برای control plane است، در حالی که بخش سنگین کار در جای دیگری میزبانی می‌شود. اگر SANDBOX_PROVIDER=docker را تنظیم کنید، آن دسکتاپ‌ها به VPS شما منتقل می‌شوند؛ بنابراین 4 GB به جای هدف، به حداقل نیاز تبدیل می‌شود. اگر قصد دارید بیش از یک بات را فعال نگه دارید، با 8 GB شروع کنید و مقدار واقعی را با docker stats در حین کار بات اندازه‌گیری کنید. مرورگر داخل sandbox همان چیزی است که میزان مصرف حافظه را تغییر می‌دهد، بنابراین برگه مشخصات فنی به شما پاسخ دقیقی نخواهد داد. برای روش کلی تعیین ابعاد سرور جهت کارهای عاملی (agent work)، میزان رم و CPU مورد نیاز واقعی برای یک VPS عاملی اندازه‌گیری‌ها را با جزئیات بررسی می‌کند.

یک تنظیم از بدتر شدن این وضعیت جلوگیری می‌کند. .env.example به همراه SANDBOX_IDLE_MS=600000 ارائه می‌شود که طبق توضیحات آن، کامپیوترهای E2B را پس از گذشت آن تعداد میلی‌ثانیه در حالت idle، متوقف یا کانتینرهای Docker را خاموش می‌کند. پس از ده دقیقه عدم فعالیت، کامپیوتر حذف می‌شود. حداقل مقدار پذیرفته‌شده 30000 است. بدون این تنظیم، هر باتی که تا به حال باز کرده‌اید، برای همیشه حافظه اشغال می‌کرد.

فضای دیسک نیز اهمیت دارد. ایمیج sandbox، ماژول‌های Node و volume مربوط به Postgres همگی از یک دیسک استفاده می‌کنند، بنابراین 40 GB نقطه شروع معقولی است.

نسخه را پیش از clone کردن ثابت کنید

پروژه Rakazo به‌سرعت در حال تغییر است و main یک نسخه رسمی (release) محسوب نمی‌شود. تا تاریخ 16 August 2026، این مخزن تنها دارای یک تگ به نام 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 یا تگ، خودِ commit را ثابت (pin) کنید. یک branch در git pull بعدی تغییر می‌کند و یک تگ، برچسبی قابل‌جابه‌جایی است که نگهدارنده پروژه می‌تواند آن را به نقطه دیگری منتقل کند؛ بنابراین هیچ‌کدام از این دو، درختی که بتوانید به آن بازگردید را به‌طور دقیق مشخص نمی‌کنند. شناسه یک commit هرگز تغییر نمی‌کند. شناسه خود را در کنار سایر اطلاعات سرور یادداشت کنید، زیرا وقتی یک ارتقا باعث خرابی می‌شود، راهکار سریع و ارزان، 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 یا بالاتر را نمایش دهد. بسته Node موجود در مخازن Ubuntu معمولاً قدیمی‌تر از این نسخه است، بنابراین آن را از طریق 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 اضافه کنید و یک نشست (login shell) جدید باز کنید. ابتدا بدانید که این کار چه دسترسی‌هایی می‌دهد: عضویت در docker معادل دسترسی root روی ماشین است، زیرا هر کسی در این گروه می‌تواند containerای را اجرا کند که فایل‌سیستم میزبان را mount می‌کند.

پیکربندی .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 مقادیر پیش‌فرض (placeholder) را خارج از محیط توسعه نمی‌پذیرد؛ بنابراین یک استقرار نیمه‌پیکربندی‌شده به جای اجرا با یک رمز عبور منتشرشده در مخزن، با خطا متوقف می‌شود.

openssl rand -base64 48
openssl rand -hex 32

سپس دیتابیس را به‌صورت مستقل بالا بیاورید و migrationها را اجرا کنید.

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 تصویر (image) رایانه بات را که در package.json با نام docker build -t rakazo/computer:local infra/sandboxes/computer تعریف شده است، می‌سازد. این یک تصویر گرافیکی است، بنابراین اولین build حجم زیادی را دانلود می‌کند و زمان‌بر است. با استفاده از docker image ls rakazo/computer تأیید کنید که تصویر ایجاد شده است؛ این دستور باید یک ردیف خروجی داشته باشد.

فایل compose، دیتابیس Postgres را روی 127.0.0.1:5433:5432 منتشر می‌کند که فقط برای loopback در دسترس است. آن را به همین شکل رها کنید. اعتبارنامه‌های محیط توسعه rakazo:rakazo هستند که در مخزن موجودند؛ پورت Postgres که از طریق اینترنت با رمز عبور منتشرشده در دسترس باشد، ظرف چند ساعت توسط اسکنرها شناسایی می‌شود. فایل compose محیط عملیاتی (production) به جای آن POSTGRES_PASSWORD را می‌خواند، بنابراین وقتی به آن مرحله رسیدید، آن را روی یک رشته تصادفی تنظیم کنید.

اجرای اولیه

pnpm dev

این دستور چهار مورد را راه‌اندازی می‌کند: API روی پورت 3100، پردازشگر Graphile Worker، اپلیکیشن وب Vite روی پورت 5173 و ناظر محیط sandbox روی پورت 7091. اپلیکیشن در آدرس http://127.0.0.1:5173 در دسترس است و باید صفحه ورود را مشاهده کنید.

روی یک VPS شما پشت آن دستگاه نیستید و نباید پورت 5173 را برای دسترسی عمومی منتشر کنید. به‌جای آن، پورت‌ها را از طریق SSH (پوسته امن) از دستگاه خودتان فوروارد کنید.

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

به تفاوت بین این دو روش اجرا دقت کنید. دستور pnpm dev برنامه Vite را روی میزبان اجرا می‌کند و آن را به صورت محلی bind می‌کند. سرویس web در فایل compose، پورت 5173:5173 را روی تمام اینترفیس‌ها منتشر می‌کند. اگر کل stack توسعه را روی یک VPS عمومی بالا بیاورید، اپلیکیشن در معرض دسترسی عمومی قرار می‌گیرد؛ بنابراین برای هر چیزی که قصد دارید به صورت دائم اجرا شود، از فایل production و reverse proxy مربوط به آن استفاده کنید.

کدام ارائه‌دهنده sandbox روی سرور امن است؟

این تنها تنظیمی است که باید به‌درستی انجام شود. SANDBOX_PROVIDER در .env چهار مقدار می‌پذیرد.

• docker مقدار پیش‌فرض است. هر بات کانتینر مخصوص به خود را روی ماشین شما دریافت می‌کند که از ایمیج تولیدشده توسط pnpm sandbox:build ساخته شده است. این سریع‌ترین روش برای راه‌اندازی self-hosted است.
• e2b کامپیوترهای بات را روی E2B اجرا می‌کند و به E2B_API_KEY نیاز دارد. این پروژه استفاده از آن را برای استقرار عمومی یا چندکاربره توصیه می‌کند، زیرا کامپیوترهای بات را از میزبانی که API و دیتابیس شما روی آن اجرا می‌شود، جدا نگه می‌دارد.
• desktop دستورات بات را مستقیماً روی میزبان API و worker اجرا می‌کند. دستورالعمل مخزن صریح است: از آن روی سرور عمومی یا اشتراکی استفاده نکنید.
• fake یک شبیه‌ساز درون‌پردازشی (in-process) برای تست است. این یک محیط اجرا (runtime) نیست.

هشدار مربوط به desktop را جدی بگیرید. در حالت desktop هیچ مرز ایزولاسیونی وجود ندارد، بنابراین بات دستورات shell را با کاربری که پروسه API را اجرا می‌کند، اجرا خواهد کرد؛ با همان دایرکتوری home، همان کلیدهای SSH، همان اعتبارنامه‌های ابری و همان .env آن کاربر. متنی که در یک صفحه وب توسط بات خوانده می‌شود، به دستوری روی سرور شما تبدیل خواهد شد. استفاده از حالت desktop روی سرور باعث می‌شود بات به اعتبارنامه‌های شما دسترسی پیدا کند. از این حالت فقط روی ماشینی استفاده کنید که پشت آن نشسته‌اید، یا اصلاً از آن استفاده نکنید.

docker یک مرز واقعی است، اما مرزی ناقص. یک بات نمی‌تواند فایل‌های بات دیگر را بخواند، زیرا هر کدام کانتینر خود را دارند. با این حال، supervisor که این کانتینرها را ایجاد می‌کند، /var/run/docker.sock را mount می‌کند و کنترل بر Docker socket میزبان به معنای کنترل بر کل میزبان است. بنابراین supervisor را خصوصی نگه دارید. .env.example، مقدار SANDBOX_SUPERVISOR_TOKEN را به‌عنوان یک اعتبارنامه سرویس جداگانه و اختیاری مستند کرده است که در صورت خالی بودن به‌طور پیش‌فرض BETTER_AUTH_SECRET در نظر گرفته می‌شود؛ این یعنی باقی گذاشتن آن secret در حالت پیش‌فرض، سرویس ایجادکننده کانتینر را با رشته‌ای محافظت می‌کند که هر کسی در GitHub می‌تواند آن را بخواند. هر دو مقدار را تنظیم کنید. برای قوی‌ترین جداسازی ممکن در اینجا، از e2b استفاده کنید یا به Rakazo ماشینی بدهید که هیچ چیز دیگری روی آن نباشد. این همان منطقی است که پشت اجرای ایجنت‌های برنامه‌نویسی در یک VM یک‌بارمصرف وجود دارد: ارزان‌ترین راه برای نجات از اشتباه یک ایجنت این است که ماشینی که روی آن اجرا می‌شود، فاقد هرگونه ارزش یا داده حساس باشد.

کلیدهای API مدل کجا قرار می‌گیرند؟

Rakazo هیچ سیستم مدیریت صورت‌حساب برای مدل‌ها ندارد. شما باید کلید خود را ارائه دهید. .env.example مقدار PI_DEFAULT_PROVIDER=openrouter را تنظیم می‌کند، بنابراین OPENROUTER_API_KEY مکان معمول برای این کار است و کلیدهای ارائه‌دهندگان مختلف نیز از طریق همین تنظیمات کار می‌کنند.

کلید را در .env نگه دارید و آن را در هیچ فایلی که commit می‌کنید قرار ندهید. هر دو دستور compose در مخزن، --env-file .env را پاس می‌دهند، بنابراین مقادیر بدون اینکه در فایل‌های YAML که توسط git ردیابی می‌شوند نوشته شوند، به containerها می‌رسند. همچنین می‌توانید OPENROUTER_API_KEY را خالی بگذارید و کلید را در طول مرحله onboarding در برنامه وارد کنید؛ این یکی دیگر از دلایلی است که ENCRYPTION_KEY باید یک مقدار تصادفی واقعی داشته باشد و نه مقدار پیش‌فرض اولیه.

پیش از آنکه رباتی از کلید استفاده کند، یک سقف هزینه (spending limit) برای آن در پنل ارائه‌دهنده تنظیم کنید. رباتی که در حلقه بیفتد، رباتی است که هزینه ایجاد می‌کند، و محدودیت در سطح کلید تنها راه توقفی است که به نظارت لحظه‌ای شما وابسته نیست. برای این کلید یک نام اختصاصی انتخاب کنید تا بتوانید در صورت نیاز، فقط همان کلید را ابطال کنید.

انتقال از حالت توسعه به محیط عملیاتی

این مخزن شامل یک فایل compose برای محیط عملیاتی است که Postgres، API، worker، برنامه وب و Caddy را برای گواهی‌های TLS (امنیت لایه انتقال) که به‌طور خودکار دریافت می‌شوند، اجرا می‌کند. این تنظیمات برای ربات‌ها به 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 را غیرفعال می‌کند، قوانین UFW (فایروال ساده) را برای SSH، HTTP و HTTPS تنظیم می‌کند، fail2ban را فعال کرده و پروفایل‌های AppArmor را اعمال می‌کند. پیش از اجرا، آن را مطالعه کنید، زیرا نحوه ورود شما به سیستم را تغییر می‌دهد. هنگام اجرای آن، یک نشست SSH دوم باز نگه دارید.

فایل .env عملیاتی به تنظیمات بیشتری نسبت به نسخه توسعه نیاز دارد. مستندات 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، یک رکورد A به سمت سرور تنظیم کنید. Caddy برای نام موجود در RAKAZO_HOST درخواست گواهی می‌دهد و اگر نام دامنه به این سرور اشاره نکند یا پورت 80 برای دسترسی خارجی بسته باشد، درخواست با شکست مواجه می‌شود.

همچنین SIGNUP_ALLOWLIST=you@example.com را تنظیم کنید. مقدار پیش‌فرض SIGNUPS_ENABLED=true است، بنابراین یک نمونه (instance) روی دامنه عمومی، ثبت‌نام هر کسی که آن را پیدا کند می‌پذیرد و هر حساب جدید یک کامپیوتر دریافت می‌کند. ابتدا از لیست مجاز (allowlist) استفاده کنید و در صورت تمایل، بعداً محدودیت‌ها را کاهش دهید.

فایل docs/self-host.md موجود در مخزن را به عنوان مرجع تنظیمات عملیاتی در نظر بگیرید، زیرا این فایل همگام با کد تغییر می‌کند و این راهنما ممکن است به‌روز نباشد. از آنجا که Compose وظیفه اجرا را بر عهده دارد، قوانین معمول اعمال می‌شوند و اصول اولیه Docker Compose برای VPS توضیح می‌دهد که چرا --env-file و volumeهای نام‌گذاری‌شده، زمانی که یک stack را برای ماه‌ها به حال خود رها می‌کنید، اهمیت بیشتری پیدا می‌کنند.

پشتیبان‌گیری

پایگاه‌داده Postgres و دایرکتوری data/ تمام اجزای این نمونه (instance) را تشکیل می‌دهند.

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

ابزار backup.sh از Postgres خروجی (dump) تهیه کرده و data/ را آرشیو می‌کند. برای ماشینی که به آن وابستگی دارید، infra/compose/backup-prod.sh را به عنوان /usr/local/sbin/rakazo-backup و با استفاده از تایمری که در مخزن ارائه شده است نصب کنید تا چرخش (rotation) فایل‌ها بدون دخالت شما انجام شود. پشتیبان‌گیری که روی همان دیسکِ پایگاه‌داده قرار داشته باشد، پشتیبان محسوب نمی‌شود؛ بنابراین آن را به خارج از سرور منتقل کنید. سپس پیش از آنکه به آن نیاز پیدا کنید، یک‌بار عملیات بازیابی (restore) را روی یک سرور یدکی تست کنید.

چرا عملیات با شکست مواجه می‌شود و چه چیزی مشاهده خواهید کرد

pnpm db:migrate نمی‌تواند به دیتابیس متصل شود. عملیات migration گزارش می‌دهد که قادر به برقراری ارتباط با سرور دیتابیس در 127.0.0.1:5433 نیست. یا کانتینر Postgres بالا نیامده است، یا بالا آمده اما هنوز آماده نیست. دستور docker compose --env-file .env -f infra/compose/docker-compose.yml ps را اجرا کنید و بررسی کنید که آیا سرویس postgres وضعیت healthy را گزارش می‌دهد یا خیر؛ چرا که فایل compose یک health check دارد که هر 3 ثانیه اجرا می‌شود. کانتینری که در یک حلقه مدام restart می‌شود، معمولاً به این معنی است که volume مربوط به pgdata با اعتبارنامه‌های متفاوتی ایجاد شده است. دستور docker compose ... down -v آن را پاکسازی می‌کند و داده‌ها نیز همراه با آن حذف می‌شوند.

پورت از قبل اشغال شده است. بالا آوردن Postgres با خطای bind: address already in use شکست می‌خورد، زمانی که سرویس دیگری پورت 5433 را اشغال کرده باشد؛ این اتفاق معمولاً به دلیل یک stack قدیمی از Rakazo رخ می‌دهد که فراموش کرده‌اید آن را متوقف کنید. دستور sudo ss -lntp | grep 5433 نام آن پردازش را مشخص می‌کند.

یک بات هرگز به کامپیوتر دسترسی پیدا نمی‌کند. با وجود SANDBOX_PROVIDER=docker و نبود image برای rakazo/computer:local، چیزی برای اجرا وجود ندارد. دستور docker image ls rakazo/computer این موضوع را در یک خط پاسخ می‌دهد و pnpm sandbox:build آن را اصلاح می‌کند. اگر supervisor نتواند به Docker socket دسترسی پیدا کند، نمی‌تواند کانتینرها را ایجاد کند و پیام خطا مسیر مربوطه را ذکر می‌کند: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock.

یک دستور طولانی در میانه راه متوقف می‌شود. مقدار .env.example تنظیم‌کننده SANDBOX_COMMAND_TIMEOUT_MS=300000 است، بنابراین یک دستور واحد در داخل کامپیوتر بات پس از 5 دقیقه قطع می‌شود. برای buildهای طولانی، این مقدار را افزایش دهید و فرض را بر crash کردن sandbox نگذارید.

pnpm install به روش‌های گیج‌کننده‌ای دچار اختلال می‌شود. پیش از هر چیز node -v را بررسی کنید. فضای کاری (workspace) مقدار >=22 را اعلام می‌کند و نسخه‌های قدیمی Node معمولاً به جای نمایش پیام خطا درباره نسخه، در کدهای dependency دچار شکست می‌شوند.

ورود به سیستم در حالت محلی کار می‌کند اما از طریق دامنه خیر. مقادیر BETTER_AUTH_URL، WEB_ORIGIN و API_URL همگی باید دارای همان public origin موجود در نوار آدرس باشند، که شامل scheme نیز می‌شود. وجود یک http://127.0.0.1:5173 قدیمی در یکی از این موارد، دلیل معمول برای نشست‌هایی (session) است که هرگز پایدار نمی‌مانند.

به‌روزرسانی یک checkout ثابت‌شده (pinned)

مسیر ارتقا در مستندات self-host کوتاه است: سورس جدید را pull کنید، 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

ابتدا نسخه پشتیبان تهیه کنید. Migrationها فقط رو به جلو حرکت می‌کنند و در نسخه بتا، مسیر بازگشتی که بتوان به آن اطمینان کرد وجود ندارد. پیش از اعمال تغییرات، commitهای بین SHA ثابت‌شده فعلی و SHA جدید را مطالعه کنید؛ چرا که پروژه‌ای به این نوپایی ممکن است متغیرهای محیطی (environment variables) را بدون اطلاع‌رسانی قبلی تغییر نام دهد. فقدان یک متغیر باعث می‌شود سرویس پس از شروع، بلافاصله متوقف (exit) شود. اگر هنوز در حال تصمیم‌گیری هستید که آیا Rakazo گزینه مناسبی برای اجرا است یا خیر، بررسی جامع عامل‌های هوش مصنوعی self-hosted گزینه‌های دیگر در این دسته‌بندی و هزینه‌های نگهداری هر کدام را پوشش می‌دهد.

FAQ

Can I run Rakazo on a 1 GB VPS?

No. Postgres, the API, the worker, the sandbox supervisor and the web app all run at the same time, and with SANDBOX_PROVIDER=docker every awake bot adds a container holding a graphical desktop and a browser. The project's own doc calls 2 vCPU and 4 GB enough for the API, worker and Postgres only when E2B hosts the bot desktops. Treat 4 GB as the floor for the control plane, and go higher when the desktops run on your machine.

Is the desktop sandbox provider safe on a server?

No. desktop runs the bot's commands directly on the API and worker host, as the user running that process, with that user's files and credentials in reach. The repository says not to use it on a public or shared server. Use docker for a container per bot, or e2b when more than one person signs in.

Which version of Rakazo should I install?

As of 16 August 2026 there is one tag, v0.1.0-beta, published 13 August 2026 and marked a prerelease. Check out the commit it points at, 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb, rather than tracking main. A branch moves under you and a tag can be repointed, so neither identifies a tree you can return to. Record the commit, because rolling back is only possible when you know which one worked.

Where do I put my OpenRouter API key?

In .env as OPENROUTER_API_KEY, and never in a compose file you commit. Both compose commands in the repository pass --env-file .env, so the value reaches the containers without being written into tracked YAML. You can also leave it empty and paste the key in the app during onboarding. Set a spending limit on the key at the provider, because a bot in a loop keeps calling the model until something stops it.

Do I need a domain name and TLS?

For anything past a first test, yes. The production compose file runs Caddy and obtains certificates automatically, and RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN and API_URL must all carry the same public HTTPS origin. For a first look you can skip the domain: run pnpm dev and forward port 5173 over SSH instead of publishing it.