راهنمای self-host کردن LiveContext، جایگزین n8n

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

برای self-host کردن LiveContext به یک VPS با حدود 8 GB RAM نیاز دارید. LiveContext CE یک پلتفرم اتوماسیون source-available است که agentهای هوش مصنوعی را داخل خود فرایند اتوماسیون اجرا می‌کند. این پلتفرم به‌صورت یک stack از نوع Docker Compose شامل 7 container ارائه می‌شود که بر پایه یک backend جاوا ساخته شده‌اند. یکی از این containerها یک job یک‌باره است که پس از setup خارج می‌شود. مستندات self-hosting سازنده، حداقل 4 GB و مقدار پیشنهادی 8 GB را اعلام می‌کنند. README مربوط به launcher مبتنی بر npm اکنون حداقل 6 GB را ذکر می‌کند. فایل compose نیز نشان می‌دهد این حافظه در کجا مصرف می‌شود.

این پروژه در GitHub با شناسه livecontext-ai/livecontext-ce و تحت مجوز AGPL-3.0 منتشر شد، اما CE دیگر تحت AGPL نیست. مجوز همراه release فعلی، LiveContext Sustainable Use License 1.1 است؛ مجوزی source-available که اجرای CE و ایجاد تغییر در آن را، از جمله در محیط production کسب‌وکار خودتان، مجاز می‌کند. بااین‌حال، ارائه آن به اشخاص ثالث به‌صورت hosted یا embedded برای رقابت با نسخه‌های پولی LiveContext ممنوع است. launcher مبتنی بر npm سازنده این تغییر را نشان می‌دهد: livecontext@0.2.11 مقدار AGPL-3.0-only را اعلام می‌کند، درحالی‌که livecontext@0.3.8 به فایل همان مجوز اشاره دارد. تا 13 October 2026، مخزن GitHub و سازمان livecontext-ai هر دو پاسخ 404 برمی‌گردانند، درحالی‌که مستندات سازنده همچنان می‌گویند آن را clone کنید. بنابراین این راهنما فایل‌های release را از package مربوط به npm دریافت می‌کند. release فعلی v0.3.8 است که در 9 October 2026 منتشر شده است. تمام imageهای LiveContext فقط برای linux/amd64 ساخته شده‌اند و این موضوع planهای ارزان Arm را منتفی می‌کند. این راهنما آن tag را ثابت می‌کند، stack را پشت یک reverse proxy قرار می‌دهد و توصیه‌های upstream درباره backup را به command تبدیل می‌کند.

پیش از self-host کردن LiveContext، اندازه VPS را تعیین کنید

بیشتر سرویس‌های موجود در فایل compose منتشرشده، محدودیت حافظهٔ صریح دارند؛ بنابراین می‌توانید پیش از اجارهٔ سرور، اندازهٔ آن را تعیین کنید. دو سرویس این محدودیت را ندارند: job یک‌بارهٔ minio-init و frontend. این اعداد، محدودیت‌های ثبت‌شده در فایل compose مربوط به v0.3.8 هستند و مصرف اندازه‌گیری‌شده را نشان نمی‌دهند.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 2048
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "postgres",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "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 به 2048 MB محدود شده است. این محدودیت روی یک فرایند Java 21 اعمال می‌شود که heap آن روی 1 GiB تنظیم شده است (-Xmx1024m با ZGC). در توضیح خود فایل compose آمده است که heap تا همان 1 GiB کامل رشد می‌کند و سربار خود JVM نیز به آن اضافه می‌شود. مجموع محدودیت 5 سرویس پایه حدود 3.6 GB است و frontend هیچ محدودیتی ندارد؛ بنابراین به‌اندازه‌ای که Node درخواست کند، حافظه مصرف می‌کند. در یک VPS با 4 GB، همین محدودیت‌ها فقط چند صد MB برای frontend، kernel و page cache باقی می‌گذارند. به همین دلیل README لانچر اکنون حداقل 6 GB را پیشنهاد می‌کند، هرچند مستندات self-hosting هنوز 4 GB را ذکر می‌کنند.

این profileهای اختیاری هستند که نیاز سرور را به 8 GB می‌رسانند. profile مربوط به browser agent یک container از نوع Chromium با سقف 2048 MB، در کنار یک نمونهٔ جست‌وجوی SearXNG، اضافه می‌کند و profile مربوط به renderer نیز 1024 MB دیگر برای screenshot و PDF اضافه می‌کند. هیچ‌کدام تا زمانی که profile مربوط به آن را فعال نکنید شروع نمی‌شوند؛ بنابراین هر دو را تا زمان نیاز غیرفعال نگه دارید. container مربوط به Chromium به‌صورت محلی از یک دایرکتوری websearch-service ساخته می‌شود که بستهٔ npm آن را همراه خود منتشر نمی‌کند. بنابراین، تا تاریخ 13 October 2026، اگر repository مربوط به GitHub در دسترس نباشد، browser agent profile را نمی‌توان از فایل‌های منتشرشده ساخت. renderer از یک image منتشرشده استفاده می‌کند و تحت تأثیر این مشکل نیست. container مربوط به SearXNG برای آن وجود دارد که backend جست‌وجوی agent باشد؛ بنابراین صفحه‌هایی که برمی‌گرداند به‌صورت متن غیرقابل‌اعتماد وارد promptهای شما می‌شوند. این همان مرز اعتماد است که دادن جست‌وجوی وب SearXNG به یک AI agent با جزئیات از طریق آن انجام می‌شود.

اگر از قبل n8n را اجرا می‌کنید، به‌جای افزودن LiveContext، برای جایگزینی آن برنامه‌ریزی کنید. stack معرفی‌شده در راهنمای ما برای اجرای n8n روی VPS با Docker و HTTPS شامل یک فرایند Node در کنار Postgres است و روی یک سرور کوچک به‌خوبی کار می‌کند. LiveContext فقط برای backend خود، منابع بیشتری از کل آن stack رزرو می‌کند. اجرای دو platform اتوماسیون روی یک VPS با 8 GB تا زمانی بدون مشکل است که هر دو در یک دقیقهٔ یکسان job اجرا نکنند. اگر قرار است host را مشترک استفاده کنید، با روش توضیح‌داده‌شده در مقالهٔ ما دربارهٔ تنظیم محدودیت حافظه در Docker Compose، برای همهٔ سرویس‌های دیگر نیز محدودیت‌های صریح تعیین کنید تا یک workflow خارج از کنترل نتواند کل ماشین را از کار بیندازد.

استقرار LiveContext با Docker Compose و pin کردن آن روی یک tag

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

README مربوط به launcher، npx livecontext@latest را به‌عنوان روش راه‌اندازی تک‌خطی ارائه می‌کند. این روش روی لپ‌تاپ مناسب است، اما launcher در هر اجرا فایل compose خود را دوباره کپی می‌کند و imageهایی که نام می‌برد با tag latest مشخص شده‌اند. روی سرور، فایل compose باید در مسیری تحت کنترل شما قرار داشته باشد و روی یک release مشخص pin شود تا بتوانید تغییرات مربوط به upgrade را با diff بررسی کنید. مستندات vendor هنوز برای این کار به git clone از repository در GitHub اشاره می‌کنند، اما این repository از تاریخ 13 October 2026 پاسخ 404 می‌دهد. بنابراین همان دو فایل، یعنی فایل compose و فایل env نمونه، را از npm package مربوط به release موردنظر دریافت کنید.

sudo apt update && sudo apt install -y npm
npm view livecontext version
mkdir -p ~/livecontext-ce/docker ~/livecontext-ce/catalog-seeds
cd ~/livecontext-ce
npm pack livecontext@0.3.8
tar xzf livecontext-0.3.8.tgz
cp package/assets/docker-compose.yml .
cp package/assets/.env.example docker/.env.ce
chmod 600 docker/.env.ce

فایل compose، ./catalog-seeds را به backend bind-mount می‌کند؛ به همین دلیل این directory در مرحله قبل ساخته شد. npm launcher در زمان start آن را با bundle مربوط به model catalog که دانلود می‌کند پر خواهد کرد و stack در ابتدا با این directory خالی شروع می‌شود.

فایل compose موجود در npm package، همه imageهای LiveContext را با tag latest نام‌گذاری می‌کند؛ برای مثال ghcr.io/livecontext-ai/livecontext-ce:latest، با این‌که comment ابتدایی خود فایل می‌گوید tag روی release pin شده است. پیش از اولین start، این مقدار را خودتان pin کنید. vendor همان tagهای release را در Docker Hub و در namespace livecontext منتشر می‌کند. در تاریخ 13 October 2026، مقدار v0.3.8 برای imageهای backend، frontend، bridge و renderer فهرست شده بود؛ بنابراین هر 4 image را به این namespace تغییر دهید:

sed -i -E 's#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v0.3.8#' docker-compose.yml
grep -n 'image:' docker-compose.yml

دریافت فایل compose از همان release مربوط به imageها باعث می‌شود این دو با یکدیگر هماهنگ بمانند، زیرا فایل compose مربوط به v0.3.8 بر اساس همان imageها نوشته شده است. tagهای latest را باقی نگذارید. یک tag از نوع latest ممکن است بدون اطلاع شما تغییر کند. همچنین backend در هر start migrationهای پایگاه داده را اجرا می‌کند؛ بنابراین یک pull ناخواسته می‌تواند schema شما را ساعت 3 بامداد جلو ببرد و تنها راه بازگشت، restore باشد.

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

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

در تمام دستورهای compose این راهنما از همان flag، یعنی --env-file، استفاده کنید. Compose در هر invocation آن فایل را از ابتدا می‌خواند؛ بنابراین دستوری که این flag را نداشته باشد به defaultهای درج‌شده در فایل compose برمی‌گردد و ممکن است portهایی متفاوت از portهای پیکربندی‌شده شما را publish کند.

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

curl -s localhost:8080/actuator/health

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

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

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

DB_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
PUBLIC_BASE_URL=https://lc.example.com
GATEWAY_PUBLIC_URL=https://lc-api.example.com

هر مقدار تصادفی را با openssl rand -base64 32 تولید کنید. نکات مهم درباره موارد مشکل‌ساز:

• DB_PASSWORD و MINIO_ROOT_PASSWORD به‌صورت پیش‌فرض با مقادیر postgres و minioadmin ارائه می‌شوند. فایل compose مقدار DB_PASSWORD را به‌عنوان POSTGRES_PASSWORD به Postgres می‌دهد. هیچ‌یک از پورت‌های database روی host منتشر نمی‌شوند؛ بنابراین مستقیماً در معرض دسترسی نیستند. اما هر container دیگری که بعداً به همان network متصل شود، می‌تواند با استفاده از مقدار پیش‌فرض مستندشده به هر دو دسترسی پیدا کند.
• CREDENTIAL_ENCRYPTION_PASSWORD و CREDENTIAL_ENCRYPTION_SALT به‌صورت comment ارائه می‌شوند و اگر خالی بمانند، در نخستین boot به‌طور خودکار تولید می‌شوند. آن‌ها را خودتان تعیین کنید. اعتبارنامه‌هایی که workflowهای شما ذخیره می‌کنند با این جفت مقدار رمزنگاری می‌شوند. بنابراین اگر database dump را روی یک box جدید بازیابی کنید، اما همان password و salt را نداشته باشید، ردیف‌های اعتبارنامه ایجادشده قابل‌خواندن نخواهند بود. این مقادیر را یک‌بار تنظیم کنید و سپس docker/.env.ce را بخشی از backup در نظر بگیرید.
• FRONTEND_PORT و BACKEND_PORT در mappingهای پورت به‌صورت ${FRONTEND_PORT:-3000}:3000 و ${BACKEND_PORT:-8080}:8080 جایگزین می‌شوند. فایل env نمونه هر دو را به‌صورت comment و با مقادیر # FRONTEND_PORT=3000 و # BACKEND_PORT=8080 ارائه می‌کند؛ بنابراین تا زمانی که خطی را برای override از حالت comment خارج نکنید، مقادیر پیش‌فرض 3000 و 8080 اعمال می‌شوند.
• PUBLIC_BASE_URL نشانی قابل‌دسترسی از طریق browser برای web UI است و فایل نمونه از نصب‌های server می‌خواهد آن را در کنار GATEWAY_PUBLIC_URL تنظیم کنند. هر دو را بدون slash انتهایی بنویسید، چون فایل نمونه هشدار می‌دهد که وجود slash انتهایی callbackهای OAuth را خراب می‌کند.
• GATEWAY_PUBLIC_URL origin قابل‌دسترسی از طریق browser برای backend است. به‌محض آن‌که reverse proxy وارد معماری شود، این مقدار اهمیت پیدا می‌کند. بخش بعدی را ببینید.
• کلیدهای model، یعنی ANTHROPIC_API_KEY، OPENAI_API_KEY، GOOGLE_API_KEY و در صورت نیاز MISTRAL_API_KEY یا DEEPSEEK_API_KEY، در اینجا به‌صورت متن ساده قرار دارند. فقط provider مورد استفاده خود را تکمیل کنید.

هفت کانتینر چه کاری انجام می‌دهند

• postgres، pgvector/pgvector:pg16 را به‌عنوان کانتینر livecontext-db اجرا می‌کند و پایگاه‌داده‌ای با نام livecontext را نگه می‌دارد. افزونهٔ pgvector برای جست‌وجوی embedding در آن فعال است؛ بنابراین image معمولی postgres:16 مناسب نیست.
• redis، redis:7-alpine را با appendonly yes و --maxmemory-policy noeviction اجرا می‌کند. این policy عمدی است: Redis در اینجا وضعیت صف و اجرا را نگه می‌دارد؛ بنابراین وقتی به سقف حافظه برسد، به‌جای حذف بی‌صدای keyها، به writer خطا برمی‌گرداند. خطایی که بتوانید ببینید، بهتر از کاری است که بدون اطلاع از بین برود.
• minio، object store سازگار با S3 برای فایل‌هایی است که در workflowها جابه‌جا می‌شوند.
• minio-init یک کانتینر یک‌باره است که هنگام startup، mc mb myminio/workflow-files --ignore-existing را اجرا می‌کند، bucket را می‌سازد و خارج می‌شود. مشاهدهٔ minio-init به‌صورت exited (0) در docker compose ps وضعیت سالم را نشان می‌دهد.
• bridge، adapterهای CLI و ابزارهای MCP (model context protocol) را نگه می‌دارد. این سرویس داخل شبکهٔ Docker روی پورت 8093 گوش می‌دهد و روی host publish نمی‌شود.
• livecontext backend است؛ یک monolith مبتنی بر Java 21 که روی پورت 8080 اجرا می‌شود. موتور workflow، schedulerها و agentها در آن اجرا می‌شوند.
• frontend رابط وب Next.js روی پورت 3000 است. فقط همین دو کانتینر آخر روی host publish می‌شوند.

وضعیت در هفت volume نام‌گذاری‌شده ذخیره می‌شود: livecontext_data برای Postgres، livecontext_redis، livecontext_minio، livecontext_keys، livecontext_bridge_secret، livecontext_cli_home و livecontext_logs. Compose نام پروژه را به ابتدای نام آن‌ها اضافه می‌کند. فایل compose نام پروژه را livecontext-ce تعیین می‌کند؛ بنابراین نام واقعی volume روی دیسک چیزی مانند livecontext-ce_livecontext_minio خواهد بود. launcher مربوط به npm این نام را با -p livecontext override می‌کند؛ بنابراین سیستمی که قبلاً npx livecontext را اجرا کرده باشد، مجموعهٔ دومی با پیشوند livecontext_ خواهد داشت. docker volume ls را اجرا کنید و پیش از نوشتن هر backup script برای آن‌ها، نام‌های دقیق را کپی کنید.

docker compose down -v هر هفت volume را حذف می‌کند. مستندات vendor می‌گویند هرگز آن را اجرا نکنید، زیرا سریع‌ترین راه برای از دست دادن تمام workflowهایی است که ساخته‌اید. -v تمام تفاوت را ایجاد می‌کند.

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

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

راه‌حل صحیح این است که هیچ پورتی را منتشر نکنید و اجازه دهید proxy از طریق یک شبکهٔ مشترک Docker به containerها دسترسی پیدا کند. docker-compose.override.yml را در کنار docker-compose.yml ایجاد کنید:

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

networks:
  proxy:
    external: true

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

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

routerها، certificate resolver و redirect از HTTP به HTTPS مانند هر برنامهٔ دیگری هستند. بنابراین به‌جای نوشتن پیکربندی TLS جدید در اینجا، راهنمای reverse proxy ما برای اجرای چند برنامه روی یک VPS با Traefik را دنبال کنید. یک hostname را روی پورت 3000 به frontend و hostname دوم را روی پورت 8080 به livecontext هدایت کنید.

hostname دوم اختیاری نیست. رابط وب، backend را از داخل browser فراخوانی می‌کند؛ بنابراین backend به origin مستقل خود نیاز دارد که browser بتواند به آن دسترسی پیدا کند. مقدار GATEWAY_PUBLIC_URL را در docker/.env.ce روی URL مربوط به backend، برای نمونه https://lc-api.example.com، قرار دهید و PUBLIC_BASE_URL را روی URL مربوط به frontend تنظیم کنید. اگر این کار را انجام ندهید، صفحه به‌طور عادی بارگذاری می‌شود، اما همهٔ عملیات شکست می‌خورند؛ زیرا UI، origin مربوط به backend را از آدرسی که با آن صفحه را باز کرده‌اید استخراج می‌کند و به پورتی فراخوانی می‌فرستد که proxy هرگز منتشر نکرده است.

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

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

عامل‌ها در همین automation اجرا می‌شوند؛ بنابراین مدل هزینه با یک workflow tool معمولی متفاوت است. کلید provider در docker/.env.ce به‌صورت ANTHROPIC_API_KEY یا OPENAI_API_KEY قرار می‌گیرد، backend و bridge آن را هنگام startup می‌خوانند و این کلید برای کل instance اعمال می‌شود. این کلید برای هر user به‌صورت جداگانه scope نمی‌شود. هر کسی که روی instance شما account داشته باشد و بتواند یک agent بسازد، از همان کلید هزینه ایجاد می‌کند؛ همچنین اولین فردی که register می‌کند، admin است. اگر به agentهای جداگانه برای هر فرد و هزینه‌ای نیاز دارید که بتوانید واقعاً به یک همکار نسبت دهید، استفاده از OneCLI به‌صورت self-hosting و به‌عنوان harnessی با یک agent برای هر فرد همین مسئله کلید را از سمت دیگری حل می‌کند؛ به این صورت که هر کلید model را پشت یک gateway قرار می‌دهد که می‌داند چه کسی درخواست را ارسال می‌کند.

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

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

از Postgres و object store نسخهٔ پشتیبان تهیه کنید

دو data store و دو محل برای نگهداری secretها وجود دارد: فایل env و volume مربوط به livecontext_keys که مستندات vendor آن را نیز در فهرست volumeهای قابل پشتیبان‌گیری آورده‌اند. از دست دادن هرکدام از این موارد به از دست رفتن instance شما منجر می‌شود. از database و bucket در یک بازهٔ زمانی یکسان نسخهٔ پشتیبان بگیرید و backend را متوقف کنید تا پس از dump شدن ردیف database، فایلی نوشته نشود.

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 قرار دهید. سپس volumeهای object store و keys را با استفاده از نام‌های دارای پیشوندی که 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 run --rm \
  -v livecontext-ce_livecontext_keys:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-keys-$(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 statement را نشان دهد، نه یک خط حاوی خطا. سپس هر چهار فایل را همراه با docker-compose.yml و فایل override از سرور خارج کنید. نسخهٔ پشتیبانی که فقط روی همان ماشینی قرار دارد که از آن محافظت می‌کند، نسخهٔ پشتیبان محسوب نمی‌شود.

برای restore روی یک سرور جدید، همان tag را نصب کنید، docker/.env.ce ذخیره‌شده را برگردانید تا password و salt مربوط به رمزنگاری credentialها یکسان بماند، stack را یک‌بار start کنید تا volumeها ایجاد شوند، backend را stop کنید، archive مربوط به keys را به همان روشی که تهیه شده بود داخل volume مربوط به keys باز کنید، سپس dump را load کنید:

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 هنگام startup migrationهای schema را اعمال می‌کند و migrationها فقط به جلو حرکت می‌کنند. بنابراین، بازگشت به tag قدیمی پس از یک ارتقای ناموفق، باعث می‌شود کد قدیمی روی schema جدید اجرا شود. rollback یعنی بازیابی dump؛ به همین دلیل dump باید در ابتدا تهیه شود.

cd ~/livecontext-ce
npm view livecontext version
TAG=0.3.8
npm pack "livecontext@$TAG"
rm -rf package && tar xzf "livecontext-$TAG.tgz"
cp docker-compose.yml docker-compose.yml.prev
cp package/assets/docker-compose.yml .
sed -i -E "s#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v$TAG#" docker-compose.yml
diff docker-compose.yml.prev docker-compose.yml
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 را روی نسخه‌ای تنظیم کنید که command دوم نمایش داد. لاگ backend را monitor کنید تا endpoint مربوط به health دوباره پاسخ دهد. docker-compose.override.yml شما بخشی از package نیست؛ بنابراین، کپی‌کردن compose file جدید آن را در جای خود حفظ می‌کند. بااین‌حال، diff نمایش‌داده‌شده توسط command diff را بخوانید، زیرا اضافه‌شدن یک service یا تغییر نام آن می‌تواند override شما را بدون نمایش هیچ پیام خطایی stale کند. docker/.env.ce را با package/assets/.env.example نیز مقایسه کنید، چون settingهای جدید در آنجا اضافه می‌شوند.

حالت‌های خرابی و رشته‌هایی که مشاهده می‌کنید

یک container مرتب restart می‌شود و docker compose ps مقدار exited (137) را نشان می‌دهد. این وضعیت مربوط به OOM killer هسته است و docker inspect livecontext-app نیز آن را با "OOMKilled": true در بخش state تأیید می‌کند. backend به limit برابر با 2048M رسیده است، یا host زودتر با کمبود memory مواجه شده است. پیش از افزایش هر limit، free -m را بررسی کنید؛ زیرا افزایش limit یک container روی hostی که memory آزاد ندارد، فقط باعث می‌شود kill به container دیگری منتقل شود.

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

Bind for 0.0.0.0:3000 failed: port is already allocated. پورت موردنظر از قبل در اختیار برنامه دیگری روی host است. مقدار FRONTEND_PORT را در docker/.env.ce تنظیم کنید، یا override بالا را اعمال کنید و هیچ چیزی را publish نکنید.

UI فعال است، اما پس از افزودن proxy، درخواست login شکست می‌خورد. مرورگر backend را روی originای فراخوانی می‌کند که proxy شما آن را سرو نمی‌کند. تب network مرورگر را باز کنید و host درخواست ناموفق را بررسی کنید. مقدار GATEWAY_PUBLIC_URL را روی URL عمومی backend تنظیم کنید و frontend container را دوباره ایجاد کنید، زیرا این مقدار هنگام startup خوانده می‌شود.

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

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

وقتی agent محور اصلی است، LiveContext را انتخاب کنید؛ یعنی می‌خواهید مدل automation را بسازد و اجرا کند و پذیرفته‌اید که یک سرور 8 GB و یک سرویس Java هزینه این انتخاب باشند. وقتی workflowهای deterministic، کتابخانه‌ای بزرگ از nodeها و footprintی می‌خواهید که یک VPS را با سرویس‌های دیگر به‌اشتراک بگذارد، n8n را انتخاب کنید. مجوزها دیگر این دو گزینه را از هم جدا نمی‌کنند. LiveContext CE از AGPL-3.0 به LiveContext Sustainable Use License 1.1 منتقل شده است؛ این مجوز source-available از همان خانواده fair-code مانند Sustainable Use License مربوط به n8n است. بنابراین پیش از آن‌که هرکدام را در اختیار فردی خارج از شرکت خود قرار دهید، محدودیت hosting را بخوانید. نسخه self-hosted n8n نیز چند قابلیت را برای مشتریان پرداخت‌کننده محفوظ نگه می‌دارد. بنابراین پیش از آن‌که workflow تیمی را بر پایه یکی از آن‌ها بسازید، بررسی کنید کدام بخش‌های n8n رایگان هستند و کدام بخش‌ها به license key نیاز دارند. شماره‌نسخه‌های اینجا جدید هستند؛ v0.3.8 در 13 October 2026. خط 0.3 نیز بین 22 September و 9 October 2026، 9 release منتشر کرده است. بنابراین نسخه را pin کنید و پیش از هر upgrade، تغییرات را بخوانید. برای بررسی گسترده‌تر، از جمله ابزارهایی که میان این دو گزینه قرار می‌گیرند، به مقایسه ما از alternativeهای self-hosted برای n8n مراجعه کنید، نه مقایسه‌ای که فقط این دو گزینه را بررسی می‌کند.

FAQ

LiveContext خودمیزبان به چه مقدار RAM نیاز دارد؟

8 GB را در نظر بگیرید. مستندات self-hosting فروشنده 4 GB را حداقل و 8 GB را مقدار پیشنهادی اعلام می‌کنند، README مربوط به launcher اکنون 6 GB را حداقل می‌داند و فایل compose ارائه‌شده نیز دلیل آن را توضیح می‌دهد: فقط backend روی 2048 MB محدود شده است و مجموع محدودیت پنج سرویس پایه، پیش از در نظر گرفتن container مربوط به frontend که محدودیتی ندارد، حدود 3.6 GB است. فعال‌کردن profile مربوط به browser agent، برای Chromium و یک container مربوط به SearXNG، 2048 MB دیگر اضافه می‌کند؛ بنابراین از آن مرحله به بعد، 8 GB دیگر اختیاری نیست.

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

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

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

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

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

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

چرا backend پس از boot، برای چند دقیقه روی health: starting باقی می‌ماند؟

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