آموزش میزبانی شخصی LiveContext جایگزین n8n

LiveContext چیست و هزینه اجرای آن چقدر است

برای میزبانی شخصی LiveContext، به یک VPS با حدود 8 گیگابایت رم نیاز دارید. LiveContext CE یک پلتفرم اتوماسیون متن‌باز است که عامل‌های هوش مصنوعی را درون خودِ اتوماسیون اجرا می‌کند و به‌صورت یک stack شامل شش کانتینر Docker Compose که حول یک backend جاوا ساخته شده‌اند، عرضه می‌شود. فایل README اصلی پروژه، حداقل 4 گیگابایت و مقدار پیشنهادی 8 گیگابایت رم را درخواست می‌کند و فایل compose نشان می‌دهد که این حافظه چگونه مصرف می‌شود.

این پروژه در livecontext-ai/livecontext-ce در GitHub قرار دارد و تحت مجوز AGPL-3.0 منتشر شده است. نسخه فعلی تا اوت 2026، v0.2.11 است که در تاریخ 3 اوت 2026 منتشر شده است. تمامی ایمیج‌ها فقط برای linux/amd64 ساخته شده‌اند که استفاده از پلن‌های ارزان‌قیمت Arm را غیرممکن می‌کند. این راهنما آن تگ را ثابت (pin) می‌کند، stack را پشت یک 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
  }
]

بخش backend به‌تنهایی به 1536 مگابایت محدود شده است. این محدودیت بر روی یک پردازش Java 21 اعمال می‌شود، بنابراین JVM بخش عمده آن را اشغال کرده و در همان سطح باقی می‌ماند. مجموع پنج سرویس پایه به کمی کمتر از 3 گیگابایت می‌رسد و بخش frontend هیچ محدودیتی ندارد، بنابراین هر چقدر که Node درخواست کند، مصرف می‌کند. روی یک VPS با 4 گیگابایت رم، تقریباً چیزی برای هسته سیستم‌عامل (kernel) و page cache باقی نمی‌ماند؛ به همین دلیل 4 گیگابایت به‌عنوان حداقلِ موردنیاز ذکر شده است، نه به‌عنوان یک پیشنهاد.

پروفایل‌های اختیاری همان مواردی هستند که نیاز سرور را به 8 گیگابایت می‌رسانند. پروفایل browser agent یک کانتینر Chromium با محدودیت 2048 مگابایت را در کنار یک نمونه جستجوی SearXNG اضافه می‌کند و پروفایل renderer نیز 1024 مگابایت دیگر برای اسکرین‌شات‌ها و فایل‌های PDF اختصاص می‌دهد. هیچ‌کدام از این‌ها تا زمانی که پروفایل مربوطه را فعال نکنید اجرا نمی‌شوند، پس تا زمانی که به آن‌ها نیاز ندارید، هر دو را غیرفعال نگه دارید. کانتینر SearXNG برای این وجود دارد که backend جستجوی agent باشد، بنابراین صفحاتی که بازمی‌گرداند به‌عنوان متن غیرقابل‌اعتماد در پرامپت‌های شما ظاهر می‌شوند؛ این همان مرز اعتماد است که در ارائه دسترسی جستجوی وب SearXNG به یک AI agent به‌طور مفصل بررسی شده است.

اگر در حال حاضر n8n را اجرا می‌کنید، برنامه‌ریزی کنید که آن را جایگزین کنید، نه اینکه به آن اضافه کنید. استک موجود در راهنمای ما برای اجرای n8n روی VPS با Docker و HTTPS شامل یک پردازش Node در کنار Postgres است و روی یک سرور کوچک به‌راحتی اجرا می‌شود. LiveContext به‌تنهایی برای backend خود بیش از کل آن استک حافظه رزرو می‌کند. دو پلتفرم اتوماسیون روی یک VPS با 8 گیگابایت رم تا زمانی که هر دو در یک دقیقه کاری را اجرا نکنند، به‌خوبی کار می‌کنند. اگر قصد دارید از یک میزبان مشترک استفاده کنید، با استفاده از روش ذکرشده در پست ما درباره تنظیم محدودیت حافظه در Docker Compose، برای همه سرویس‌های دیگر نیز محدودیت‌های صریح تعیین کنید تا یک گردش‌کار (workflow) خارج از کنترل نتواند کل ماشین را از دسترس خارج کند.

نصب LiveContext با Docker Compose و قفل کردن روی یک تگ خاص

کار را با یک VPS تمیز دارای Ubuntu 24.04، نسخه 24 یا جدیدتر Docker Engine و نسخه 2 از Compose شروع کنید. اگر Docker هنوز نصب نشده است، ابتدا مبانی Docker Compose ما برای VPS را دنبال کنید و سپس بازگردید.

فایل README دستور npx livecontext را به عنوان یک راهکار سریع پیشنهاد می‌دهد. این روش برای لپ‌تاپ مناسب است. اما روی سرور، بهتر است فایل compose در دایرکتوری تحت کنترل شما باشد؛ چرا که در این صورت، ارتقا تنها با یک git checkout انجام می‌شود و می‌توانید دقیقاً تغییرات را بررسی کنید.

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 از قبل تمام imageها را روی تگ release مربوطه قفل کرده است، برای مثال ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. بررسی تگ git متناظر باعث می‌شود فایل compose و imageها با هم هماهنگ بمانند، زیرا فایل compose برای v0.2.11 دقیقاً برای همان imageها نوشته شده است. تگ‌ها را به latest تغییر ندهید. تگ latest ممکن است بدون اطلاع شما تغییر کند و از آنجا که backend در هر بار اجرا، migrationهای دیتابیس را انجام می‌دهد، یک pull ناخواسته می‌تواند schema شما را در ساعت 3 صبح به نسخه جدید ببرد و راه بازگشتی جز restore کردن وجود نداشته باشد.

پیش از اولین اجرا، فایل docker/.env.ce را ویرایش کنید (بخش بعدی موارد لازم برای تغییر را فهرست کرده است)، سپس stack را بالا بیاورید.

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

در تمام دستورات compose در این راهنما، از همان فلگ --env-file استفاده کنید. Compose در هر بار فراخوانی، فایل را از نو می‌خواند؛ بنابراین دستوری که بدون این فلگ اجرا شود، به تنظیمات پیش‌فرض داخل فایل compose بازمی‌گردد و ممکن است پورت‌هایی متفاوت از آنچه پیکربندی کرده‌اید را منتشر کند.

بررسی سلامت (healthcheck) در backend دارای یک start_period به مدت 120 ثانیه است و /actuator/health را پایش می‌کند، بنابراین docker compose ps در حدود دو دقیقه اول، تا زمانی که migrationهای schema و ثبت ابزارها انجام شوند، وضعیت سرویس livecontext را health: starting گزارش می‌دهد. این رفتار طبیعی است. یک بررسی سریع از داخل سرور:

curl -s localhost:8080/actuator/health

این دستور باید {"status":"UP"} را چاپ کند. پس از آن، رابط کاربری وب را روی پورت 3000 باز کنید. اولین حسابی که ایجاد می‌کنید، دسترسی مدیر (admin) خواهد داشت، پس پیش از آنکه پورت برای دیگران در دسترس قرار گیرد، حساب خود را بسازید. این مهم‌ترین دلیل برای عدم انتشار پورت 3000 روی اینترنت در روز اول است.

مقادیر env که باید تغییر دهید

فایل نمونه با مقادیر پیش‌فرض ارائه می‌شود تا stack روی لپ‌تاپ اجرا شود. چندین مورد از این مقادیر در سرور عمومی ناامن هستند.

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 ارائه می‌شوند. هیچ‌کدام از پورت‌های دیتابیس روی host منتشر نمی‌شوند، بنابراین مستقیماً در معرض دسترسی نیستند، اما هر container که بعداً به همان شبکه متصل کنید می‌تواند با مقادیر پیش‌فرض مستندشده به هر دو دسترسی داشته باشد.
• CREDENTIAL_ENCRYPTION_PASSWORD و CREDENTIAL_ENCRYPTION_SALT در صورت خالی ماندن به‌طور خودکار تولید می‌شوند. خودتان آن‌ها را تنظیم کنید. اعتبارنامه‌هایی که workflowهای شما ذخیره می‌کنند با این جفت رمزنگاری می‌شوند، بنابراین اگر dump دیتابیس را روی سیستم جدیدی بدون همان رمز عبور و salt بازیابی کنید، ردیف‌های اعتبارنامه غیرقابل خواندن خواهند بود. آن‌ها را یک‌بار تنظیم کنید و سپس docker/.env.ce را بخشی از نسخه پشتیبان (backup) در نظر بگیرید.
• FRONTEND_PORT و BACKEND_PORT در نگاشت پورت‌ها به عنوان ${FRONTEND_PORT:-3000}:3000 و ${BACKEND_PORT:-8080}:8080 جایگزین می‌شوند. فایل env نمونه هر دو را به‌طور صریح تنظیم می‌کند و مقادیر ارائه‌شده همیشه 3000 و 8080 نیستند. به جای فرض کردن، فایل خود را مطالعه کنید.
• GATEWAY_PUBLIC_URL مبدأ (origin) سمت مرورگر برای backend است. به محض استفاده از 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 برای جستجوی embedding در آن قرار دارد، بنابراین یک ایمیج معمولی postgres:16 کافی نخواهد بود.
• redis برنامه redis:7-alpine را با تنظیمات appendonly yes و --maxmemory-policy noeviction اجرا می‌کند. این سیاست آگاهانه است: Redis در اینجا وظیفه حمل صف و وضعیت اجرا را بر عهده دارد، بنابراین هنگامی که به سقف حافظه خود می‌رسد، به جای حذف بی‌سروصدای کلیدها، یک خطا به نویسنده بازمی‌گرداند. خطایی که می‌توانید مشاهده کنید، بهتر از کاری است که ناپدید می‌شود.
• minio یک فضای ذخیره‌سازی شیء (object store) سازگار با S3 برای فایل‌هایی است که در جریان‌های کاری (workflows) جابه‌جا می‌شوند. یک کانتینر یک‌بارمصرف minio-init در زمان راه‌اندازی، mc mb myminio/workflow-files --ignore-existing را اجرا کرده، bucket را ایجاد می‌کند و سپس خارج می‌شود. مشاهده وضعیت minio-init به عنوان exited (0) در docker compose ps نشان‌دهنده وضعیت سالم است.
• bridge آداپتورهای CLI و ابزارهای MCP (پروتکل زمینه مدل) را در خود جای داده است. این کانتینر روی پورت 8093 در شبکه Docker گوش می‌دهد و روی میزبان (host) منتشر نمی‌شود.
• livecontext بخش backend است، یک monolith مبتنی بر Java 21 روی پورت 8080. این بخش موتور جریان کاری، زمان‌بندها و عامل‌ها (agents) را اجرا می‌کند.
• frontend رابط کاربری وب Next.js روی پورت 3000 است. تنها این دو مورد آخر روی میزبان منتشر شده‌اند.

وضعیت (state) در پنج volume نام‌گذاری‌شده ذخیره می‌شود: livecontext_data برای Postgres، به همراه livecontext_redis، livecontext_minio، livecontext_keys و livecontext_logs. دستور Compose پیشوندی از نام پروژه (که به‌صورت پیش‌فرض نام دایرکتوری است) به آن‌ها اضافه می‌کند، بنابراین نام واقعی volume روی دیسک چیزی شبیه به livecontext-ce_livecontext_minio خواهد بود. پیش از نوشتن هرگونه اسکریپت پشتیبان‌گیری، دستور docker volume ls را اجرا کرده و نام‌های دقیق را کپی کنید.

docker compose down -v هر پنج volume را حذف می‌کند. این روش مستندشده برای شروع مجدد است و در عین حال سریع‌ترین راه برای از دست دادن تمام جریان‌های کاری است که ساخته‌اید. تفاوت اصلی در همان -v است.

قرار دادن آن پشت Traefik به‌جای انتشار پورت 3000

انتشار پورت‌های 3000 و 8080 روی یک VPS عمومی، برنامه را بدون TLS (امنیت لایه انتقال) و بدون هیچ دروازه‌ای در مقابل ثبت‌نام ادمین در معرض دید قرار می‌دهد. یک قانون ufw به‌تنهایی کافی نیست، زیرا Docker قوانین iptables اختصاصی خود را برای پورت‌های منتشرشده، پیش از زنجیره‌ای که توسط ufw مدیریت می‌شود قرار می‌دهد؛ بنابراین پورتی که روی 0.0.0.0 منتشر شده است، حتی زمانی که ufw آن را مسدود کرده باشد، همچنان در دسترس باقی می‌ماند.

راهکار تمیز این است که هیچ پورتی را منتشر نکنید و اجازه دهید پروکسی از طریق یک شبکه مشترک Docker به کانتینرها دسترسی پیدا کند. فایل docker-compose.override.yml را در ریشه مخزن ایجاد کنید:

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

networks:
  proxy:
    external: true

دو جزئیات تعیین می‌کنند که آیا این روش کار می‌کند یا خیر. !override جایگزین لیست پورت‌ها می‌شود و با آن ادغام نمی‌شود، که این امر به Compose نسخه 2.24 یا جدیدتر نیاز دارد: با استفاده از docker compose version آن را بررسی کنید، زیرا در نسخه‌های قدیمی‌تر Compose، دو لیست با هم ادغام شده و پورت‌ها همچنان منتشر باقی می‌مانند. همچنین default باید در هر لیست networks باقی بماند، زیرا نام‌گذاری هر شبکه، جایگزین شبکه پیش‌فرض می‌شود و حذف آن باعث قطع ارتباط فرانت‌اند با Postgres و Redis خواهد شد. پیش از شروع هر کاری، نتیجه ادغام‌شده را تأیید کنید:

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

روترها، حل‌کننده گواهی (certificate resolver) و تغییر مسیر HTTP به HTTPS مشابه هر برنامه دیگری هستند، بنابراین به‌جای نوشتن پیکربندی TLS جدید در اینجا، از راهنمای ما برای اجرای چندین برنامه روی یک VPS با استفاده از Traefik reverse proxy پیروی کنید. یک نام دامنه را به frontend روی پورت 3000 و دومی را به livecontext روی پورت 8080 هدایت کنید.

نام دامنه دوم اختیاری نیست. رابط کاربری وب (web UI)، بک‌اند را از داخل مرورگر فراخوانی می‌کند، بنابراین بک‌اند به مبدأ (origin) اختصاصی خود نیاز دارد که مرورگر بتواند به آن دسترسی داشته باشد. مقدار GATEWAY_PUBLIC_URL را در docker/.env.ce روی آن URL بک‌اند تنظیم کنید، برای مثال https://lc-api.example.com. اگر این کار را انجام ندهید، صفحه به‌طور عادی بارگذاری می‌شود اما تمام عملیات‌ها با شکست مواجه می‌شوند، زیرا رابط کاربری، مبدأ بک‌اند را از آدرسی که با آن صفحه را باز کرده‌اید تشخیص می‌دهد و در حال فراخوانی پورتی است که پروکسی شما هرگز آن را منتشر نکرده است.

از آنجایی که صفحه ثبت‌نام برای هر کسی که به آن دسترسی پیدا کند باز است، ارزشش را دارد که یک احراز هویت روی روتر فرانت‌اند قرار دهید تا هیچ‌کس بدون احراز هویت در سطح پروکسی، آن صفحه را نبیند؛ این همان قابلیتی است که اجرای Authentik به‌عنوان لایه SSO اختصاصی به همان تنظیمات Traefik اضافه می‌کند.

محل قرارگیری کلید مدل و دلیل هزینه داشتن نمونه‌های غیرفعال

عامل‌ها (Agents) در اینجا درون اتوماسیون اجرا می‌شوند که این موضوع، مدل اقتصادی آن را نسبت به ابزارهای گردش‌کار ساده تغییر می‌دهد. کلید ارائه‌دهنده در docker/.env.ce به عنوان ANTHROPIC_API_KEY یا OPENAI_API_KEY قرار می‌گیرد، در زمان راه‌اندازی توسط بک‌اند و پل (bridge) خوانده می‌شود و برای کل نمونه (instance) اعمال می‌گردد. این کلید محدود به کاربر خاصی نیست. هر کسی که در نمونه شما حساب کاربری دارد و می‌تواند یک عامل بسازد، در حال استفاده از این کلید است و اولین نفری که ثبت‌نام کند، مدیر (admin) خواهد بود.

سه عادت باعث می‌شود هزینه‌ها قابل پیش‌بینی باقی بمانند. یک کلید ارائه‌دهنده مجزا برای این VPS ایجاد کنید تا بتوانید بدون ایجاد اختلال در سایر بخش‌ها، آن را ابطال کنید. یک سقف هزینه سخت (hard spend cap) در کنسول ارائه‌دهنده تنظیم کنید، زیرا آن محدودیت تنها موردی است که خارج از ماشینی که در حال ایمن‌سازی آن هستید، اعمال می‌شود. سپس از بودجه‌های اعتباری و معیارهای هر عامل که LiveContext ارائه می‌دهد استفاده کنید تا یک حلقه (loop) نتواند پیش از آنکه متوجه شوید، کلید را تخلیه کند.

هزینه حالت غیرفعال (idle) زمانی که یک عامل روی زمان‌بندی (schedule) قرار می‌گیرد، صفر نیست. یک محرک زمان‌بندی (schedule trigger) فارغ از اینکه کسی آن را نظارت کند یا خیر، فعال می‌شود و هر بار اجرا، توکن مصرف می‌کند. یک زمان‌بندی 5 دقیقه‌ای به معنای 288 اجرا در روز است و عاملی که یک صفحه را می‌خواند و تصمیم می‌گیرد کاری انجام ندهد، همچنان هزینه خواندن آن صفحه را می‌پردازد. اولین عامل‌های خود را روی یک webhook یا محرک چت (chat trigger) قرار دهید، هزینه‌های واقعی را برای یک هفته زیر نظر بگیرید و پس از آنکه هزینه هر اجرا را دانستید، به سراغ زمان‌بندی بروید.

پشتیبان‌گیری از Postgres و object store

دو منبع داده و یک secret وجود دارد که از دست دادن هر یک از آن‌ها منجر به از دست رفتن instance شما می‌شود. از پایگاه داده و bucket در یک بازه زمانی واحد پشتیبان بگیرید، در حالی که backend متوقف شده است؛ این کار باعث می‌شود فایلی پس از dump شدن ردیف پایگاه داده مربوط به آن، نوشته نشود.

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 چاپ کرده است، از volume مربوط به object store کپی بگیرید:

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)

پیش از اعتماد به dump، بررسی کنید که خالی نباشد: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 باید شامل دستورات CREATE TABLE و DROP TABLE باشد، نه یک خط پیام خطا. سپس هر سه فایل را از سرور خارج کنید. پشتیبانی که فقط روی همان ماشینی که از آن محافظت می‌کند باقی بماند، پشتیبان محسوب نمی‌شود.

برای بازیابی روی یک سیستم جدید، همان tag را نصب کنید، docker/.env.ce ذخیره‌شده را بازگردانید تا رمز عبور رمزنگاری اعتبارنامه‌ها و salt مطابقت داشته باشند، stack را یک بار اجرا کنید تا volumeها ایجاد شوند، backend را متوقف کنید و سپس dump را بارگذاری نمایید:

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

ارتقا و بازگشت به وضعیت قبل در صورت بروز خطا

همیشه پیش از هر کاری، یک نسخه پشتیبان (dump) تهیه کنید. سرویس backend در زمان شروع، مهاجرت‌های شمای پایگاه داده را اعمال می‌کند و این مهاجرت‌ها فقط رو به جلو هستند؛ بنابراین اگر پس از یک ارتقای ناموفق به نسخه (tag) قدیمی برگردید، کد قدیمی با شمای جدید اجرا می‌شود. بازگشت به وضعیت قبل (rollback) به معنای بازیابی نسخه پشتیبان است و به همین دلیل تهیه پشتیبان باید در اولویت باشد.

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 را روی تگی که از لیست چاپ‌شده توسط دستور سوم انتخاب کرده‌اید، تنظیم کنید. لاگ backend را تا زمانی که endpoint سلامت (health endpoint) دوباره پاسخ دهد، زیر نظر بگیرید. فایل docker-compose.override.yml شما توسط git ردیابی نمی‌شود، بنابراین دستور git checkout آن را دست‌نخورده باقی می‌گذارد؛ اما حتماً تفاوت‌های (diff) فایل docker-compose.yml را بین دو تگ بررسی کنید، زیرا ممکن است یک سرویس جدید یا تغییر نام یک سرویس، تنظیمات override شما را بدون نمایش هیچ پیام خطایی، منسوخ کند.

حالت‌های شکست و پیام‌های مربوط به آن‌ها

یک کانتینر مدام در حال ری‌استارت است و docker compose ps مقدار exited (137) را نشان می‌دهد. این وضعیت نشان‌دهنده عملکرد OOM Killer (قاتل حافظه) هسته سیستم‌عامل است و docker inspect livecontext-app با نمایش "OOMKilled": true در بلوک وضعیت، آن را تأیید می‌کند. سرویس backend به محدودیت 1536M خود رسیده است یا حافظه میزبان (host) تمام شده است. پیش از افزایش هرگونه محدودیت، free -m را بررسی کنید؛ زیرا افزایش محدودیت کانتینر روی میزبانی که منابع آزاد ندارد، فقط باعث می‌شود کانتینر دیگری توسط سیستم متوقف شود.

عملیات pull با خطای no matching manifest for linux/arm64/v8 in the manifest list entries شکست می‌خورد. ایمیج‌ها فقط برای linux/amd64 منتشر شده‌اند. یک VPS با معماری Arm نمی‌تواند این stack را از روی ایمیج‌های منتشرشده اجرا کند و شبیه‌سازی از طریق QEMU برای اجرای JVM به همراه Chromium بسیار کند است. از یک پلن x86 استفاده کنید.

خطای Bind for 0.0.0.0:3000 failed: port is already allocated. سرویس دیگری روی میزبان از قبل آن پورت را اشغال کرده است. مقدار FRONTEND_PORT را در docker/.env.ce تغییر دهید یا از override بالا استفاده کنید و هیچ پورتی را منتشر نکنید.

رابط کاربری (UI) بالا می‌آید اما درخواست ورود پس از افزودن پروکسی شکست می‌خورد. مرورگر در حال فراخوانی backend از مبدأیی (origin) است که پروکسی شما آن را سرویس‌دهی نمی‌کند. تب Network در مرورگر را باز کنید و host درخواست ناموفق را بررسی کنید. مقدار GATEWAY_PUBLIC_URL را روی URL عمومی backend تنظیم کرده و کانتینر frontend را دوباره ایجاد کنید، زیرا این مقدار فقط در زمان شروع (startup) خوانده می‌شود.

همه چیز سالم است اما فایل‌های آپلود شده در یک workflow ناپدید می‌شوند. بررسی کنید که minio-init مقدار exited (0) را نشان دهد و نه یک کد غیر صفر. اگر bucket مربوط به workflow-files هرگز ایجاد نشده باشد، backend مکانی برای ذخیره اشیاء (objects) ندارد.

انتخاب بین LiveContext یا n8n

زمانی که تمرکز اصلی بر روی عامل (agent) است، LiveContext را انتخاب کنید: یعنی می‌خواهید مدل، اتوماسیون را بسازد و اجرا کند، و در عین حال می‌پذیرید که بهای آن، استفاده از یک سرور با 8 GB رم و یک سرویس Java است. زمانی که به گردش‌کارهای قطعی (deterministic)، کتابخانه‌ای بزرگ از نودها و ابزاری با ردپای سبک که می‌تواند یک VPS را با سایر سرویس‌ها شریک شود نیاز دارید، n8n را انتخاب کنید. شماره نسخه‌های ذکر شده در اینجا جدید هستند، v0.2.11 تا اوت 2026، بنابراین تگ نسخه خود را ثابت (pin) کنید و پیش از هر ارتقا، یادداشت‌های انتشار (release notes) را مطالعه نمایید. برای بررسی گزینه‌های گسترده‌تر، از جمله ابزارهایی که در جایگاهی بین این دو قرار می‌گیرند، به مجموعه جایگزین‌های خودمیزبان n8n ما مراجعه کنید و تنها به مقایسه این دو بسنده نکنید.

FAQ

میزان رم مورد نیاز برای اجرای LiveContext چقدر است؟

برای 8 گیگابایت رم برنامه‌ریزی کنید. فایل README اصلی، 4 گیگابایت را حداقل و 8 گیگابایت را مقدار پیشنهادی اعلام کرده است و فایل compose ارائه‌شده نیز با این مقادیر مطابقت دارد: بخش backend به‌تنهایی به 1536 مگابایت محدود شده است و پنج سرویس پایه در مجموع کمی کمتر از 3 گیگابایت رم مصرف می‌کنند (پیش از آنکه container نامحدود frontend محاسبه شود). فعال‌سازی پروفایل browser agent، مقدار 2048 مگابایت دیگر برای Chromium و یک container برای SearXNG اضافه می‌کند؛ بنابراین در آن مرحله، 8 گیگابایت رم دیگر یک گزینه انتخابی نیست.

آیا می‌توانم LiveContext را روی یک VPS با معماری Arm اجرا کنم؟

خیر. تمام imageهای منتشرشده برای linux/amd64 ساخته شده‌اند، بنابراین docker compose up روی یک پلن Arm در مرحله pull با خطای no matching manifest for linux/arm64/v8 in the manifest list entries مواجه می‌شود. اجرای آن تحت شبیه‌ساز QEMU در تئوری ممکن است، اما برای یک workload مبتنی بر JVM در عمل غیرقابل استفاده است. یک پلن x86 انتخاب کنید.

کلید API مدل خود را کجا قرار دهم؟

در docker/.env.ce، به عنوان ANTHROPIC_API_KEY، OPENAI_API_KEY یا GOOGLE_API_KEY، پیش از اولین اجرا. بخش backend و bridge این کلید را هنگام راه‌اندازی می‌خوانند و این کلید برای کل instance اعمال می‌شود، نه فقط برای یک کاربر خاص. فایل را با مجوز 600 نگه دارید، از کلیدی استفاده کنید که فقط برای همین سرور ایجاد شده است تا بتوانید آن را به‌صورت مستقل ابطال کنید، و در کنسول ارائه‌دهنده سرویس یک سقف هزینه (spend cap) تعیین کنید؛ چرا که آن سقف، تنها محدودیتی است که خارج از این ماشین اعمال می‌شود.

چگونه از LiveContext نسخه پشتیبان تهیه کنم؟

سه مورد را باید در نظر بگیرید: یک pg_dump از دیتابیس livecontext، یک کپی از volume مربوط به MinIO و فایل docker/.env.ce. هنگام تهیه دو مورد اول، سرویس‌های livecontext و frontend را متوقف کنید تا دیتابیس و object store با یکدیگر همگام باشند. فایل env اهمیت حیاتی دارد، زیرا اعتبارنامه‌های ذخیره‌شده در workflowهای شما با CREDENTIAL_ENCRYPTION_PASSWORD و CREDENTIAL_ENCRYPTION_SALT رمزنگاری شده‌اند؛ بنابراین بازیابی بدون این مقادیر، منجر به ردیف‌هایی از اعتبارنامه می‌شود که هیچ‌چیز در سیستم جدید قادر به خواندن آن‌ها نیست.

چرا backend پس از بوت، دقایق طولانی در وضعیت health: starting باقی می‌ماند؟

بررسی سلامت (healthcheck) در compose، مقدار start_period: 120s را تنظیم کرده و /actuator/health را پایش می‌کند؛ بنابراین Docker تا زمانی که مهاجرت‌های schema و ثبت ابزارها انجام نشود، سرویس را در وضعیت starting گزارش می‌دهد. دو تا سه دقیقه زمان در اولین بوت طبیعی است. اگر وضعیت هرگز به healthy تغییر نکرد، docker compose logs -f livecontext را مطالعه کنید. استکی که در مرحله migration متوقف می‌شود، معمولاً به یک volume دیتابیس مربوط به نسخه جدیدتر اشاره دارد.