SSD Nodes Learn 🎉 VPS เริ่ม $5.50/เดือน
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-13

วิธีติดตั้ง LiveContext ด้วยตัวเองบน VPS แบบครบวงจร

เรียนรู้วิธีติดตั้ง LiveContext CE บน Docker stack 6 คอนเทนเนอร์ พร้อมคำแนะนำการเลือก VPS ขนาด 8 GB การล็อกเวอร์ชันอิมเมจ x86_64 การตั้งค่า Traefik และวิธีสำรองข้อมูล

LiveContext คืออะไรและมีค่าใช้จ่ายในการรันเท่าใด

ในการ self-host LiveContext คุณต้องใช้ VPS ที่มี RAM ประมาณ 8 GB โดย LiveContext CE เป็นแพลตฟอร์มระบบอัตโนมัติแบบ open source ที่รัน AI agents ไว้ภายในระบบอัตโนมัติเอง และจัดส่งในรูปแบบ Docker Compose stack ที่ประกอบด้วยคอนเทนเนอร์ 6 รายการซึ่งสร้างบน Java backend เอกสาร README ของผู้พัฒนาต้นทางระบุความต้องการขั้นต่ำไว้ที่ 4 GB และแนะนำที่ 8 GB โดยไฟล์ compose จะแสดงให้เห็นว่าหน่วยความจำดังกล่าวถูกจัดสรรไปที่ใด

โครงการนี้อยู่ที่ livecontext-ai/livecontext-ce บน GitHub ภายใต้สัญญาอนุญาต AGPL-3.0 รุ่นปัจจุบัน ณ เดือนสิงหาคม 2026 คือ v0.2.11 ซึ่งเผยแพร่เมื่อวันที่ 3 สิงหาคม 2026 อิมเมจทุกรายการถูกสร้างขึ้นสำหรับ linux/amd64 เท่านั้น ซึ่งทำให้ไม่สามารถใช้กับแผนบริการราคาประหยัดที่เป็นสถาปัตยกรรม Arm ได้ คู่มือนี้จะทำการระบุ tag ดังกล่าวไว้ตายตัว พร้อมทั้งวาง stack ไว้หลัง reverse proxy และครอบคลุมขั้นตอนการสำรองข้อมูลที่เอกสารต้นทางไม่ได้ระบุไว้

การกำหนดขนาด VPS ก่อนเริ่ม self-host LiveContext

บริการทุกตัวในไฟล์ compose ที่จัดส่งมามีการกำหนดขีดจำกัดหน่วยความจำไว้อย่างชัดเจน เพื่อให้คุณสามารถประเมินขนาดของเซิร์ฟเวอร์ก่อนเช่าใช้งานได้ ค่าเหล่านี้คือขีดจำกัดที่ระบุไว้ในไฟล์ v0.2.11 compose ไม่ใช่การวัดปริมาณการใช้งานจริง

ChartMemory limits in the LiveContext CE v0.2.11 compose file, MB
The data behind this chart
[
  {
    "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 MB ขีดจำกัดนี้ครอบคลุมกระบวนการทำงานของ Java 21 ดังนั้น JVM จะขยายตัวจนเกือบเต็มขีดจำกัดและคงระดับนั้นไว้ บริการพื้นฐานทั้งห้าตัวรวมกันใช้หน่วยความจำไม่ถึง 3 GB ส่วน frontend ไม่มีการจำกัดขีดจำกัดไว้ จึงใช้ทรัพยากรตามที่ Node ร้องขอ บน VPS ขนาด 4 GB จะเหลือพื้นที่ว่างแทบไม่พอสำหรับ kernel และ page cache นี่คือเหตุผลที่ 4 GB ถูกระบุว่าเป็นค่าขั้นต่ำ ไม่ใช่ค่าที่แนะนำ

โปรไฟล์เสริมคือสิ่งที่ผลักดันให้ความต้องการของเซิร์ฟเวอร์เพิ่มขึ้นเป็น 8 GB โปรไฟล์ browser agent จะเพิ่มคอนเทนเนอร์ Chromium ที่จำกัดไว้ที่ 2048 MB ควบคู่ไปกับอินสแตนซ์การค้นหา SearXNG และโปรไฟล์ renderer จะเพิ่มอีก 1024 MB สำหรับการทำภาพหน้าจอและไฟล์ PDF ทั้งสองโปรไฟล์จะไม่เริ่มทำงานจนกว่าคุณจะเปิดใช้งาน ดังนั้นควรปิดไว้ทั้งคู่จนกว่าจะมีความจำเป็น คอนเทนเนอร์ SearXNG นั้นมีไว้เพื่อเป็น backend การค้นหาสำหรับ agent ดังนั้นหน้าเว็บที่ส่งกลับมาจะเข้าสู่ prompt ของคุณในฐานะข้อความที่ไม่น่าเชื่อถือ ซึ่งเป็นขอบเขตความปลอดภัยที่อธิบายไว้โดยละเอียดใน การให้ AI agent ใช้การค้นหาเว็บผ่าน SearXNG

หากคุณใช้งาน n8n อยู่แล้ว ให้วางแผนที่จะเปลี่ยนแทนการติดตั้งเพิ่ม stack ใน คู่มือการรัน n8n บน VPS ด้วย Docker และ HTTPS ของเรา ประกอบด้วยกระบวนการ Node หนึ่งตัวทำงานคู่กับ Postgres ซึ่งสามารถทำงานได้อย่างราบรื่นบนเซิร์ฟเวอร์ขนาดเล็ก LiveContext จองหน่วยความจำสำหรับ backend เพียงอย่างเดียวมากกว่าที่ stack ทั้งหมดนั้นใช้เสียอีก แพลตฟอร์มอัตโนมัติสองตัวบน 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 ไว้ในไดเรกทอรีที่คุณควบคุมได้ เพราะการอัปเกรดจะทำได้โดยการ 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 ได้ระบุแท็กของอิมเมจไว้ตายตัวแล้ว เช่น ghcr.io/livecontext-ai/livecontext-ce:v0.2.11 การ checkout แท็ก git ที่ตรงกันจะช่วยให้ไฟล์ compose และอิมเมจทำงานสอดคล้องกัน เนื่องจากไฟล์ compose สำหรับ v0.2.11 ถูกเขียนขึ้นมาเพื่อใช้งานกับอิมเมจเหล่านั้นโดยเฉพาะ ห้ามแก้ไขแท็กเป็น latest เพราะแท็ก latest จะมีการเปลี่ยนแปลงอยู่ตลอดเวลา และตัว backend จะรันการทำ database migration ทุกครั้งที่เริ่มทำงาน ดังนั้นการ pull โดยไม่ตั้งใจอาจทำให้ schema ของคุณถูกอัปเกรดโดยไม่คาดคิดในช่วงเวลาที่คุณไม่สามารถย้อนกลับได้นอกจากต้องกู้คืนข้อมูลเท่านั้น

แก้ไขไฟล์ docker/.env.ce ก่อนเริ่มการทำงานครั้งแรก (ส่วนถัดไปจะระบุรายการที่ต้องเปลี่ยน) จากนั้นจึงเริ่ม stack ขึ้นมา

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

ใช้แฟล็ก --env-file เดียวกันนี้กับทุกคำสั่ง compose ในคู่มือนี้ เนื่องจาก Compose จะอ่านไฟล์ใหม่ทุกครั้งที่เรียกใช้ ดังนั้นคำสั่งที่ไม่มีแฟล็กนี้จะกลับไปใช้ค่าเริ่มต้นที่ระบุในไฟล์ compose ซึ่งอาจทำให้มีการเปิดพอร์ตต่างจากที่คุณตั้งค่าไว้

การตรวจสอบ healthcheck ของ backend มีค่า start_period อยู่ที่ 120 วินาที และมีการตรวจสอบที่ /actuator/health ดังนั้น docker compose ps จะรายงานสถานะของบริการ livecontext ว่าเป็น health: starting ในช่วงประมาณสองนาทีแรกขณะที่ระบบกำลังทำ schema migration และลงทะเบียนเครื่องมือ ซึ่งถือเป็นเรื่องปกติ คุณสามารถตรวจสอบอย่างรวดเร็วจากเซิร์ฟเวอร์ได้ดังนี้:

curl -s localhost:8080/actuator/health

คำสั่งนี้ควรแสดงผลเป็น {"status":"UP"} เมื่อสถานะพร้อมแล้ว ให้เปิดเว็บ UI ที่พอร์ต 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 พอร์ตของฐานข้อมูลทั้งสองไม่ได้ถูกเปิดเผย (publish) ออกมายัง host จึงไม่มีการเข้าถึงโดยตรงจากภายนอก แต่คอนเทนเนอร์ใดก็ตามที่คุณเชื่อมต่อเข้ากับเครือข่ายเดียวกันในภายหลังจะสามารถเข้าถึงทั้งสองพอร์ตนี้ได้ด้วยค่าเริ่มต้นที่ระบุไว้
  • CREDENTIAL_ENCRYPTION_PASSWORD และ CREDENTIAL_ENCRYPTION_SALT จะถูกสร้างขึ้นโดยอัตโนมัติหากปล่อยว่างไว้ ให้คุณกำหนดค่าด้วยตนเองแทน ข้อมูลประจำตัวที่ workflow ของคุณจัดเก็บจะถูกเข้ารหัสด้วยคู่รหัสผ่านและ salt นี้ ดังนั้นหากมีการกู้คืนฐานข้อมูลบนเครื่องใหม่โดยไม่มีรหัสผ่านและ salt เดิม แถวข้อมูลประจำตัวเหล่านั้นจะไม่สามารถอ่านได้ ให้กำหนดค่าเพียงครั้งเดียวแล้วถือว่า docker/.env.ce เป็นส่วนหนึ่งของการสำรองข้อมูล
  • 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) จะถูกเก็บไว้ที่นี่ในรูปแบบข้อความธรรมดา ให้กรอกเฉพาะข้อมูลของผู้ให้บริการที่คุณใช้งานจริงเท่านั้น

หน้าที่ของคอนเทนเนอร์ทั้ง 6 รายการ

  • postgres รัน pgvector/pgvector:pg16 ในฐานะคอนเทนเนอร์ livecontext-db โดยเก็บฐานข้อมูลชื่อ livecontext เอาไว้ ส่วนขยาย pgvector ถูกติดตั้งไว้เพื่อรองรับการค้นหาแบบ embedding ดังนั้นการใช้ image postgres:16 แบบปกติทั่วไปจึงไม่สามารถใช้งานได้
  • redis รัน redis:7-alpine พร้อมด้วย appendonly yes และ --maxmemory-policy noeviction นโยบายนี้ถูกกำหนดไว้อย่างตั้งใจ เนื่องจาก Redis ทำหน้าที่เก็บคิวและสถานะการทำงานในส่วนนี้ ดังนั้นเมื่อหน่วยความจำเต็ม ระบบจะส่งข้อผิดพลาดกลับไปยังผู้เขียนแทนที่จะลบข้อมูลทิ้งโดยไม่แจ้งเตือน การเห็นข้อผิดพลาดนั้นดีกว่าการที่งานหายไปโดยไม่ทราบสาเหตุ
  • minio คือ object store ที่รองรับ S3 สำหรับไฟล์ที่ถูกประมวลผลผ่านเวิร์กโฟลว์ โดยจะมีคอนเทนเนอร์ minio-init แบบ one-shot ทำหน้าที่รัน mc mb myminio/workflow-files --ignore-existing ในช่วงเริ่มต้นเพื่อสร้าง bucket แล้วจึงปิดตัวลง การเห็นสถานะ minio-init เป็น exited (0) ใน docker compose ps ถือเป็นสถานะที่ปกติ
  • bridge เก็บ CLI adapters และเครื่องมือ MCP (model context protocol) โดยจะฟังคำสั่งที่พอร์ต 8093 ภายในเครือข่าย Docker และไม่ได้เปิดเผยพอร์ตออกสู่โฮสต์
  • livecontext คือส่วน backend ซึ่งเป็น Java 21 monolith ที่พอร์ต 8080 ทำหน้าที่รัน workflow engine, ตัวจัดตารางเวลา (schedulers) และตัวแทน (agents)
  • frontend คือ Next.js web UI ที่พอร์ต 3000 โดยมีเพียงสองรายการสุดท้ายนี้เท่านั้นที่เปิดเผยพอร์ตออกสู่โฮสต์

ข้อมูลสถานะจะถูกเก็บไว้ใน named volumes 5 รายการ ได้แก่ livecontext_data สำหรับ Postgres, livecontext_redis, livecontext_minio, livecontext_keys และ livecontext_logs โดย Compose จะใส่ชื่อโปรเจกต์นำหน้า volume เหล่านี้ ซึ่งโดยปกติจะเป็นชื่อไดเรกทอรี ดังนั้นชื่อ volume จริงบนดิสก์จะมีลักษณะคล้ายกับ livecontext-ce_livecontext_minio ให้รันคำสั่ง docker volume ls และคัดลอกชื่อที่ถูกต้องก่อนที่จะเขียนสคริปต์สำรองข้อมูลใดๆ

docker compose down -v จะลบ volume ทั้ง 5 รายการทิ้ง นี่เป็นวิธีที่ระบุไว้ในเอกสารสำหรับการเริ่มต้นใหม่ และยังเป็นวิธีที่เร็วที่สุดในการสูญเสียเวิร์กโฟลว์ทั้งหมดที่คุณสร้างขึ้นมา ดังนั้น -v จึงเป็นจุดที่สร้างความแตกต่างอย่างสิ้นเชิง

นำไปไว้หลัง Traefik แทนการเปิดพอร์ต 3000

การเปิดพอร์ต 3000 และ 8080 บน VPS สาธารณะทำให้แอปพลิเคชันไม่มี TLS (transport layer security) และไม่มีด่านหน้าสำหรับป้องกันการลงทะเบียนผู้ดูแลระบบ กฎ ufw เพียงอย่างเดียวไม่เพียงพอ เพราะ Docker จะแทรกกฎ iptables ของตนเองสำหรับพอร์ตที่เปิดไว้ก่อนหน้า chain ที่ ufw จัดการ ดังนั้นพอร์ตที่เปิดไปยัง 0.0.0.0 จึงยังคงเข้าถึงได้แม้ ufw จะปฏิเสธการเชื่อมต่อก็ตาม

วิธีแก้ไขที่ถูกต้องคือไม่ต้องเปิดพอร์ตใดๆ และปล่อยให้ proxy เข้าถึง container ผ่านเครือข่าย Docker ที่ใช้ร่วมกัน ให้สร้างไฟล์ docker-compose.override.yml ไว้ที่ root ของ repo:

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 ของแต่ละบริการ เพราะการระบุชื่อเครือข่ายใดๆ จะเป็นการแทนที่เครือข่ายเริ่มต้น ดังนั้นหากละทิ้งไปจะทำให้ frontend ไม่สามารถเชื่อมต่อกับ Postgres และ Redis ได้ ให้ยืนยันผลลัพธ์ที่รวมกันก่อนเริ่มดำเนินการใดๆ:

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

ส่วนของ routers, certificate resolver และการเปลี่ยนเส้นทางจาก HTTP ไปยัง HTTPS นั้นเหมือนกับแอปอื่นๆ ดังนั้นให้ปฏิบัติตาม คู่มือ Traefik reverse proxy สำหรับการรันหลายแอปบน VPS เดียวกันของเรา แทนการเขียน config TLS ใหม่ที่นี่ ให้กำหนดเส้นทาง hostname หนึ่งไปยัง frontend ที่พอร์ต 3000 และอีก hostname หนึ่งไปยัง livecontext ที่พอร์ต 8080

hostname ที่สองนั้นจำเป็นต้องมี เพราะ web UI จะเรียก backend จากเบราว์เซอร์ ดังนั้น backend จึงต้องมี origin ของตัวเองที่เบราว์เซอร์สามารถเข้าถึงได้ ให้ตั้งค่า GATEWAY_PUBLIC_URL ใน docker/.env.ce เป็น URL ของ backend นั้น ตัวอย่างเช่น https://lc-api.example.com หากข้ามขั้นตอนนี้ไป หน้าเว็บจะโหลดได้ตามปกติแต่ทุกการกระทำจะล้มเหลว เนื่องจาก UI จะระบุ origin ของ backend จากที่อยู่ที่คุณใช้เปิดหน้าเว็บ และพยายามเรียกไปยังพอร์ตที่ proxy ของคุณไม่ได้เปิดไว้

เนื่องจากหน้าลงทะเบียนเปิดให้ใครก็ตามที่เข้าถึงได้ก่อนใช้งานได้ จึงควรเพิ่มการยืนยันตัวตนที่ frontend router เพื่อไม่ให้ใครเห็นหน้านั้นโดยไม่ได้ผ่านการยืนยันตัวตนที่ proxy ซึ่งเป็นสิ่งที่ การรัน Authentik เป็นชั้น SSO ของคุณเอง จะช่วยเพิ่มเข้ามาบนการตั้งค่า Traefik เดิมนี้

ตำแหน่งการวาง model key และเหตุผลที่ instance ที่ไม่ได้ใช้งานยังคงมีค่าใช้จ่าย

Agent ทำงานอยู่ภายในระบบอัตโนมัติที่นี่ ซึ่งเปลี่ยนรูปแบบทางเศรษฐศาสตร์เมื่อเทียบกับเครื่องมือ workflow ทั่วไป provider key จะถูกวางไว้ใน docker/.env.ce ในรูปแบบของ ANTHROPIC_API_KEY หรือ OPENAI_API_KEY โดย backend และ bridge จะอ่านค่านี้เมื่อเริ่มต้นระบบและนำไปใช้กับทั้ง instance ไม่ได้จำกัดขอบเขตตามรายผู้ใช้ ใครก็ตามที่มีบัญชีบน instance ของคุณและสามารถสร้าง agent ได้ จะเป็นการใช้ key นี้ และบุคคลแรกที่ลงทะเบียนจะเป็นผู้ดูแลระบบ (admin)

นิสัย 3 ประการที่จะช่วยให้ค่าใช้จ่ายคาดการณ์ได้ คือ สร้าง provider key แยกต่างหากสำหรับ VPS นี้ เพื่อให้คุณสามารถเพิกถอนสิทธิ์ได้โดยไม่กระทบกับส่วนอื่น กำหนดเพดานการใช้จ่ายสูงสุด (hard spend cap) ในคอนโซลของผู้ให้บริการ เพราะขีดจำกัดนั้นเป็นเพียงสิ่งเดียวที่อยู่นอกเหนือการควบคุมของเครื่องที่คุณกำลังรักษาความปลอดภัย จากนั้นให้ใช้ credit budget ราย agent และ metrics ราย agent ที่ LiveContext เปิดเผยไว้ เพื่อป้องกันไม่ให้ loop เดียวใช้ key จนหมดก่อนที่คุณจะทันสังเกตเห็น

ค่าใช้จ่ายในช่วงที่ไม่ได้ใช้งาน (idle cost) จะไม่เป็นศูนย์เมื่อ agent ถูกตั้งค่าตามกำหนดเวลา (schedule) ตัวกระตุ้นตามกำหนดเวลา (schedule trigger) จะทำงานไม่ว่าจะมีใครเฝ้าดูอยู่หรือไม่ และทุกครั้งที่ทำงานจะมีการส่ง token เสมอ การตั้งกำหนดเวลาทุก 5 นาทีหมายถึงการทำงาน 288 ครั้งต่อวัน และ agent ที่อ่านหน้าเว็บแล้วตัดสินใจไม่ทำอะไรเลยก็ยังคงต้องเสียค่าใช้จ่ายในการอ่านหน้าเว็บนั้นอยู่ดี ให้เริ่มใช้งาน agent แรกของคุณด้วย webhook หรือ chat trigger เฝ้าดูค่าใช้จ่ายจริงเป็นเวลาหนึ่งสัปดาห์ แล้วจึงเปลี่ยนไปใช้กำหนดเวลาหลังจากที่คุณทราบค่าใช้จ่ายต่อการทำงานหนึ่งครั้งแล้ว

การสำรองข้อมูล Postgres และ object store

ข้อมูลมีแหล่งจัดเก็บ 2 แห่งและ secret อีก 1 รายการ หากสูญเสียสิ่งใดสิ่งหนึ่งไปจะทำให้ instance ของคุณใช้งานไม่ได้ ให้ทำการสำรองข้อมูลฐานข้อมูลและ bucket ในช่วงเวลาเดียวกันโดยหยุดการทำงานของ backend ไว้ก่อน เพื่อป้องกันไม่ให้มีการเขียนไฟล์หลังจากที่แถวข้อมูลในฐานข้อมูลถูกดัมพ์ออกมาแล้ว

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 โดยใช้ชื่อที่มี prefix ตามที่ 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 ไม่ใช่ข้อความแสดงข้อผิดพลาดบรรทัดเดียว จากนั้นให้คัดลอกไฟล์ทั้ง 3 ไฟล์ออกจากเซิร์ฟเวอร์ การสำรองข้อมูลที่เก็บไว้เฉพาะบนเครื่องที่ต้องการป้องกันนั้นไม่ถือว่าเป็นการสำรองข้อมูล

สำหรับการกู้คืนข้อมูลลงบนเครื่องใหม่ ให้ติดตั้ง tag เวอร์ชันเดิม นำไฟล์ docker/.env.ce ที่สำรองไว้กลับมาวางเพื่อให้รหัสผ่านและ salt ที่ใช้เข้ารหัส credential ตรงกัน เริ่มการทำงานของ stack หนึ่งครั้งเพื่อให้ volume ถูกสร้างขึ้น จากนั้นให้หยุดการทำงานของ backend แล้วจึงโหลดไฟล์ดัมพ์:

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 จะประยุกต์ใช้ schema migration เมื่อเริ่มต้นระบบ และ migration เหล่านี้จะเดินหน้าไปข้างหน้าเท่านั้น ดังนั้นการย้อนกลับไปใช้ tag เวอร์ชันเก่าหลังจากอัปเกรดล้มเหลว จะทำให้โค้ดเวอร์ชันเก่าทำงานร่วมกับ schema เวอร์ชันใหม่ การย้อนกลับ (rollback) จึงหมายถึงการกู้คืนข้อมูลจากไฟล์ dump ซึ่งเป็นเหตุผลว่าทำไมต้องสำรองข้อมูลก่อนเป็นอันดับแรก

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 ให้เป็น tag ที่คุณเลือกจากรายการที่คำสั่งที่สามแสดงผลออกมา ให้เฝ้าดู log ของ backend จนกว่า health endpoint จะตอบสนองอีกครั้ง ไฟล์ docker-compose.override.yml ของคุณจะไม่ได้ถูกติดตามโดยระบบควบคุมเวอร์ชัน ดังนั้นการใช้คำสั่ง git checkout จะคงไฟล์นั้นไว้ที่เดิม อย่างไรก็ตาม ให้ตรวจสอบความแตกต่าง (diff) ของไฟล์ docker-compose.yml ระหว่าง tag ต่างๆ เพราะการเพิ่มบริการใหม่หรือการเปลี่ยนชื่อบริการอาจทำให้ค่า override ของคุณล้าสมัยโดยไม่มีข้อความแจ้งเตือนแสดงขึ้นมา

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

คอนเทนเนอร์รีสตาร์ทตัวเองซ้ำๆ และ docker compose ps แสดงผล exited (137) นี่คือการทำงานของ kernel out-of-memory killer และ docker inspect livecontext-app จะยืนยันสาเหตุด้วย "OOMKilled": true ในบล็อกสถานะ ระบบแบ็กเอนด์ใช้งานหน่วยความจำถึงขีดจำกัดที่ 1536M หรือโฮสต์หน่วยความจำเต็มก่อน ให้ตรวจสอบ 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 ใช้งานได้ แต่คำขอเข้าสู่ระบบล้มเหลวหลังจากเพิ่มพร็อกซี เบราว์เซอร์กำลังเรียกไปยังแบ็กเอนด์ใน origin ที่พร็อกซีของคุณไม่ได้ให้บริการ ให้เปิดแท็บ network ในเบราว์เซอร์แล้วดู host ของคำขอที่ล้มเหลว จากนั้นตั้งค่า GATEWAY_PUBLIC_URL ให้เป็น URL สาธารณะของแบ็กเอนด์และสร้างคอนเทนเนอร์ frontend ขึ้นมาใหม่ เนื่องจากค่านี้จะถูกอ่านเฉพาะตอนเริ่มต้นระบบเท่านั้น

ทุกอย่างทำงานปกติ แต่ไฟล์ที่อัปโหลดในเวิร์กโฟลว์หายไป ตรวจสอบว่า minio-init แสดงผลเป็น exited (0) แทนที่จะเป็นรหัสอื่นที่ไม่ใช่ศูนย์ หาก bucket workflow-files ไม่เคยถูกสร้างขึ้น แบ็กเอนด์จะไม่มีที่สำหรับจัดเก็บออบเจกต์เหล่านั้น

เลือกระหว่าง LiveContext หรือ n8n

เลือก LiveContext เมื่อตัวแทน (agent) คือหัวใจสำคัญ: คุณต้องการให้โมเดลสร้างและรันระบบอัตโนมัติ และยอมรับการใช้ทรัพยากรขนาด 8 GB รวมถึงบริการ Java ได้ เลือก n8n เมื่อคุณต้องการเวิร์กโฟลว์ที่กำหนดผลลัพธ์ได้แน่นอน (deterministic) มีไลบรารีโหนดจำนวนมาก และต้องการใช้ทรัพยากรในระดับที่สามารถแชร์ VPS ร่วมกับบริการอื่นได้ หมายเลขเวอร์ชันในขณะนี้ยังถือว่าใหม่ v0.2.11 ณ เดือนสิงหาคม 2026 ดังนั้นควรระบุ tag ให้ชัดเจนและอ่าน release notes ก่อนการอัปเกรดทุกครั้ง สำหรับตัวเลือกที่กว้างขึ้น รวมถึงเครื่องมือที่อยู่กึ่งกลางระหว่างสองตัวเลือกนี้ โปรดดู บทสรุปทางเลือก n8n แบบ self-hosted ของเรา แทนการอ่านการเปรียบเทียบเพียงสองตัวเลือกนี้เท่านั้น

FAQ

LiveContext ที่โฮสต์เองต้องใช้ RAM เท่าไร?

ควรวางแผนไว้ที่ 8 GB โดย README ของต้นทางระบุว่า 4 GB คือขั้นต่ำและ 8 GB คือค่าที่แนะนำ ซึ่งไฟล์ compose ที่มาพร้อมกับซอฟต์แวร์ก็กำหนดไว้เช่นนั้น โดยตัว backend เพียงอย่างเดียวถูกจำกัดไว้ที่ 1536 MB และบริการพื้นฐานทั้ง 5 รายการรวมกันใช้พื้นที่ไม่ถึง 3 GB ก่อนที่จะรวม container ของ frontend ที่ไม่มีการจำกัด RAM หากเปิดใช้งานโปรไฟล์ browser agent จะต้องใช้เพิ่มอีก 2048 MB สำหรับ Chromium และ container ของ SearXNG ดังนั้นที่ระดับนี้ 8 GB จึงไม่ใช่ตัวเลือกเสริมอีกต่อไป

ฉันสามารถรัน LiveContext บน Arm VPS ได้หรือไม่?

ไม่ได้ อิมเมจที่เผยแพร่ทั้งหมดถูกสร้างมาสำหรับ linux/amd64 ดังนั้นการรัน docker compose up บนแผนบริการที่เป็น Arm จะล้มเหลวในขั้นตอนการ pull ด้วยข้อผิดพลาด no matching manifest for linux/arm64/v8 in the manifest list entries การรันผ่านการจำลอง QEMU อาจเป็นไปได้ในทางทฤษฎี แต่ใช้งานจริงไม่ได้สำหรับภาระงานที่เป็น JVM ควรเลือกแผนบริการที่เป็น x86

ฉันต้องวาง API key ของโมเดลไว้ที่ไหน?

ให้วางไว้ใน docker/.env.ce ในรูปแบบของ ANTHROPIC_API_KEY, OPENAI_API_KEY หรือ GOOGLE_API_KEY ก่อนการเริ่มระบบครั้งแรก ทั้ง backend และ bridge จะอ่านค่านี้ในตอนเริ่มต้น และจะมีผลกับทั้ง instance แทนที่จะเป็นรายผู้ใช้ ควรตั้งค่าไฟล์ให้เป็นโหมด 600 ใช้คีย์ที่สร้างขึ้นสำหรับเซิร์ฟเวอร์นี้โดยเฉพาะเพื่อให้สามารถเพิกถอนได้แยกต่างหาก และตั้งค่าเพดานการใช้จ่ายในคอนโซลของผู้ให้บริการไว้ด้วย เนื่องจากเพดานนั้นเป็นข้อจำกัดเดียวที่อยู่นอกเหนือการควบคุมของเครื่อง

ฉันจะสำรองข้อมูล LiveContext ได้อย่างไร?

มี 3 สิ่งที่ต้องทำ: ทำ 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 และการลงทะเบียนเครื่องมือ (tool registration) กำลังดำเนินการอยู่ การรอ 2 ถึง 3 นาทีในการบูตครั้งแรกถือเป็นเรื่องปกติ หากสถานะไม่เปลี่ยนเป็น healthy ให้ตรวจสอบ docker compose logs -f livecontext สแต็กที่ค้างอยู่ในขั้นตอนการย้ายข้อมูลมักเกิดจากการชี้ไปยัง volume ของฐานข้อมูลที่มาจากซอฟต์แวร์เวอร์ชันที่ใหม่กว่า

#livecontext#n8n#docker-compose#self-hosting#ai-agents#automation