Cara Hos Sendiri LiveContext: Panduan Docker Stack

Apakah itu LiveContext dan kos untuk menjalankannya

Untuk mengehos sendiri LiveContext, anda memerlukan VPS dengan kira-kira 8 GB RAM. LiveContext CE ialah platform automasi sumber tersedia yang menjalankan ejen AI di dalam automasi itu sendiri. Ia diedarkan sebagai timbunan Docker Compose yang terdiri daripada tujuh kontena yang dibina di sekitar backend Java, dengan salah satunya merupakan tugas sekali jalan yang akan tamat selepas persediaan selesai. Dokumentasi pengehosan sendiri daripada vendor meminta minimum 4 GB dan 8 GB disyorkan. README pelancar npm miliknya kini menyatakan minimum 6 GB, dan fail compose menunjukkan ke mana peruntukan memori tersebut pergi.

Projek ini diterbitkan sebagai livecontext-ai/livecontext-ce di GitHub di bawah AGPL-3.0, namun CE kini bukan lagi AGPL. Lesen yang disertakan dengan keluaran semasa ialah LiveContext Sustainable Use License 1.1, iaitu lesen sumber tersedia yang membenarkan anda menjalankan dan mengubah suai CE, termasuk dalam pengeluaran di dalam perniagaan anda sendiri, tetapi melarang penawaran perkhidmatan tersebut kepada pihak ketiga secara hos atau terbenam untuk bersaing dengan versi berbayar LiveContext. Pelancar npm vendor menunjukkan perubahan tersebut: livecontext@0.2.11 mengisytiharkan AGPL-3.0-only, manakala livecontext@0.3.8 menghala ke fail lesen tersebut. Setakat 13 Oktober 2026, repositori GitHub dan organisasi livecontext-ai kedua-duanya memaparkan ralat 404, walaupun dokumentasi vendor masih mengarahkan anda untuk melakukan klon. Oleh itu, panduan ini mengambil fail keluaran daripada pakej npm sebagai ganti. Keluaran semasa ialah v0.3.8, yang diterbitkan pada 9 Oktober 2026. Setiap imej LiveContext dibina untuk linux/amd64 sahaja, yang mengecualikan pelan Arm yang murah. Panduan ini menetapkan tag tersebut, meletakkan timbunan di belakang reverse proxy, dan menukarkan nasihat sandaran upstream kepada bentuk arahan.

Tentukan saiz VPS sebelum anda melakukan self-host LiveContext

Kebanyakan servis dalam fail compose yang dibekalkan mempunyai had memori yang jelas, jadi anda boleh menentukan saiz pelayan sebelum menyewanya. Terdapat dua servis yang tidak mempunyai had: tugasan minio-init sekali jalan dan frontend. Had ini ditulis ke dalam fail compose v0.3.8, bukannya penggunaan yang diukur.

[
  {
    "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 sahaja dihadkan kepada 2048 MB. Had tersebut diletakkan ke atas proses Java 21 yang heap-nya ditetapkan pada 1 GiB (-Xmx1024m dengan ZGC), dan komen dalam fail compose itu sendiri menyatakan bahawa heap akan berkembang sehingga 1 GiB penuh, dengan tambahan overhead daripada JVM. Lima servis asas dengan had tersebut berjumlah kira-kira 3.6 GB, dan frontend tidak mempunyai sebarang had, jadi ia mengambil apa sahaja yang diminta oleh Node. Pada VPS 4 GB, had tersebut sahaja hanya meninggalkan beberapa ratus MB untuk frontend, kernel dan page cache, itulah sebabnya README pelancar kini menetapkan minimum pada 6 GB walaupun dokumentasi self-hosting masih menyatakan 4 GB.

Profil pilihan adalah perkara yang menolak keperluan pelayan kepada 8 GB. Profil ejen pelayar menambah kontena Chromium yang dihadkan kepada 2048 MB di sebelah instans carian SearXNG, dan profil renderer menambah lagi 1024 MB untuk tangkapan skrin dan PDF. Tiada satu pun yang bermula melainkan anda mendayakan profilnya, jadi biarkan kedua-duanya dimatikan sehingga anda memerlukannya. Kontena Chromium dibina secara setempat daripada direktori websearch-service yang tidak disertakan dalam pakej npm, jadi dengan repositori GitHub tidak boleh dicapai, profil ejen pelayar tidak boleh dibina daripada fail yang diterbitkan setakat 13 Oktober 2026. Renderer menggunakan imej yang diterbitkan dan tidak terjejas. Kontena SearXNG itu wujud untuk menjadi backend carian ejen tersebut, jadi halaman yang dikembalikannya sampai ke dalam prompt anda sebagai teks yang tidak dipercayai, iaitu sempadan kepercayaan yang memberikan ejen AI carian web SearXNG terangkan dengan terperinci.

Jika anda sudah menjalankan n8n, rancang untuk menggantikannya dan bukannya menambah beban kepadanya. Stak dalam panduan kami untuk menjalankan n8n pada VPS dengan Docker dan HTTPS adalah satu proses Node di sebelah Postgres, dan ia selesa pada pelayan kecil. LiveContext menempah lebih banyak memori untuk backend-nya sahaja berbanding keseluruhan stak tersebut. Dua platform automasi pada satu VPS 8 GB akan muat sehingga kedua-duanya menjalankan tugasan pada minit yang sama. Jika anda berkongsi hos, letakkan had yang jelas pada semua perkara lain juga, menggunakan kaedah dalam siaran kami tentang menetapkan had memori dalam Docker Compose, supaya satu aliran kerja yang tidak terkawal tidak menjatuhkan mesin tersebut.

Memasang LiveContext dengan Docker Compose, dipinkan pada tag

Mulakan dengan VPS Ubuntu 24.04 yang bersih, menggunakan Docker Engine 24 atau lebih baharu serta Compose v2. Jika Docker belum dipasang, ikuti asas Docker Compose kami untuk VPS terlebih dahulu, kemudian kembali ke sini.

README pelancar menawarkan npx livecontext@latest sebagai permulaan satu baris. Ini sesuai pada komputer riba, namun pelancar tersebut menyalin semula fail compose setiap kali dijalankan dan imej yang dinamakan ditag sebagai latest. Pada pelayan, anda mahukan fail compose berada dalam direktori yang anda kawal, dipinkan pada satu keluaran (release), supaya naik taraf (upgrade) menjadi fail yang boleh anda buat perbandingan (diff). Dokumentasi vendor masih menerangkan git clone bagi repositori GitHub untuk tujuan ini, namun repositori tersebut memaparkan ralat 404 setakat 13 Oktober 2026. Oleh itu, ambil dua fail yang sama, iaitu fail compose dan fail env contoh, daripada pakej npm keluaran yang anda mahukan.

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

Fail compose melakukan bind-mount pada ./catalog-seeds ke dalam backend, itulah sebabnya direktori tersebut dicipta di atas. Pelancar npm mengisinya dengan bundle katalog model yang dimuat turun semasa permulaan, dan stack bermula dalam keadaan kosong.

Fail compose dalam pakej npm menamakan setiap imej LiveContext dengan tag latest, contohnya ghcr.io/livecontext-ai/livecontext-ce:latest, walaupun komen pengepala (header) menyatakan tag tersebut dipinkan pada keluaran berkenaan. Pin sendiri tag tersebut sebelum permulaan pertama. Vendor menerbitkan tag keluaran yang sama di Docker Hub di bawah namespace livecontext, di mana v0.3.8 disenaraikan untuk imej backend, frontend, bridge dan renderer pada 13 Oktober 2026, jadi halakan keempat-empat imej tersebut ke sana:

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

Mengambil fail compose daripada keluaran yang sama dengan imej adalah cara untuk memastikan kedua-duanya selari, kerana fail compose untuk v0.3.8 ditulis berdasarkan imej tersebut. Jangan biarkan tag pada latest. Tag latest akan berubah tanpa pengetahuan anda, dan backend menjalankan migrasi pangkalan data setiap kali ia bermula. Oleh itu, penarikan (pull) secara tidak sengaja boleh mengubah skema anda pada pukul 3 pagi tanpa cara untuk kembali kecuali melalui pemulihan (restore).

Edit docker/.env.ce sebelum permulaan pertama (bahagian seterusnya menyenaraikan perkara yang perlu diubah), kemudian naikkan stack tersebut.

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

Gunakan flag --env-file yang sama pada setiap arahan compose dalam panduan ini. Compose membaca fail tersebut semula pada setiap panggilan. Oleh itu, arahan tanpa flag tersebut akan kembali kepada tetapan lalai yang terbina dalam fail compose dan mungkin menerbitkan port yang berbeza daripada yang anda konfigurasikan.

Healthcheck backend mempunyai start_period selama 120s dan meninjau /actuator/health, jadi docker compose ps melaporkan servis livecontext sebagai health: starting untuk kira-kira dua minit pertama sementara migrasi skema dan pendaftaran alat dijalankan. Ini adalah perkara biasa. Semakan pantas daripada pelayan:

curl -s localhost:8080/actuator/health

Ini sepatutnya mencetak {"status":"UP"}. Apabila ia muncul, buka UI web pada port 3000. Akaun pertama yang anda cipta menjadi admin, dan pendaftaran awam akan ditutup selepas itu melainkan admin membukanya semula. Jadi, cipta akaun anda sebelum port tersebut boleh dicapai oleh orang lain. Ini adalah sebab paling penting untuk tidak menerbitkan port 3000 ke internet pada hari pertama.

Nilai env yang perlu anda ubah

Fail contoh disertakan dengan tetapan lalai yang berfungsi supaya stack boleh dimulakan pada komputer riba. Beberapa daripadanya tidak selamat pada pelayan awam.

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

Jana setiap nilai rawak dengan openssl rand -base64 32. Nota mengenai nilai yang kritikal:

• DB_PASSWORD dan MINIO_ROOT_PASSWORD disertakan sebagai postgres dan minioadmin. Fail compose menghantar DB_PASSWORD kepada Postgres sebagai POSTGRES_PASSWORD miliknya. Tiada port pangkalan data yang diterbitkan ke hos, jadi ia tidak terdedah secara terus, tetapi mana-mana container yang anda sambungkan kemudian ke rangkaian yang sama boleh mencapai kedua-duanya dengan nilai lalai yang didokumentasikan.
• CREDENTIAL_ENCRYPTION_PASSWORD dan CREDENTIAL_ENCRYPTION_SALT disertakan dalam keadaan dikomen dan dijana secara automatik pada but pertama jika dibiarkan kosong. Tetapkan nilai tersebut sendiri. Kredensial yang disimpan oleh aliran kerja anda disulitkan dengan pasangan tersebut, jadi dump pangkalan data yang dipulihkan pada kotak baharu tanpa kata laluan dan salt yang sama akan menyebabkan baris kredensial tidak dapat dibaca oleh sesiapa. Tetapkan sekali sahaja, kemudian anggap docker/.env.ce sebagai sebahagian daripada sandaran.
• FRONTEND_PORT dan BACKEND_PORT digantikan ke dalam pemetaan port sebagai ${FRONTEND_PORT:-3000}:3000 dan ${BACKEND_PORT:-8080}:8080. Fail env contoh menyertakan kedua-duanya dalam keadaan dikomen, sebagai # FRONTEND_PORT=3000 dan # BACKEND_PORT=8080, jadi nilai lalai 3000 dan 8080 akan digunakan sehingga anda membuang komen pada baris tersebut untuk mengatasi nilai itu.
• PUBLIC_BASE_URL ialah alamat UI web yang menghadap pelayar, dan fail contoh meminta pemasangan pelayan untuk menetapkannya bersama GATEWAY_PUBLIC_URL. Tulis kedua-duanya tanpa garis miring (trailing slash) di hujung, kerana fail contoh memberi amaran bahawa satu daripadanya akan merosakkan callback OAuth.
• GATEWAY_PUBLIC_URL ialah origin backend yang menghadap pelayar. Ia menjadi penting sebaik sahaja reverse proxy terlibat. Lihat bahagian seterusnya.
• Kunci model (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, dan secara pilihan MISTRAL_API_KEY atau DEEPSEEK_API_KEY) disimpan di sini dalam teks biasa. Isikan hanya penyedia yang anda gunakan.

Fungsi tujuh kontena tersebut

• postgres menjalankan pgvector/pgvector:pg16 sebagai kontena livecontext-db, yang menyimpan pangkalan data bernama livecontext. Sambungan pgvector disertakan untuk carian embedding, jadi imej postgres:16 biasa tidak mencukupi.
• redis menjalankan redis:7-alpine dengan appendonly yes dan --maxmemory-policy noeviction. Polisi tersebut adalah sengaja: Redis membawa baris gilir dan status larian di sini, jadi apabila ia mencapai had memori, ia akan mengembalikan ralat kepada penulis dan bukannya membuang kunci secara senyap. Ralat yang boleh dilihat adalah lebih baik daripada kerja yang hilang begitu sahaja.
• minio ialah storan objek yang serasi dengan S3 untuk fail yang bergerak melalui aliran kerja.
• minio-init ialah kontena sekali jalan yang menjalankan mc mb myminio/workflow-files --ignore-existing semasa permulaan, mencipta baldi (bucket), dan kemudian berhenti. Melihat minio-init sebagai exited (0) dalam docker compose ps adalah status yang sihat.
• bridge menyimpan penyesuai CLI dan alatan MCP (model context protocol). Ia mendengar pada port 8093 di dalam rangkaian Docker dan tidak diterbitkan ke hos.
• livecontext ialah bahagian belakang (backend), satu monolit Java 21 pada port 8080. Ia menjalankan enjin aliran kerja, penjadual, dan ejen.
• frontend ialah UI web Next.js pada port 3000. Hanya dua yang terakhir ini diterbitkan ke hos.

Status disimpan dalam tujuh volum bernama: livecontext_data untuk Postgres, livecontext_redis, livecontext_minio, livecontext_keys, livecontext_bridge_secret, livecontext_cli_home, dan livecontext_logs. Compose meletakkan awalan nama projek pada volum tersebut, yang ditetapkan oleh fail compose kepada livecontext-ce, jadi volum sebenar pada cakera dinamakan seperti livecontext-ce_livecontext_minio. Pelancar npm mengatasi nama tersebut dengan -p livecontext, jadi kotak yang pernah menjalankan npx livecontext membawa set kedua dengan awalan livecontext_. Jalankan docker volume ls dan salin nama yang tepat sebelum anda menulis sebarang skrip sandaran terhadapnya.

docker compose down -v memadamkan kesemua tujuh volum. Dokumentasi vendor menyatakan jangan sekali-kali menjalankannya, kerana ia adalah cara terpantas untuk kehilangan setiap aliran kerja yang anda bina. -v adalah perbezaan keseluruhannya.

Letakkan di belakang Traefik dan bukannya mendedahkan port 3000

Mendedahkan port 3000 dan 8080 pada VPS awam akan mendedahkan aplikasi tanpa TLS (transport layer security) dan tanpa kawalan akses di hadapan pendaftaran admin. Peraturan ufw sahaja tidak mencukupi, kerana Docker memasukkan peraturan iptables miliknya sendiri untuk port yang didedahkan sebelum rantaian yang diuruskan oleh ufw. Oleh itu, port yang didedahkan kepada 0.0.0.0 kekal boleh dicapai walaupun ufw menyatakan port tersebut dinafikan.

Penyelesaian yang kemas adalah dengan tidak mendedahkan sebarang port dan membiarkan proksi mencapai kontena melalui rangkaian Docker yang dikongsi. Cipta docker-compose.override.yml bersebelahan dengan docker-compose.yml:

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

networks:
  proxy:
    external: true

Dua perincian menentukan sama ada ini berfungsi. !override menggantikan senarai ports dan bukannya bergabung dengannya, yang memerlukan Compose v2.24 atau lebih baharu: semak dengan docker compose version, kerana pada Compose yang lebih lama, kedua-dua senarai akan bergabung dan port kekal didedahkan. Selain itu, default mesti kekal dalam setiap senarai networks, kerana menamakan mana-mana rangkaian akan menggantikan rangkaian lalai. Jika ia ditinggalkan, backend akan terputus daripada Postgres dan Redis, manakala frontend akan terputus daripada backend. Sahkan hasil gabungan sebelum memulakan apa-apa:

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

Router, penyelesai sijil dan pengalihan HTTP ke HTTPS adalah sama seperti aplikasi lain. Oleh itu, ikuti panduan reverse proxy Traefik kami untuk menjalankan berbilang aplikasi pada satu VPS dan bukannya menulis konfigurasi TLS baharu di sini. Halakan satu hostname ke frontend pada port 3000 dan satu lagi ke livecontext pada port 8080.

Hostname kedua adalah wajib. UI web memanggil backend daripada pelayar, jadi backend memerlukan origin sendiri yang boleh dicapai oleh pelayar. Tetapkan GATEWAY_PUBLIC_URL dalam docker/.env.ce kepada URL backend tersebut, contohnya https://lc-api.example.com, dan PUBLIC_BASE_URL kepada URL frontend. Jika dilangkau, halaman akan dimuatkan seperti biasa tetapi setiap tindakan akan gagal, kerana UI menyelesaikan origin backend daripada alamat yang anda buka dan sedang memanggil port yang tidak pernah didedahkan oleh proksi anda.

Memandangkan halaman pendaftaran terbuka kepada sesiapa sahaja yang mencapainya terlebih dahulu, adalah wajar untuk meletakkan pengesahan di hadapan router frontend supaya tiada sesiapa yang melihat halaman tersebut tanpa mengesahkan diri di proksi. Inilah yang ditambah oleh menjalankan Authentik sebagai lapisan SSO anda sendiri di atas persediaan Traefik yang sama.

Lokasi kunci model dan sebab instans melahu tetap dikenakan bayaran

Ejen berjalan di dalam automasi di sini. Keadaan ini mengubah ekonomi penggunaan berbanding alat aliran kerja biasa. Kunci pembekal disimpan dalam docker/.env.ce sebagai ANTHROPIC_API_KEY atau OPENAI_API_KEY. Kunci itu dibaca oleh backend dan bridge semasa permulaan, lalu digunakan untuk seluruh instance. Kunci tersebut tidak dikhususkan mengikut pengguna. Sesiapa yang mempunyai akaun pada instance anda dan boleh membina ejen akan menggunakan kunci itu. Pengguna pertama yang mendaftar ialah admin. Jika anda memerlukan ejen bagi setiap individu serta perbelanjaan yang boleh dikaitkan dengan rakan sekerja tertentu, self-hosting OneCLI sebagai harness satu ejen bagi setiap individu menangani masalah kunci yang sama dari sudut lain. Setiap kunci model diletakkan di belakang gateway yang mengenal pasti pihak yang membuat panggilan.

Tiga tabiat memastikan bil anda boleh diramal. Cipta kunci pembekal yang berasingan untuk VPS ini supaya anda boleh membatalkannya tanpa menjejaskan perkara lain. Tetapkan had perbelanjaan yang ketat dalam konsol pembekal, kerana had tersebut adalah satu-satunya kawalan di luar mesin yang anda lindungi. Kemudian, gunakan bajet kredit setiap ejen dan metrik setiap ejen yang didedahkan oleh LiveContext, supaya satu gelung tidak boleh menghabiskan kunci tersebut sebelum anda menyedarinya.

Kos melahu tidak menjadi sifar sebaik sahaja ejen diletakkan pada jadual. Pencetus jadual akan berfungsi sama ada seseorang memantaunya atau tidak, dan setiap pencetusan akan menghantar token. Jadual lima minit bermakna 288 pelaksanaan sehari, dan ejen yang membaca halaman serta memutuskan untuk tidak melakukan apa-apa tetap perlu membayar untuk membaca halaman tersebut. Letakkan ejen pertama anda pada webhook atau pencetus sembang, pantau perbelanjaan sebenar selama seminggu, dan beralih kepada jadual selepas anda mengetahui kos bagi setiap pelaksanaan.

Sandarkan Postgres dan storan objek

Terdapat dua storan data serta dua lokasi yang menyimpan rahsia, iaitu fail env dan volum livecontext_keys, yang disenaraikan oleh dokumentasi vendor sebagai volum yang perlu disandarkan. Kehilangan mana-mana daripadanya akan menyebabkan kehilangan instans anda. Lakukan sandaran pangkalan data dan bucket dalam tetingkap masa yang sama, dengan backend dihentikan, supaya fail tidak boleh ditulis selepas baris pangkalan datanya disalin (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

Gunakan apa sahaja yang anda tetapkan sebagai DB_USERNAME sebagai ganti postgres jika anda telah mengubahnya. Kemudian, salin storan objek dan volum kunci, menggunakan nama berprefiks yang dipaparkan oleh 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)

Pastikan fail dump tidak kosong sebelum anda mempercayainya: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 sepatutnya menunjukkan pernyataan CREATE TABLE dan DROP TABLE, bukan ralat satu baris. Kemudian, salin kesemua empat fail keluar dari pelayan, bersama-sama dengan docker-compose.yml dan fail override anda. Sandaran yang hanya disimpan pada mesin yang dilindunginya bukanlah sandaran yang sebenar.

Untuk memulihkan ke mesin baharu, pasang tag yang sama, letakkan semula docker/.env.ce yang telah disimpan supaya kata laluan penyulitan kelayakan dan salt sepadan, mulakan stack sekali supaya volum wujud, hentikan backend, nyahzip arkib kunci ke dalam volum kunci dengan cara yang sama ia diambil, kemudian muatkan fail dump tersebut:

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

Naik taraf, dan cara pemulihan apabila berlaku kegagalan

Sentiasa lakukan dump data terlebih dahulu. Backend akan melaksanakan migrasi skema semasa permulaan dan migrasi hanya bergerak ke hadapan. Oleh itu, kembali kepada tag lama selepas naik taraf yang gagal akan menyebabkan kod lama berjalan pada skema yang lebih baharu. Rollback bermaksud memulihkan dump tersebut, itulah sebabnya dump perlu dilakukan terlebih dahulu.

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

Tetapkan TAG kepada versi yang dipaparkan oleh arahan kedua. Pantau log backend sehingga endpoint kesihatan memberikan respons semula. docker-compose.override.yml anda bukan sebahagian daripada pakej, jadi menyalin fail compose baharu akan mengekalkannya di tempat asal. Walau bagaimanapun, baca diff yang dicetak oleh arahan diff, kerana servis baharu atau servis yang dinamakan semula boleh menyebabkan override anda menjadi lapuk tanpa sebarang mesej ralat. Bandingkan docker/.env.ce dengan package/assets/.env.example juga, kerana tetapan baharu mungkin disertakan di sana.

Mod kegagalan, berserta rentetan yang akan anda lihat

Bekas (container) terus dimulakan semula dan docker compose ps menunjukkan exited (137). Ini adalah kernel out-of-memory killer, dan docker inspect livecontext-app mengesahkannya dengan "OOMKilled": true dalam blok status. Bahagian backend telah mencapai had 2048M, atau hos kehabisan memori terlebih dahulu. Semak free -m sebelum menaikkan sebarang had, kerana menaikkan had bekas pada hos yang tidak mempunyai ruang memori tambahan hanya akan memindahkan tindakan penamatan (kill) tersebut ke bekas yang lain.

Proses pull gagal dengan no matching manifest for linux/arm64/v8 in the manifest list entries. Imej tersebut diterbitkan untuk linux/amd64 sahaja. VPS Arm tidak boleh menjalankan stack ini daripada imej yang diterbitkan, dan emulasi melalui QEMU adalah terlalu perlahan untuk JVM serta Chromium. Beralih kepada pelan x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Sesuatu yang lain pada hos sudah menggunakan port tersebut. Tetapkan FRONTEND_PORT dalam docker/.env.ce, atau gunakan override di atas dan jangan terbitkan apa-apa.

UI aktif tetapi permintaan log masuk gagal selepas anda menambah proksi. Pelayar sedang memanggil backend pada origin yang tidak diservis oleh proksi anda. Buka tab rangkaian pelayar dan lihat hos permintaan yang gagal. Tetapkan GATEWAY_PUBLIC_URL kepada URL backend awam dan cipta semula bekas frontend, kerana nilai tersebut dibaca semasa permulaan.

Semuanya sihat tetapi fail yang dimuat naik dalam aliran kerja hilang. Semak sama ada minio-init menunjukkan exited (0) dan bukannya kod bukan sifar. Jika bucket workflow-files tidak pernah dicipta, backend tidak mempunyai tempat untuk meletakkan objek.

Pilih antara LiveContext atau n8n

Pilih LiveContext apabila fokus utama adalah ejen: anda mahu model tersebut membina dan menjalankan automasi, serta anda menerima penggunaan pelayan 8 GB dan servis Java sebagai kosnya. Pilih n8n apabila anda mahukan aliran kerja yang deterministik, pustaka nod yang besar, dan jejak memori yang membolehkan VPS dikongsi dengan servis lain. Lesen kini tidak lagi membezakan kedua-duanya. LiveContext CE telah beralih daripada AGPL-3.0 kepada LiveContext Sustainable Use License 1.1, iaitu lesen sumber tersedia daripada keluarga kod saksama (fair-code) yang sama seperti Lesen Penggunaan Mampan n8n, jadi baca sekatan pengehosan sebelum anda menawarkan mana-mana daripadanya kepada pihak luar syarikat anda. n8n yang dihoskan sendiri juga mengehadkan beberapa ciri untuk pelanggan berbayar, jadi semak bahagian n8n yang percuma dan yang memerlukan kunci lesen sebelum anda membina aliran kerja pasukan menggunakan salah satu daripadanya. Nombor versi di sini masih baharu, v0.3.8 setakat 13 Oktober 2026, dan siri 0.3 telah mengeluarkan sembilan release antara 22 September dan 9 Oktober 2026, jadi tetapkan (pin) versi anda dan baca perubahan yang dibuat sebelum setiap naik taraf. Untuk gambaran yang lebih luas, termasuk alatan yang berada di antara kedua-dua kedudukan ini, lihat rumusan kami mengenai alternatif n8n yang dihoskan sendiri daripada hanya membaca perbandingan antara kedua-duanya sahaja.

FAQ

Berapakah jumlah RAM yang diperlukan oleh LiveContext yang dihoskan sendiri?

Rancang untuk 8 GB. Dokumentasi self-hosting daripada vendor menyenaraikan 4 GB sebagai minimum dan 8 GB sebagai saranan, README pelancar kini menyatakan 6 GB sebagai minimum, dan fail compose yang dibekalkan menjelaskan sebabnya: backend sahaja dihadkan pada 2048 MB, dan lima servis asas dengan had tersebut berjumlah kira-kira 3.6 GB sebelum mengambil kira kontena frontend yang tidak mempunyai had. Mendayakan profil ejen pelayar menambah lagi 2048 MB untuk Chromium serta satu kontena SearXNG, jadi 8 GB bukan lagi pilihan pada tahap tersebut.

Bolehkah saya menjalankan LiveContext pada VPS Arm?

Tidak. Setiap imej LiveContext yang diterbitkan untuk v0.3.8 dibina untuk linux/amd64, jadi docker compose up pada pelan Arm akan gagal semasa proses pull dengan no matching manifest for linux/arm64/v8 in the manifest list entries. Menjalankannya di bawah emulasi QEMU mungkin secara teori, tetapi tidak praktikal untuk beban kerja JVM. Pilih pelan x86.

Di manakah saya perlu meletakkan kunci API model saya?

Di dalam docker/.env.ce, sebagai ANTHROPIC_API_KEY, OPENAI_API_KEY atau GOOGLE_API_KEY, sebelum permulaan pertama. Backend dan bridge membacanya semasa permulaan, dan ia terpakai untuk keseluruhan instans dan bukannya untuk seorang pengguna sahaja. Pastikan fail tersebut berada pada mod 600, gunakan kunci yang dicipta khusus untuk pelayan ini supaya anda boleh membatalkannya secara berasingan, dan tetapkan had perbelanjaan dalam konsol pembekal, kerana had tersebut adalah satu-satunya had yang berada di luar mesin.

Bagaimanakah cara untuk membuat sandaran LiveContext?

Empat perkara: pg_dump bagi pangkalan data livecontext, salinan volum MinIO, salinan volum livecontext_keys, dan fail docker/.env.ce. Hentikan servis livecontext dan frontend semasa anda melakukan dump dan salinan volum supaya pangkalan data dan storan objek selari antara satu sama lain. Fail env adalah penting kerana kelayakan yang disimpan dalam aliran kerja anda disulitkan dengan CREDENTIAL_ENCRYPTION_PASSWORD dan CREDENTIAL_ENCRYPTION_SALT, jadi pemulihan tanpa nilai tersebut akan meninggalkan baris kelayakan yang tidak boleh dibaca oleh mana-mana sistem pada mesin baharu.

Mengapakah backend berada pada health: starting selama beberapa minit selepas but?

Healthcheck compose menetapkan start_period: 120s dan meninjau /actuator/health, jadi Docker melaporkan servis sebagai sedang bermula sementara migrasi skema dan pendaftaran alatan dijalankan. Dua hingga tiga minit pada but pertama adalah perkara biasa. Jika ia tidak pernah menjadi sihat, baca docker compose logs -f livecontext. Stack yang terhenti pada langkah migrasi biasanya merujuk kepada volum pangkalan data daripada keluaran yang lebih baharu.