استضافة Rakazo ذاتياً على VPS خطوة بخطوة

ما الذي يشغّله Rakazo فعلياً عند الاستضافة الذاتية

تعني الاستضافة الذاتية لـRakazo تشغيل خمسة مكوّنات على خادم Linux واحد: PostgreSQL، وعملية Graphile Worker، وواجهة API، وتطبيق الويب، وحاوية sandbox واحدة لكل bot نشط. Rakazo بديل مفتوح المصدر لـGrok Bot، نشره elie222 بموجب ترخيص Apache 2.0. يحصل كل bot على thread خاص به، وحاسوب خاص به، وذاكرة خاصة به، وسجل خاص به. ويمكنه إنشاء نظراء أو subagents قصيرة العمر. إذا كانت كلمات مثل memory وsubagent وtool call تؤدي معنى غير مألوف في هذه الجملة، فمن المفيد أن تقرأ أولاً مساراً تدريجياً لفهم طريقة عمل agents فعلياً خلال فترة بعد الظهر، لأن معظم الإعدادات أدناه لا تصبح مفهومة إلا عندما تتصور ما الذي يفعله bot عند استيقاظه.

ولهذا السبب تحديداً يجب تشغيله على VPS (خادم خاص افتراضي)، وليس على جهاز مكتبي. يحتاج bot الذي يحتفظ بالذاكرة وينفّذ المهام المجدولة إلى أن يكون قابلاً للوصول أثناء نومك. عندما يدخل الحاسوب المحمول في وضع السكون، يتوقف الطابور.

ما يزال Rakazo في مرحلة beta المبكرة اعتباراً من August 2026، لذلك تعامل مع هذا الإعداد باعتباره إعداداً عملياً، لا appliance مكتملة. تعتمد المكدسة بالكامل على TypeScript: React 19 وVite لتطبيق الويب، وHono لواجهة API، وPostgres مع Prisma، وBetter Auth للحسابات، وGraphile Worker للمهام الخلفية. يخزّن Graphile Worker طابوره داخل Postgres، لذلك لا تحتاج إلى تشغيل Redis أو مخزن بيانات ثانٍ. يحدّد .env.example قيمة WAKEUP_DRIVER=graphile، ما يعني أن استيقاظ bot هو job مدعوم من Postgres. أوقف Postgres، وستتوقف معه كل إجراءات bot المجدولة. إذا كنت تفضّل تجميع agent من مكوّنات بدلاً من تشغيل منتج أنشأه طرف آخر، فالمسار الآخر هو بناء agent الخاص بك من المكوّنات.

لماذا لن تتحمل هذه المنظومة خطة بسعة 1 GB

احسب العمليات. Postgres عملية واحدة. وواجهة API هي عملية Node. والعامل عملية ثانية. وتطبيق الويب عملية ثالثة. ومشرف الـsandbox عملية رابعة. بعد ذلك، يحصل كل bot قيد التشغيل على حاوية تحتوي على سطح مكتب Linux رسومي ومتصفح.

تذكر وثيقة الاستضافة الذاتية للمشروع رقماً واقعياً واحداً: تكفي آلة بسعة 2 vCPU و4 GB لتشغيل API والعامل وPostgres عندما تتولى E2B استضافة أسطح مكتب bots. وهذا الرقم يخص طبقة التحكم وحدها، بينما يستضيف طرف آخر الجزء الأثقل. عند ضبط SANDBOX_PROVIDER=docker، تنتقل أسطح المكتب هذه إلى VPS لديك، ولذلك تصبح سعة 4 GB حداً أدنى بدلاً من أن تكون هدفاً. ابدأ بسعة 8 GB إذا كنت تخطط لإبقاء أكثر من bot واحد قيد التشغيل، وقِس الاستهلاك الفعلي باستخدام docker stats أثناء عمل bot. المتصفح داخل الـsandbox هو العامل الذي يرفع استهلاك الذاكرة، لذلك لن تخبرك ورقة المواصفات بالاستهلاك الفعلي. لمعرفة الطريقة العامة لتحديد حجم خادم لأعمال الوكلاء، يشرح مقدار RAM وCPU الذي يحتاجه VPS الخاص بالوكيل فعلياً عملية القياس بالتفصيل.

يمنع إعداد واحد تفاقم هذا الوضع. يوفّر .env.example الإعداد SANDBOX_IDLE_MS=600000 مع تعليق يفيد بأنه يوقف أجهزة E2B، أو يوقف أجهزة Docker، بعد مرور عدد المللي ثانية المحدد من الخمول. بعد 10 دقائق من الخمول، يختفي الجهاز. القيمة الدنيا المقبولة هي 30000. من دون هذا الإعداد، سيحتفظ كل bot فتحته بالذاكرة إلى الأبد.

تؤثر مساحة القرص أيضاً. تشترك صورة الـsandbox ووحدات Node ووحدة تخزين Postgres في قرص واحد، لذلك تُعد سعة 40 GB نقطة بداية مناسبة.

ثبّت إصداراً قبل استنساخ المستودع

يتطور Rakazo بسرعة، وmain ليس إصداراً. في 16 August 2026، يحتوي المستودع على وسم واحد فقط هو v0.1.0-beta، وقد نُشر في 13 August 2026 ووُسِم بأنه إصدار تجريبي.

git clone https://github.com/elie222/rakazo.git
cd rakazo
git checkout 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb
git log -1 --format='%H %ci'

هذا هو الـcommit الذي يشير إليه v0.1.0-beta. ثبّت الـcommit بدلاً من تثبيت الـbranch أو الـtag. يتغير الـbranch في عملية git pull التالية، بينما الـtag تسمية قابلة للتغيير ويمكن للمشرف إعادة توجيهها، لذلك لا يحدد أيٌّ منهما شجرة يمكنك العودة إليها. أما معرّف الـcommit فلا يمكن تغييره. دوّن معرّفك بجانب معلومات خادمك الأخرى، لأن الحل السريع عند تعطل الترقية هو git checkout <old commit> وإعادة البناء، وهذا لا ينجح إلا إذا كنت تعرف أيّ commit كان يعمل. يُعد التثبيت بهذه الدقة تكلفة مرحلة beta، وليس قاعدة عامة. ويمكن بدلاً من ذلك تثبيت المشروع الذي يصدر إصدارات مدروسة عند tag منشور، وهذا ما يفعله مكدس أصغر مستضاف ذاتياً مثل openGym.

المتطلبات: 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 مع Node عبر corepack:

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، الذي يجب أن يطبع صفاً واحداً.

ينشر ملف Compose خادوم Postgres على 127.0.0.1:5433:5432، وهو مقيّد بحلقة الاسترجاع المحلية فقط. اتركه بهذه الطريقة. بيانات اعتماد التطوير هي rakazo:rakazo، وهي موجودة في المستودع، كما أن منفذ Postgres المتاح من الإنترنت مع كلمة مرور منشورة ستكتشفه أدوات المسح خلال ساعات. يقرأ ملف Compose الخاص بالإنتاج POSTGRES_PASSWORD بدلاً من ذلك، لذا عيّن له سلسلة عشوائية عند الوصول إلى تلك المرحلة.

التشغيل الأول

pnpm dev

يبدأ ذلك أربعة مكونات: واجهة API على المنفذ 3100، وGraphile Worker، وتطبيق الويب Vite على المنفذ 5173، ومشرف sandbox على المنفذ 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 على المضيف مع ربطه محلياً. وتنشر خدمة web في ملف compose المنفذ 5173:5173 على جميع الواجهات. إذا شغّلت مكدس compose الكامل للتطوير على VPS عام، فسيصبح التطبيق مكشوفاً. لذلك استخدم ملف الإنتاج وReverse Proxy الخاص به لأي مكونات تتركها قيد التشغيل.

أي مزوّد بيئة معزولة آمن على الخادم؟

هذا هو الإعداد الوحيد الذي يجب ضبطه بشكل صحيح. يأخذ SANDBOX_PROVIDER في .env أربع قيم.

• docker هو الإعداد الافتراضي. يحصل كل bot على حاوية خاصة به على جهازك، وتُنشأ من الصورة التي ينتجها pnpm sandbox:build. هذا أسرع إعداد للاستضافة الذاتية.
• e2b يشغّل أجهزة bot على E2B ويتطلب E2B_API_KEY. يوصي المشروع به لعمليات النشر العامة أو متعددة المستخدمين، لأنه يفصل أجهزة bot عن المضيف الذي يشغّل API وقاعدة البيانات.
• desktop يشغّل أوامر bot مباشرة على مضيف API وworker. تعليمات المستودع واضحة: لا تستخدمه على خادم عام أو مشترك.
• fake محاكي داخل العملية للاختبارات. وليس بيئة تشغيل.

خذ تحذير وضع سطح المكتب حرفياً. في وضع سطح المكتب لا توجد أي حدود للعزل، لذلك ينفّذ bot أوامر shell بصلاحيات المستخدم الذي يشغّل عملية API، مع الدليل المنزلي لذلك المستخدم، ومفاتيح SSH الخاصة به، وبيانات اعتماد السحابة الخاصة به، و.env الخاص به. يتحول النص الموجود في صفحة ويب يقرأها bot إلى أمر على خادمك. استخدام وضع سطح المكتب على خادم هو الطريقة التي ينتهي بها الأمر إلى امتلاك bot لبيانات اعتمادك. استخدمه على جهاز تجلس أمامه، أو لا تستخدمه إطلاقاً. يؤدي تبديل المزوّد إلى وضع حاوية حول مسار صفحة الويب، لكنه لا يغلقه، كما أن منح bot واجهة بحث SearXNG خاصة به يغطي سطح الحقن نفسه من جهة البحث.

docker حد فاصل حقيقي، لكنه غير كامل. لا يستطيع bot قراءة ملفات bot آخر، لأن لكل منهما حاويته الخاصة. لكن المشرف الذي ينشئ تلك الحاويات يربط /var/run/docker.sock، والتحكم في Docker socket الخاص بالمضيف يعني التحكم في المضيف. لذلك أبقِ المشرف خاصاً. يوثّق .env.example أن SANDBOX_SUPERVISOR_TOKEN هو بيانات اعتماد اختيارية لخدمة منفصلة، وتصبح قيمته الافتراضية BETTER_AUTH_SECRET عندما تكون فارغة، ما يعني أن ترك هذا السر على قيمته النائبة يحمي الخدمة التي تنشئ الحاويات بسلسلة يستطيع أي شخص قراءتها على GitHub. اضبط القيمتين معاً. للحصول على أقوى فصل متاح هنا، استخدم e2b، أو خصّص لـRakazo جهازاً لا يحتوي على أي شيء آخر. وهذا هو المنطق نفسه وراء تشغيل وكلاء البرمجة في VM مؤقتة: أرخص طريقة للتعامل مع تنفيذ وكيل لشيء خاطئ هي أن تكون قيمة جهازه معدومة.

أين توضع مفاتيح API الخاصة بالنماذج؟

لا يدير Rakazo فوترة النماذج. يجب أن توفّر المفتاح بنفسك. يضبط .env.example قيمة PI_DEFAULT_PROVIDER=openrouter، لذلك يكون OPENROUTER_API_KEY هو المكان المعتاد، وتعمل مفاتيح موفّري الخدمة عبر الإعداد نفسه.

احتفظ بالمفتاح في .env، ولا تضعه في أي ملف تلتزم به في المستودع. يمرّر كلا أمري compose في المستودع قيمة --env-file .env، لذلك تصل القيم إلى الحاويات من دون كتابتها في ملفات YAML التي يتتبعها git. يمكنك أيضاً ترك OPENROUTER_API_KEY فارغاً ولصق مفتاح في التطبيق أثناء الإعداد الأولي. وهذا سبب إضافي يجعل ENCRYPTION_KEY يحتاج إلى قيمة عشوائية حقيقية بدلاً من القيمة النائبة المضمّنة.

ضع حداً للإنفاق على المفتاح لدى موفّر الخدمة قبل أن يستخدمه أي bot. إذا دخل bot في حلقة تكرار، فسوف يواصل الإنفاق. والحد المخصص لكل مفتاح هو الإجراء الوحيد الذي لا يعتمد على مراقبتك. امنح هذا المفتاح اسماً خاصاً حتى تتمكن من إبطاله وحده. إذا كنت تعدّ هذا الإعداد لفريق لا لك وحدك، فإن بوابة OneCLI واحدة أمام agent الخاص بالجميع تمثل حلاً مختلفاً للمشكلة نفسها، لأنها تحتفظ بمفاتيح موفّري الخدمة في مكان واحد بدلاً من إنشاء مفتاح لكل شخص.

الانتقال من وضع التطوير إلى إعداد يمكنك تركه قيد التشغيل

يأتي المستودع مع ملف Compose للإنتاج يشغّل Postgres وواجهة API والعامل وتطبيق الويب و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 الخاص بالإنتاج إعدادات أكثر من إعداد التطوير. وتعرض وثيقة الاستضافة الذاتية الحد الأدنى المطلوب.

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

وجّه سجل A إلى الخادم قبل تشغيل up لأول مرة. يطلب Caddy شهادة للاسم الموجود في RAKAZO_HOST، ويفشل الطلب إذا لم يُحلّ الاسم إلى هذا الخادم أو إذا كان المنفذ 80 مغلقاً أمام الاتصالات الخارجية.

اضبط SIGNUP_ALLOWLIST=you@example.com أيضاً. القيمة الافتراضية لـSIGNUPS_ENABLED=true، ولذلك يقبل المثيل الموجود على اسم عام التسجيلات من أي شخص يعثر عليه، ويحصل كل حساب جديد على جهاز كمبيوتر. أضف قائمة السماح أولاً. ويمكنك تخفيف هذا القيد لاحقاً إذا أردت. إذا كنت تشغّل عدة خدمات على الخادم نفسه وتفضّل الاحتفاظ بقائمة واحدة للأشخاص بدلاً من قائمة سماح لكل تطبيق، فإن وضع مثيل Authentik أمامها ينقل هذا القرار إلى الـproxy، لكنه يبقى أمام حسابات Better Auth الخاصة بـRakazo ولا يستبدلها.

اعتبر docs/self-host.md في المستودع المرجع المعتمد لإعدادات الإنتاج، لأنه يتغير مع تغيّر الشيفرة بينما لا يتغير هذا الدليل. وبما أن Compose يتولى التشغيل، تنطبق القواعد المعتادة، وتوضح أساسيات Docker Compose لخادم 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 هذه الوحدة، ويحذف البيانات الموجودة فيها أيضاً.

المنفذ مستخدم بالفعل. يفشل تشغيل 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 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، ولذلك يُوقَف أمر واحد داخل حاسوب البوت بعد خمس دقائق. ارفع هذه القيمة عند تنفيذ عمليات بناء بطيئة، بدلاً من افتراض تعطل الـsandbox.

يتعطل pnpm install بطرق مربكة. افحص node -v أولاً. يعلن workspace عن >=22، بينما يفشل إصدار Node الأقدم داخل كود التبعيات بدلاً من عرض رسالة توضّح مشكلة الإصدارات.

يعمل تسجيل الدخول محلياً، لكنه لا يعمل عبر النطاق. يجب أن تتطابق BETTER_AUTH_URL وWEB_ORIGIN وAPI_URL مع الأصل العام الظاهر في شريط العنوان، بما في ذلك scheme. ويكون وجود http://127.0.0.1:5173 قديم في أحدها هو السبب المعتاد لبقاء الجلسة غير مستقرة.

تحديث نسخة checkout المثبّتة

مسار الترقية في مستند الاستضافة الذاتية مختصر: اسحب المصدر الجديد، وشغّل ترحيل قاعدة البيانات، ثم أعد تشغيل API وworker.

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

أنشئ نسخة احتياطية أولاً. تتحرك عمليات الترحيل إلى الأمام، ولا يوفّر لك الإصدار التجريبي مسار تراجع موثوقاً. اقرأ commits بين SHA المثبّت وSHA الجديد قبل تطبيقها، لأن مشروعاً حديثاً إلى هذا الحد قد يعيد تسمية متغيرات البيئة من دون إعلان، ويظهر المتغير المفقود على شكل خدمة تبدأ ثم تتوقف. إذا كنت لا تزال تقرر ما إذا كان Rakazo مناسباً للتشغيل أصلاً، فستجد في المقارنة بين وكلاء الذكاء الاصطناعي المستضافين ذاتياً ما يقع ضمن هذه الفئة أيضاً، وما تتطلبه المحافظة على تشغيل كل واحد منها.

FAQ

هل يمكنني تشغيل Rakazo على VPS بسعة 1 GB؟

لا. تعمل Postgres وواجهة API والعامل والمشرف على sandbox والتطبيق الويب في الوقت نفسه. ومع SANDBOX_PROVIDER=docker، يضيف كل bot نشط حاوية تحتوي على سطح مكتب رسومي ومتصفح. توضح وثائق المشروع أن 2 vCPU و4 GB تكفي لواجهة API والعامل وPostgres فقط عندما يستضيف E2B أسطح مكاتب bots. اعتبر 4 GB الحد الأدنى لطائرة التحكم، وزد السعة عندما تعمل أسطح المكاتب على جهازك.

هل موفّر sandbox لسطح المكتب آمن على خادم؟

لا. يشغّل desktop أوامر bot مباشرة على الخادم الذي يستضيف API والعامل، وبحساب المستخدم الذي يشغّل العملية، مع إمكانية الوصول إلى ملفات ذلك المستخدم وبيانات اعتماده. ينص المستودع على عدم استخدامه على خادم عام أو مشترك. استخدم docker لتشغيل حاوية لكل bot، أو e2b عندما يسجّل أكثر من شخص الدخول.

ما إصدار Rakazo الذي ينبغي تثبيته؟

اعتباراً من 16 August 2026، يوجد tag واحد هو v0.1.0-beta، وقد نُشر في 13 August 2026 ووُسِم بأنه prerelease. نفّذ checkout للـcommit الذي يشير إليه، وهو 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb، بدلاً من تتبّع main. يمكن أن يتغير branch أثناء استخدامك له، ويمكن إعادة توجيه tag، لذلك لا يحدد أي منهما شجرة يمكنك العودة إليها. سجّل commit، لأن التراجع إلى إصدار سابق ممكن فقط عندما تعرف أي commit كان يعمل.

أين أضع مفتاح OpenRouter API؟

ضعه في .env بالقيمة OPENROUTER_API_KEY، ولا تضعه مطلقاً في ملف compose تلتزم به في المستودع. يمرّر أمرا compose في المستودع --env-file .env، لذلك تصل القيمة إلى الحاويات من دون كتابتها في ملفات YAML المتتبعة. يمكنك أيضاً تركه فارغاً ولصق المفتاح في التطبيق أثناء الإعداد الأولي. ضع حداً للإنفاق على المفتاح لدى الموفّر، لأن bot العالق في حلقة سيواصل استدعاء النموذج حتى يوقفه شيء ما.

هل أحتاج إلى اسم نطاق وTLS؟

نعم، لأي استخدام يتجاوز الاختبار الأولي. يشغّل ملف compose للإنتاج Caddy ويحصل على الشهادات تلقائياً، ويجب أن تحمل RAKAZO_HOST وBETTER_AUTH_URL وWEB_ORIGIN وAPI_URL جميعاً نفس عنوان HTTPS العام. ولإجراء اختبار أولي، يمكنك تخطي اسم النطاق: شغّل pnpm dev ومرّر المنفذ 5173 عبر SSH بدلاً من نشره.