استضافة LiveContext ذاتياً كبديل لـ n8n

ما هو LiveContext وما تكلفة تشغيله

لاستضافة LiveContext ذاتياً، تحتاج إلى VPS بذاكرة RAM تبلغ نحو 8 GB. LiveContext CE منصة أتمتة مفتوحة المصدر تشغّل وكلاء الذكاء الاصطناعي داخل منصة الأتمتة نفسها، وتأتي على شكل مكدس Docker Compose يضم ست حاويات مبنية حول واجهة خلفية بلغة Java. يطلب ملف README في المشروع 4 GB كحد أدنى، ويوصي بـ8 GB، ويوضح ملف compose موضع استخدام هذه الذاكرة.

المشروع موجود على livecontext-ai/livecontext-ce في GitHub، ومرخّص بموجب AGPL-3.0. الإصدار الحالي حتى August 2026 هو v0.2.11، وقد نُشر في 3 August 2026. كل صورة مبنية لـlinux/amd64 فقط، ولذلك لا يمكن استخدام خطط Arm الرخيصة. يثبّت هذا الدليل هذه الوسمة، ويضع المكدس خلف reverse proxy، ويشرح إجراء النسخ الاحتياطي الذي لا تتضمنه وثائق المشروع الأصلية.

حدِّد حجم VPS قبل الاستضافة الذاتية لـ LiveContext

تحتوي كل خدمة في ملف Compose المرفق على حد صريح للذاكرة، لذلك يمكنك تحديد مواصفات الخادم قبل استئجاره. هذه هي الحدود المكتوبة في ملف v0.2.11 Compose، وليست قياسات للاستخدام الفعلي.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 1536
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "postgres",
    "memory_limit_mb": 256
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

يُحدَّد حد الواجهة الخلفية وحدها عند 1536 MB. ويُطبَّق هذا الحد على عملية Java 21، لذلك سيستهلك JVM معظم هذه الذاكرة ويبقى قريباً منها. يبلغ مجموع الخدمات الأساسية الخمس أقل بقليل من 3 GB، بينما لا يملك frontend أي حد، ولذلك يستهلك ما يطلبه Node. على VPS بسعة 4 GB، لا يتبقى تقريباً شيء لـkernel وpage cache، ولهذا تُذكر سعة 4 GB كحد أدنى لا كتوصية.

الملفات الاختيارية profiles هي التي ترفع احتياجات الخادم إلى 8 GB. يضيف browser agent profile حاوية Chromium بحد 2048 MB، إلى جانب نسخة بحث SearXNG، بينما يضيف renderer profile مقداراً آخر قدره 1024 MB لمعالجة لقطات الشاشة وملفات PDF. لا تبدأ أي منهما ما لم تفعّل profile الخاص بها، لذلك اتركهما معطّلين حتى تحتاج إليهما. توجد حاوية SearXNG لتكون backend البحث الخاص بالوكيل، ولذلك تصل الصفحات التي تعرضها إلى prompts الخاصة بك على شكل نص غير موثوق، وهذا هو حد الثقة الذي توضحه بالتفصيل إتاحة بحث الويب عبر SearXNG لوكيل AI.

إذا كنت تشغّل n8n بالفعل، فخطط لاستبداله بدلاً من إضافته. يتكوّن الحِمل الوارد في دليلنا لتشغيل n8n على VPS باستخدام Docker وHTTPS من عملية Node واحدة إلى جانب Postgres، ويعمل بشكل مريح على خادم صغير. يحجز LiveContext للواجهة الخلفية وحدها موارد أكبر مما يستهلكه هذا الحِمل بالكامل. سيتسع VPS بسعة 8 GB لمنصتي أتمتة، إلى أن تشغّلا مهمة في الدقيقة نفسها. إذا شاركت المضيف، فضع حدوداً صريحة على كل ما عداه أيضاً، باستخدام الطريقة الواردة في مقالتنا عن ضبط حدود الذاكرة في Docker Compose، حتى لا تؤدي workflow خارجة عن السيطرة إلى تعطيل الجهاز بأكمله.

ثبّت LiveContext باستخدام Docker Compose مع تثبيت الإصدار

ابدأ من VPS يعمل بنظام Ubuntu 24.04 ويحتوي على Docker Engine بالإصدار 24 أو أحدث وCompose v2. إذا لم يكن Docker مثبتاً بعد، فاتبع أولاً دليلنا حول أساسيات Docker Compose لـVPS، ثم عد إلى هنا.

يوفّر README الأمر npx livecontext لبدء التشغيل في سطر واحد. هذا مناسب على حاسوب محمول. أما على الخادم، فمن الأفضل وضع ملف Compose في مجلد تتحكم فيه، لأن الترقية تصبح عندئذ عملية checkout لعلامة git، ويمكنك قراءة التغييرات بدقة.

sudo apt update && sudo apt install -y git
git clone https://github.com/livecontext-ai/livecontext-ce.git
cd livecontext-ce
git tag --list 'v*' | tail -5
git checkout v0.2.11
cp docker/.env.ce.example docker/.env.ce
chmod 600 docker/.env.ce

يحدّد ملف Compose مسبقاً كل صورة باستخدام علامة إصدار، مثل ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. ويضمن checkout لعلامة git المطابقة بقاء ملف Compose والصور متوافقين، لأن ملف Compose الخاص بـv0.2.11 كُتب لهذه الصور. لا تعدّل العلامات إلى latest. يمكن أن تتغير علامة latest دون تنبيهك، ويشغّل backend عمليات ترحيل قاعدة البيانات عند كل بدء تشغيل. لذلك قد يؤدي pull غير مقصود إلى ترحيل المخطط إلى الأمام عند الساعة 3 صباحاً، من دون إمكانية للعودة إلا عبر الاستعادة.

عدّل docker/.env.ce قبل بدء التشغيل الأول، وتوضح الأقسام التالية ما يجب تغييره، ثم شغّل المكدس.

docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce ps

استخدم الخيار --env-file نفسه مع كل أمر Compose في هذا الدليل. يقرأ Compose هذا الملف من جديد عند كل استدعاء، ولذلك يعود الأمر الذي لا يتضمن الخيار إلى الإعدادات الافتراضية المضمّنة في ملف Compose، وقد ينشر منافذ مختلفة عن المنافذ التي ضبطتها.

تبلغ قيمة start_period في فحص صحة backend مدة 120s، ويستعلم الفحص عن /actuator/health. لذلك يعرض docker compose ps خدمة livecontext بالحالة health: starting خلال أول دقيقتين تقريباً، أثناء تشغيل عمليات ترحيل المخطط وتسجيل الأداة. هذا طبيعي. للتحقق سريعاً من الخادم:

curl -s localhost:8080/actuator/health

يجب أن يطبع هذا الأمر {"status":"UP"}. عند ظهور ذلك، افتح واجهة الويب على المنفذ 3000. يصبح الحساب الأول الذي تنشئه حساب admin، لذلك أنشئ حسابك قبل أن يصبح المنفذ متاحاً لأي شخص آخر. وهذا هو السبب الأهم لعدم نشر المنفذ 3000 على الإنترنت منذ اليوم الأول.

القيم الموجودة في env التي يجب تغييرها

يحتوي ملف المثال على قيم افتراضية عاملة، لكي تبدأ المجموعة على جهاز محمول. لكن عدة قيم منها غير آمنة على خادم عام.

POSTGRES_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
GATEWAY_PUBLIC_URL=https://lc-api.example.com

أنشئ كل قيمة عشوائية باستخدام openssl rand -base64 32. انتبه إلى النقاط التالية:

• تأتي POSTGRES_PASSWORD وMINIO_ROOT_PASSWORD افتراضياً بالقيمتين postgres وminioadmin. لا يُنشر أي من منفذي قاعدة البيانات على المضيف، لذلك لا يكونان مكشوفين مباشرة. لكن أي حاوية توصلها لاحقاً بالشبكة نفسها يمكنها الوصول إلى كليهما باستخدام القيمة الافتراضية الموثقة.
• تُنشأ CREDENTIAL_ENCRYPTION_PASSWORD وCREDENTIAL_ENCRYPTION_SALT تلقائياً عند تركهما فارغتين. عيّنهما يدوياً بدلاً من ذلك. تُشفَّر بيانات الاعتماد التي تخزنها عمليات سير العمل باستخدام هاتين القيمتين. لذلك، إذا استعدت تفريغ قاعدة بيانات على جهاز جديد من دون كلمة المرور وsalt نفسيهما، فستحتوي صفوف بيانات الاعتماد على قيم لا يستطيع أي شيء قراءتها. عيّنهما مرة واحدة، ثم اعتبر docker/.env.ce جزءاً من النسخة الاحتياطية.
• تُستبدل FRONTEND_PORT وBACKEND_PORT في تعيينات المنافذ بالقيمتين ${FRONTEND_PORT:-3000}:3000 و${BACKEND_PORT:-8080}:8080. يعيّن ملف env المثال القيمتين صراحةً، والقيم التي يأتي بها ليست دائماً 3000 و8080. اقرأ نسختك من الملف بدلاً من الافتراض.
• GATEWAY_PUBLIC_URL هو origin الذي يراه المتصفح للواجهة الخلفية. وتظهر أهميته فور استخدام reverse proxy. راجع القسم التالي.
• توجد مفاتيح النماذج (ANTHROPIC_API_KEY وOPENAI_API_KEY وGOOGLE_API_KEY، واختيارياً MISTRAL_API_KEY أو DEEPSEEK_API_KEY) هنا بنص واضح. املأ مفاتيح الموفر الذي تستخدمه فعلياً فقط.

ما الذي تفعله الحاويات الست

• postgres يشغّل pgvector/pgvector:pg16 في الحاوية livecontext-db، التي تحتوي على قاعدة البيانات المسماة livecontext. يوجد امتداد pgvector للبحث باستخدام التضمينات، لذلك لن تكفي صورة postgres:16 العادية.
• redis يشغّل redis:7-alpine مع appendonly yes و--maxmemory-policy noeviction. هذه السياسة مقصودة: يحتفظ Redis بحالة قوائم الانتظار والتنفيذ هنا، لذلك يعيد خطأً إلى الكاتب عند بلوغ حد الذاكرة بدلاً من إسقاط المفاتيح بصمت. الخطأ الذي يمكنك رؤيته أفضل من عمل يختفي.
• minio هو مخزن الكائنات المتوافق مع S3 للملفات التي تمر عبر مسارات العمل. تشغّل حاوية minio-init لمرة واحدة mc mb myminio/workflow-files --ignore-existing عند بدء التشغيل، وتنشئ الحاوية ثم تخرج. ظهور minio-init على أنه exited (0) في docker compose ps هو الحالة السليمة.
• bridge يحتوي على محولات CLI وأدوات MCP ‏(بروتوكول سياق النموذج). يستمع على المنفذ 8093 داخل شبكة Docker، ولا يُنشر إلى المضيف.
• livecontext هو الواجهة الخلفية، وهو تطبيق Java 21 متكامل واحد على المنفذ 8080. يشغّل محرك مسارات العمل، والمجدولات، والوكلاء.
• frontend هو واجهة الويب Next.js على المنفذ 3000. تُنشر الحاويتان الأخيرتان فقط إلى المضيف.

توجد الحالة في خمسة مجلدات تخزين مسماة: livecontext_data لـPostgres، وlivecontext_redis وlivecontext_minio وlivecontext_keys وlivecontext_logs. يضيف Compose اسم المشروع إلى أسمائها، ويكون اسم المشروع افتراضياً هو اسم الدليل، لذلك يُسمّى مجلد التخزين الفعلي على القرص اسماً مثل livecontext-ce_livecontext_minio. شغّل docker volume ls وانسخ الأسماء الدقيقة قبل كتابة أي برنامج نصي للنسخ الاحتياطي يعتمد عليها.

docker compose down -v يحذف مجلدات التخزين الخمسة كلها. هذه هي الطريقة الموثقة للبدء من جديد، وهي أيضاً أسرع طريقة لفقدان كل مسار عمل أنشأته. الفرق كله هو -v.

ضعه خلف Traefik بدلاً من نشر المنفذ 3000

يؤدي نشر المنفذين 3000 و8080 على VPS عام إلى تعريض التطبيق دون TLS (أمان طبقة النقل)، ودون بوابة أمام تسجيل حسابات المسؤول. لا تكفي قاعدة ufw وحدها، لأن Docker يضيف قواعد iptables الخاصة به للمنافذ المنشورة قبل السلسلة التي يديرها ufw، لذلك يظل المنفذ المنشور إلى 0.0.0.0 قابلاً للوصول حتى عندما يذكر ufw أن المنفذ مرفوض.

الحل الصحيح هو عدم نشر أي منفذ، والسماح للـproxy بالوصول إلى الحاويات عبر شبكة Docker مشتركة. أنشئ docker-compose.override.yml في جذر المستودع:

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

هناك تفصيلان يحددان نجاح ذلك. يستبدل !override قائمة ports بدلاً من دمجها معها، ويتطلب ذلك Compose v2.24 أو أحدث. تحقق من الإصدار باستخدام docker compose version، لأن القائمتين تندمجان في الإصدارات الأقدم من Compose، وتظل المنافذ منشورة. ويجب أن يبقى default في كل قائمة networks، لأن تسمية أي شبكة تستبدل الشبكة الافتراضية. يؤدي حذفه إلى قطع اتصال الواجهة الأمامية بـPostgres وRedis. أكّد النتيجة المدمجة قبل بدء أي شيء:

docker compose --env-file docker/.env.ce config

تبقى أجهزة التوجيه، ومحلّل الشهادات، وإعادة التوجيه من HTTP إلى HTTPS كما هي في أي تطبيق آخر. لذلك اتبع دليل Traefik للـreverse proxy لتشغيل عدة تطبيقات على VPS واحد بدلاً من كتابة إعداد TLS جديد هنا. وجّه اسم مضيف إلى frontend على المنفذ 3000، واسم مضيف ثانياً إلى livecontext على المنفذ 8080.

اسم المضيف الثاني ليس اختيارياً. تستدعي واجهة الويب الواجهة الخلفية من المتصفح، لذلك تحتاج الواجهة الخلفية إلى origin خاص بها يمكن للمتصفح الوصول إليه. اضبط GATEWAY_PUBLIC_URL في docker/.env.ce على عنوان URL الخاص بالواجهة الخلفية، مثل https://lc-api.example.com. إذا تخطيته، تُحمَّل الصفحة بشكل طبيعي، لكن تفشل كل العمليات، لأن الواجهة تستنتج origin الواجهة الخلفية من العنوان الذي فتحته، ثم تستدعي منفذاً لم ينشره الـproxy.

بما أن صفحة التسجيل مفتوحة لأول من يصل إليها، فمن المفيد تفعيل forward auth على موجّه الواجهة الأمامية، حتى لا يرى أحد تلك الصفحة من دون المصادقة لدى الـproxy. وهذا ما يضيفه تشغيل Authentik كطبقة SSO خاصة بك إلى إعداد Traefik نفسه.

موضع مفتاح النموذج، ولماذا تظل النسخة غير النشطة تكلّف مالاً

تعمل الوكلاء داخل نظام الأتمتة هنا، وهذا يغيّر الاقتصاديات مقارنةً بأداة سير عمل عادية. يوجد مفتاح المزوّد في docker/.env.ce بصيغة ANTHROPIC_API_KEY أو OPENAI_API_KEY. يقرأه كل من الواجهة الخلفية والجسر عند بدء التشغيل، وينطبق على النسخة بأكملها. ولا يكون نطاقه مقصوراً على مستخدم معيّن. كل من يملك حساباً على نسختك ويمكنه إنشاء وكيل يستخدم هذا المفتاح، وأول شخص يسجّل حساباً يكون مسؤولاً.

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

لا تكون التكلفة أثناء الخمول صفراً عندما يعمل وكيل وفق جدول زمني. إذ يُشغَّل مشغّل الجدول سواء كان أحد يراقبه أم لا، ويرسل كل تشغيل رموزاً. ينتج عن جدول زمني مدته خمس دقائق 288 عملية تشغيل يومياً، وحتى الوكيل الذي يقرأ صفحة ويقرّر عدم فعل شيء يتحمّل تكلفة قراءة الصفحة. ابدأ بتشغيل وكلائك باستخدام مشغّل webhook أو مشغّل دردشة، وراقب الإنفاق الفعلي لمدة أسبوع، ثم انتقل إلى جدول زمني بعد معرفة تكلفة كل تشغيل.

نسخ Postgres ومخزن الكائنات احتياطياً

هناك مخزنا بيانات وسر واحد. يؤدي فقدان أي منها إلى فقدان نسختك. خذ نسخة من قاعدة البيانات والدلو ضمن النافذة الزمنية نفسها، مع إيقاف الواجهة الخلفية، حتى لا يُكتب ملف بعد تفريغ صفه من قاعدة البيانات.

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

استخدم القيمة التي عيّنتها لـ DB_USERNAME بدلاً من postgres إذا غيّرتها. ثم انسخ وحدة تخزين مخزن الكائنات باستخدام الاسم ذي السابقة الذي طبعه docker volume ls:

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

تحقق من أن التفريغ غير فارغ قبل الوثوق به: يجب أن يعرض gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 عبارات CREATE TABLE وDROP TABLE، لا خطأً في سطر واحد. ثم انسخ الملفات الثلاثة كلها إلى خارج الخادم. لا تُعدّ النسخة الاحتياطية الموجودة على الجهاز الذي تحميه نسخة احتياطية.

للاستعادة على خادم جديد، ثبّت الوسم نفسه، وأعد docker/.env.ce المحفوظ حتى تتطابق كلمة مرور تشفير بيانات الاعتماد والملح، وشغّل المكدس مرة واحدة حتى تُنشأ وحدات التخزين، وأوقف الواجهة الخلفية، ثم حمّل التفريغ:

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

الترقيات واستعادة الخدمة عند فشل إحداها

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

cd ~/livecontext-ce
git fetch --tags
git tag --list 'v*' | tail -5
TAG=v0.2.11
git checkout "$TAG"
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

اضبط TAG على الوسم الذي اخترته من القائمة التي طبعها الأمر الثالث. راقب سجل المكوّن الخلفي إلى أن تستجيب نقطة نهاية الصحة مجدداً. إنّ docker-compose.override.yml لديك غير متتبَّع، لذلك يتركه git checkout في مكانه، لكن اقرأ الفروقات في docker-compose.yml بين الوسوم، لأن إضافة خدمة جديدة أو إعادة تسمية خدمة قد تجعل التجاوز الخاص بك قديماً من دون ظهور أي رسالة خطأ.

أوضاع الفشل، مع النصوص التي ستظهر لك

تستمر حاوية في إعادة التشغيل ويعرض docker compose ps القيمة exited (137). هذا هو قاتل نفاد الذاكرة في النواة، ويؤكد docker inspect livecontext-app ذلك عبر "OOMKilled": true في كتلة الحالة. لقد تجاوزت خدمة backend حد الذاكرة البالغ 1536M، أو نفدت ذاكرة المضيف أولاً. تحقّق من free -m قبل رفع أي حد، لأن رفع حد الحاوية على مضيف لا يملك ذاكرة احتياطية سينقل عملية الإنهاء إلى حاوية أخرى فقط.

يفشل السحب مع no matching manifest for linux/arm64/v8 in the manifest list entries. الصور منشورة لـlinux/amd64 فقط. لا يستطيع Arm VPS تشغيل هذه الحزمة باستخدام الصور المنشورة، كما أن المحاكاة عبر QEMU بطيئة جداً لتشغيل JVM مع Chromium. انتقل إلى خطة x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. هناك برنامج آخر على المضيف يستخدم هذا المنفذ بالفعل. غيّر FRONTEND_PORT في docker/.env.ce، أو طبّق التجاوز المذكور أعلاه وانشر دون استخدام أي منفذ.

تعمل واجهة المستخدم، لكن يفشل طلب تسجيل الدخول بعد إضافة الـproxy. يستدعي المتصفح backend عبر origin لا يقدّمه الـproxy. افتح علامة تبويب الشبكة في المتصفح وتحقق من مضيف الطلب الفاشل. اضبط GATEWAY_PUBLIC_URL على عنوان URL العام لـbackend، ثم أعد إنشاء حاوية الواجهة الأمامية، لأن هذه القيمة تُقرأ عند بدء التشغيل.

كل شيء سليم، لكن الملفات التي تُرفع ضمن سير عمل تختفي. تحقّق من أن minio-init يعرض exited (0) بدلاً من رمز غير صفري. إذا لم تُنشأ الحاوية workflow-files مطلقاً، فلن يجد backend مكاناً لتخزين الكائنات.

اختر LiveContext أو n8n

اختر LiveContext عندما يكون الوكيل هو محور العمل: تريد أن ينشئ النموذج الأتمتة ويشغّلها، وتقبل أن يكون خادم بسعة 8 GB وخدمة Java جزءاً من التكلفة. اختر n8n عندما تريد مسارات عمل حتمية، ومكتبة كبيرة من العقد، وبصمة موارد تسمح بمشاركة VPS مع خدمات أخرى. أرقام الإصدارات المذكورة هنا حديثة، v0.2.11 اعتباراً من August 2026، لذلك ثبّت الوسم واقرأ ملاحظات الإصدار قبل كل ترقية. للاطلاع على المجال الأوسع، بما في ذلك الأدوات التي تقع بين هذين الخيارين، راجع مقارنتنا لبدائل n8n ذاتية الاستضافة بدلاً من قراءة مقارنة تقتصر على هذين الخيارين.

FAQ

ما مقدار RAM الذي يحتاجه LiveContext المستضاف ذاتياً؟

خطّط لتوفير 8 GB. يذكر README الأساسي أن 4 GB هو الحد الأدنى وأن 8 GB هي السعة الموصى بها، ويتوافق ملف compose المرفق مع ذلك: يقتصر backend وحده على 1536 MB، بينما تستهلك الخدمات الأساسية الخمس مجتمعة أقل بقليل من 3 GB قبل احتساب حاوية frontend غير المحدودة. يؤدي تفعيل ملف browser agent إلى إضافة 2048 MB أخرى لـChromium، إضافة إلى حاوية SearXNG، ولذلك تصبح 8 GB ضرورية عندئذ.

هل يمكنني تشغيل LiveContext على Arm VPS؟

لا. كل image منشورة مبنية لـlinux/amd64، ولذلك يفشل docker compose up في خطة Arm عند السحب مع no matching manifest for linux/arm64/v8 in the manifest list entries. يمكن تشغيله نظرياً باستخدام محاكاة QEMU، لكن ذلك غير عملي مع حمل عمل JVM. اختر خطة x86.

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

ضعه في docker/.env.ce، على هيئة ANTHROPIC_API_KEY أو OPENAI_API_KEY أو GOOGLE_API_KEY، قبل التشغيل الأول. يقرأه backend وbridge عند بدء التشغيل، وينطبق على المثيل بأكمله لا على مستخدم واحد. اضبط صلاحيات الملف على 600، واستخدم مفتاحاً أُنشئ لهذا الخادم فقط حتى تتمكن من إبطاله بشكل مستقل، وحدد سقفاً للإنفاق في وحدة تحكم المزوّد، لأن هذا السقف هو الحد الوحيد الموجود خارج الجهاز.

كيف أنشئ نسخة احتياطية من LiveContext؟

تحتاج إلى ثلاثة أشياء: pg_dump من قاعدة بيانات livecontext، ونسخة من volume الخاص بـMinIO، وملف docker/.env.ce. أوقف خدمتي livecontext وfrontend أثناء إنشاء العنصرين الأولين، حتى تتطابق قاعدة البيانات ومخزن الكائنات. ملف env مهم لأن بيانات الاعتماد المخزنة في workflows مشفّرة باستخدام CREDENTIAL_ENCRYPTION_PASSWORD وCREDENTIAL_ENCRYPTION_SALT، ولذلك تؤدي عملية الاستعادة من دون هذه القيم إلى ترك صفوف بيانات اعتماد لا يستطيع أي شيء على الخادم الجديد قراءتها.

لماذا يبقى backend عند health: starting لعدة دقائق بعد الإقلاع؟

يحدد healthcheck في compose قيمة start_period: 120s ويستعلم من /actuator/health، ولذلك يعرض Docker الخدمة على أنها قيد البدء أثناء تشغيل عمليات ترحيل المخطط وتسجيل الأدوات. من المتوقع أن يستغرق الإقلاع الأول دقيقتين إلى 3 دقائق. إذا لم تنتقل الخدمة أبداً إلى الحالة السليمة، فاقرأ docker compose logs -f livecontext. عادةً ما تكون الحزمة التي تتوقف عند خطوة الترحيل موجهة إلى volume قاعدة بيانات من إصدار أحدث.