Self-Host LiveContext: Alternatif n8n dengan Docker

Apa itu LiveContext dan biaya untuk menjalankannya

Untuk melakukan self-hosting LiveContext, Anda memerlukan VPS dengan RAM sekitar 8 GB. LiveContext CE adalah platform otomasi open source yang menjalankan agen AI di dalam otomasi itu sendiri. Platform ini dirilis sebagai stack Docker Compose yang terdiri dari enam container dan dibangun di atas backend Java. README upstream menetapkan 4 GB sebagai minimum dan 8 GB sebagai rekomendasi. File compose menunjukkan alokasi memori tersebut.

Proyek ini tersedia di livecontext-ai/livecontext-ce pada GitHub dan dilisensikan berdasarkan AGPL-3.0. Rilis saat ini per Agustus 2026 adalah v0.2.11, yang diterbitkan pada 3 Agustus 2026. Setiap image hanya dibuat untuk linux/amd64. Karena itu, paket Arm yang murah tidak dapat digunakan. Panduan ini menetapkan tag tersebut, menempatkan stack di balik reverse proxy, dan mencakup prosedur pencadangan yang tidak disertakan dalam dokumentasi upstream.

Tentukan ukuran VPS sebelum melakukan self-hosting LiveContext

Setiap service dalam file compose yang disediakan memiliki batas memori eksplisit, sehingga Anda dapat menentukan ukuran server sebelum menyewanya. Batas ini ditetapkan dalam file compose v0.2.11, bukan hasil pengukuran penggunaan aktual.

[
  {
    "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 saja dibatasi hingga 1536 MB. Batas tersebut berlaku di atas proses Java 21, sehingga JVM akan menggunakan sebagian besar kapasitas itu dan mempertahankannya. Lima service dasar menggunakan total sedikit di bawah 3 GB, sedangkan frontend tidak memiliki batas sama sekali sehingga menggunakan kapasitas sesuai permintaan Node. Pada VPS 4 GB, kondisi ini hampir tidak menyisakan memori untuk kernel dan page cache. Karena itu, 4 GB ditulis sebagai kapasitas minimum, bukan rekomendasi.

Profil opsional yang membuat kebutuhan server meningkat hingga 8 GB. Profil browser agent menambahkan container Chromium yang dibatasi hingga 2048 MB, bersama satu instance pencarian SearXNG. Profil renderer menambahkan lagi 1024 MB untuk screenshot dan PDF. Keduanya tidak akan dijalankan sebelum Anda mengaktifkan profil masing-masing. Karena itu, biarkan keduanya nonaktif sampai diperlukan. Container SearXNG tersebut berfungsi sebagai backend pencarian agent. Halaman yang dikembalikannya masuk ke prompt Anda sebagai teks yang tidak tepercaya. Inilah batas kepercayaan yang dijelaskan secara terperinci dalam memberikan pencarian web SearXNG kepada agent AI.

Jika Anda sudah menjalankan n8n, rencanakan untuk menggantinya, bukan menambahkannya. Stack dalam panduan kami untuk menjalankan n8n pada VPS dengan Docker dan HTTPS terdiri dari satu proses Node dan Postgres, serta dapat berjalan dengan baik pada server kecil. LiveContext membutuhkan memori lebih besar hanya untuk backend-nya dibandingkan seluruh stack tersebut. Dua platform otomasi pada satu VPS 8 GB akan tetap berjalan sampai keduanya menjalankan job pada menit yang sama. Jika Anda menggunakan satu host bersama, tetapkan juga batas eksplisit untuk semua service lain dengan metode dalam artikel kami tentang menetapkan batas memori di Docker Compose. Dengan demikian, satu workflow yang tidak terkendali tidak dapat membuat seluruh mesin berhenti.

Instal LiveContext dengan Docker Compose, menggunakan tag yang ditetapkan

Mulai dari VPS Ubuntu 24.04 yang bersih dengan Docker Engine 24 atau yang lebih baru dan Compose v2. Jika Docker belum terinstal, ikuti panduan dasar Docker Compose untuk VPS kami terlebih dahulu, lalu kembali ke sini.

README menyediakan npx livecontext sebagai perintah untuk memulai dalam satu baris. Cara ini cukup untuk laptop. Pada server, simpan file compose dalam direktori yang Anda kelola. Dengan demikian, proses upgrade cukup dilakukan melalui checkout git dan Anda dapat melihat perubahan secara tepat.

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

File compose sudah menetapkan setiap image ke tag rilisnya, misalnya ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Checkout ke tag git yang sesuai menjaga agar file compose dan image tetap selaras, karena file compose untuk v0.2.11 dibuat untuk image tersebut. Jangan ubah tag menjadi latest. Tag latest dapat berubah tanpa Anda sadari, dan backend menjalankan migrasi database setiap kali dimulai. Akibatnya, pull yang tidak disengaja dapat memajukan skema Anda pada pukul 3 pagi tanpa opsi pemulihan selain restore.

Edit docker/.env.ce sebelum memulai untuk pertama kali. Bagian berikutnya menjelaskan perubahan yang perlu dilakukan. Setelah itu, jalankan stack.

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 perintah compose dalam panduan ini. Compose membaca ulang file tersebut setiap kali perintah dijalankan. Karena itu, perintah tanpa flag akan menggunakan default yang tertanam dalam file compose dan dapat memublikasikan port yang berbeda dari konfigurasi Anda.

Healthcheck backend memiliki start_period sebesar 120s dan melakukan polling ke /actuator/health. Karena itu, docker compose ps melaporkan service livecontext sebagai health: starting selama sekitar dua menit pertama, saat migrasi skema dan pendaftaran tool berjalan. Ini normal. Pemeriksaan cepat dari server:

curl -s localhost:8080/actuator/health

Perintah ini seharusnya mencetak {"status":"UP"}. Setelah itu, buka UI web pada port 3000. Akun pertama yang Anda buat menjadi admin, jadi buat akun Anda sebelum port tersebut dapat diakses orang lain. Ini adalah alasan terpenting untuk tidak memublikasikan port 3000 ke Internet sejak hari pertama.

Nilai env yang harus Anda ubah

File contoh menyediakan nilai default yang berfungsi agar stack dapat dijalankan di laptop. Beberapa di antaranya tidak aman untuk server publik.

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

Buat setiap nilai acak dengan openssl rand -base64 32. Perhatikan nilai-nilai berikut:

• POSTGRES_PASSWORD dan MINIO_ROOT_PASSWORD disediakan dengan nilai postgres dan minioadmin. Tidak ada port database yang dipublikasikan ke host, sehingga keduanya tidak terekspos secara langsung. Namun, container apa pun yang nantinya Anda hubungkan ke network yang sama dapat mengakses keduanya menggunakan default yang didokumentasikan.
• CREDENTIAL_ENCRYPTION_PASSWORD dan CREDENTIAL_ENCRYPTION_SALT dibuat secara otomatis jika dibiarkan kosong. Tetapkan sendiri nilainya. Kredensial yang disimpan oleh workflow Anda dienkripsi menggunakan pasangan tersebut. Jika database dump dipulihkan pada mesin baru tanpa password dan salt yang sama, tidak ada yang dapat membaca baris kredensial tersebut. Tetapkan nilainya satu kali, lalu perlakukan docker/.env.ce sebagai bagian dari backup.
• FRONTEND_PORT dan BACKEND_PORT disubstitusikan ke dalam pemetaan port sebagai ${FRONTEND_PORT:-3000}:3000 dan ${BACKEND_PORT:-8080}:8080. File env contoh menetapkan keduanya secara eksplisit, dan nilai yang disediakannya tidak selalu 3000 dan 8080. Baca salinan file Anda, jangan berasumsi.
• GATEWAY_PUBLIC_URL adalah origin backend yang diakses browser. Nilai ini menjadi penting segera setelah reverse proxy digunakan. Lihat bagian berikutnya.
• Key model (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, dan secara opsional MISTRAL_API_KEY atau DEEPSEEK_API_KEY) disimpan dalam file ini sebagai teks biasa. Isi hanya provider yang benar-benar Anda gunakan.

Fungsi keenam container

• postgres menjalankan pgvector/pgvector:pg16 sebagai container livecontext-db yang menyimpan database bernama livecontext. Ekstensi pgvector digunakan untuk pencarian embedding, sehingga image postgres:16 biasa tidak dapat digunakan.
• redis menjalankan redis:7-alpine dengan appendonly yes dan --maxmemory-policy noeviction. Kebijakan ini disengaja: Redis menyimpan status antrean dan eksekusi di sini. Saat batas memorinya tercapai, Redis mengembalikan error kepada penulis, bukan menghapus key secara diam-diam. Error yang dapat dilihat lebih baik daripada pekerjaan yang hilang tanpa jejak.
• minio adalah object store yang kompatibel dengan S3 untuk file yang diproses dalam workflow. Container minio-init yang dijalankan sekali menjalankan mc mb myminio/workflow-files --ignore-existing saat startup, membuat bucket, lalu berhenti. Jika minio-init terlihat sebagai exited (0) dalam docker compose ps, berarti kondisinya sehat.
• bridge menyimpan adapter CLI dan tool MCP (model context protocol). Container ini listen pada port 8093 di dalam jaringan Docker dan tidak dipublikasikan ke host.
• livecontext adalah backend, yaitu satu monolit Java 21 pada port 8080. Backend ini menjalankan workflow engine, scheduler, dan agent.
• frontend adalah web UI Next.js pada port 3000. Hanya dua container terakhir ini yang dipublikasikan ke host.

State disimpan dalam lima volume bernama: livecontext_data untuk Postgres, livecontext_redis, livecontext_minio, livecontext_keys, dan livecontext_logs. Compose menambahkan nama project sebagai prefix, yang secara default menggunakan nama direktori. Karena itu, nama volume sebenarnya pada disk akan tampak seperti livecontext-ce_livecontext_minio. Jalankan docker volume ls dan salin nama persisnya sebelum menulis script backup yang menggunakannya.

docker compose down -v menghapus kelima volume. Perintah ini adalah cara yang didokumentasikan untuk memulai dari awal, tetapi juga merupakan cara tercepat untuk kehilangan semua workflow yang telah Anda buat. -v adalah satu-satunya pembeda.

Letakkan di belakang Traefik, bukan dengan memublikasikan port 3000

Memublikasikan port 3000 dan 8080 pada VPS publik mengekspos aplikasi tanpa TLS (transport layer security) dan tanpa gerbang sebelum pendaftaran admin. Aturan ufw saja tidak cukup, karena Docker menyisipkan aturan iptables-nya sendiri untuk port yang dipublikasikan sebelum chain yang dikelola ufw. Akibatnya, port yang dipublikasikan ke 0.0.0.0 tetap dapat dijangkau meskipun ufw menyatakan port tersebut ditolak.

Solusi yang tepat adalah tidak memublikasikan port apa pun dan membiarkan proxy menjangkau container melalui jaringan Docker bersama. Buat docker-compose.override.yml di root repositori:

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

networks:
  proxy:
    external: true

Dua detail menentukan apakah konfigurasi ini berfungsi. !override menggantikan daftar ports, bukan menggabungkannya. Fitur ini memerlukan Compose v2.24 atau yang lebih baru. Periksa versinya dengan docker compose version, karena pada Compose versi lama kedua daftar akan digabungkan dan port tetap dipublikasikan. Selain itu, default harus tetap ada di setiap daftar networks. Menentukan jaringan apa pun akan menggantikan jaringan default. Jika bagian ini dihilangkan, frontend tidak dapat terhubung ke Postgres dan Redis. Pastikan hasil penggabungannya sebelum menjalankan apa pun:

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

Router, resolver sertifikat, dan pengalihan HTTP ke HTTPS sama seperti pada aplikasi lain. Ikuti panduan reverse proxy Traefik kami untuk menjalankan beberapa aplikasi pada satu VPS, bukan menulis konfigurasi TLS baru di sini. Arahkan satu hostname ke frontend pada port 3000 dan hostname kedua ke livecontext pada port 8080.

Hostname kedua wajib ada. Web UI memanggil backend dari browser, sehingga backend memerlukan origin sendiri yang dapat dijangkau browser. Atur GATEWAY_PUBLIC_URL di docker/.env.ce ke URL backend tersebut, misalnya https://lc-api.example.com. Jika bagian ini dilewati, halaman akan dimuat secara normal, tetapi setiap tindakan akan gagal. UI mendapatkan origin backend dari alamat yang Anda buka dan memanggil port yang tidak pernah dipublikasikan oleh proxy.

Karena halaman pendaftaran terbuka bagi siapa pun yang mencapainya terlebih dahulu, sebaiknya gunakan forward auth pada router frontend. Dengan begitu, tidak ada pengguna yang dapat melihat halaman tersebut sebelum melakukan autentikasi pada proxy. Inilah tambahan yang diberikan oleh menjalankan Authentik sebagai lapisan SSO Anda sendiri di atas konfigurasi Traefik yang sama.

Model key disimpan di mana dan mengapa instance yang menganggur tetap menimbulkan biaya

Agent berjalan di dalam automation ini, sehingga perhitungannya berbeda dari workflow tool biasa. Provider key disimpan di docker/.env.ce sebagai ANTHROPIC_API_KEY atau OPENAI_API_KEY, dibaca oleh backend dan bridge saat startup, serta berlaku untuk seluruh instance. Key ini tidak dibatasi per pengguna. Siapa pun yang memiliki akun pada instance Anda dan dapat membuat agent akan menggunakan key tersebut, dan orang pertama yang mendaftar menjadi admin.

Tiga kebiasaan berikut membantu menjaga biaya tetap dapat diprediksi. Buat provider key terpisah untuk VPS ini agar Anda dapat mencabutnya tanpa memengaruhi hal lain. Tetapkan batas pengeluaran yang tegas di konsol provider, karena batas tersebut adalah satu-satunya batas di luar mesin yang Anda amankan. Kemudian gunakan anggaran kredit per-agent dan metrik per-agent yang disediakan LiveContext, sehingga satu loop tidak menghabiskan key sebelum Anda menyadarinya.

Biaya tidak menjadi nol ketika agent berjalan berdasarkan schedule. Pemicu schedule tetap berjalan meskipun tidak ada orang yang memantaunya, dan setiap eksekusi mengirimkan token. Schedule setiap lima menit menghasilkan 288 eksekusi per hari, dan agent yang membaca halaman lalu memutuskan untuk tidak melakukan apa pun tetap menimbulkan biaya untuk membaca halaman tersebut. Jalankan agent pertama Anda dengan webhook atau pemicu chat, pantau pengeluaran aktual selama satu minggu, lalu gunakan schedule setelah Anda mengetahui biaya per eksekusi.

Cadangkan Postgres dan penyimpanan objek

Ada dua penyimpanan data dan satu rahasia. Kehilangan salah satunya berarti kehilangan instance Anda. Cadangkan database dan bucket dalam jangka waktu yang sama, dengan backend dihentikan. Dengan demikian, tidak ada file yang dapat ditulis setelah baris database untuk file tersebut dicadangkan.

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 nilai yang Anda tetapkan sebagai DB_USERNAME sebagai pengganti postgres jika nilainya telah diubah. Kemudian salin volume penyimpanan objek menggunakan nama dengan prefiks yang ditampilkan 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 compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

Pastikan dump tidak kosong sebelum mempercayainya: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 harus menampilkan pernyataan CREATE TABLE dan DROP TABLE, bukan error satu baris. Kemudian salin ketiga file tersebut keluar dari server. Cadangan yang hanya berada di mesin yang dilindunginya bukanlah cadangan.

Untuk memulihkan data ke server baru, instal tag yang sama, kembalikan docker/.env.ce yang telah disimpan agar kata sandi dan salt enkripsi kredensial cocok, jalankan stack sekali agar volume dibuat, hentikan backend, lalu muat 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

Upgrade dan pemulihan jika terjadi kegagalan

Selalu buat dump terlebih dahulu. Backend menerapkan migrasi skema saat startup, dan migrasi hanya bergerak maju. Karena itu, melakukan checkout ke tag yang lebih lama setelah upgrade yang gagal akan membuat kode lama berjalan pada skema yang lebih baru. Rollback berarti memulihkan dump. Itulah alasan dump harus dibuat terlebih dahulu.

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

Atur TAG ke tag yang Anda pilih dari daftar yang ditampilkan oleh perintah ketiga. Pantau log backend sampai endpoint health kembali memberikan respons. docker-compose.override.yml Anda tidak dilacak, sehingga git checkout akan membiarkannya tetap ada. Namun, baca diff pada docker-compose.yml antartag karena service baru atau service yang berganti nama dapat membuat override Anda menjadi usang tanpa pesan error.

Mode kegagalan dan string yang akan Anda lihat

Sebuah container terus melakukan restart dan docker compose ps menampilkan exited (137). Itu adalah mekanisme kernel out-of-memory killer. docker inspect livecontext-app mengonfirmasinya dengan "OOMKilled": true pada blok status. Backend mencapai batas 1536M, atau host kehabisan memori terlebih dahulu. Periksa free -m sebelum menaikkan batas apa pun. Menaikkan batas container pada host yang tidak memiliki memori cadangan hanya memindahkan proses penghentian ke container lain.

Proses pull gagal dengan no matching manifest for linux/arm64/v8 in the manifest list entries. Image hanya diterbitkan untuk linux/amd64. VPS Arm tidak dapat menjalankan stack ini dari image yang diterbitkan. Emulasi melalui QEMU terlalu lambat untuk JVM dan Chromium. Gunakan paket x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Port tersebut sudah digunakan oleh proses lain pada host. Ubah FRONTEND_PORT di docker/.env.ce, atau terapkan override di atas dan jangan publikasikan port apa pun.

UI sudah berjalan, tetapi permintaan login gagal setelah Anda menambahkan proxy. Browser memanggil backend melalui origin yang tidak dilayani oleh proxy Anda. Buka tab network pada browser dan periksa host permintaan yang gagal. Atur GATEWAY_PUBLIC_URL ke URL backend publik, lalu buat ulang container frontend karena nilai tersebut dibaca saat startup.

Semua komponen sehat, tetapi file yang diunggah dalam workflow menghilang. Periksa apakah minio-init menampilkan exited (0), bukan kode selain nol. Jika bucket workflow-files belum pernah dibuat, backend tidak memiliki lokasi untuk menyimpan object.

Pilih LiveContext atau n8n

Pilih LiveContext jika agen menjadi pusat proses: Anda ingin model membangun dan menjalankan otomatisasi, serta menerima kebutuhan server 8 GB dan service Java sebagai konsekuensinya. Pilih n8n jika Anda menginginkan workflow deterministik, pustaka node yang besar, dan footprint yang dapat berbagi VPS dengan service lain. Nomor versi di sini masih baru, v0.2.11 per Agustus 2026, jadi tetapkan tag dan baca catatan rilis sebelum setiap upgrade. Untuk cakupan yang lebih luas, termasuk tool yang berada di antara kedua pilihan ini, lihat rangkuman alternatif n8n self-hosted kami, bukan perbandingan yang hanya membahas keduanya.

FAQ

Berapa RAM yang dibutuhkan LiveContext yang di-hosting sendiri?

Siapkan 8 GB. README upstream mencantumkan 4 GB sebagai minimum dan 8 GB sebagai rekomendasi. File compose yang disertakan juga mengikuti ketentuan tersebut: backend saja dibatasi hingga 1536 MB, sedangkan lima service dasar secara keseluruhan menggunakan sedikit di bawah 3 GB sebelum container frontend yang tidak dibatasi. Mengaktifkan profil browser agent menambahkan 2048 MB untuk Chromium serta satu container SearXNG. Pada titik itu, 8 GB bukan lagi pilihan.

Apakah LiveContext dapat dijalankan pada VPS Arm?

Tidak. Setiap image yang dipublikasikan dibuat untuk linux/amd64. Karena itu, docker compose up pada paket Arm gagal saat proses pull dengan no matching manifest for linux/arm64/v8 in the manifest list entries. Menjalankannya melalui emulasi QEMU secara teori memungkinkan, tetapi dalam praktiknya tidak layak untuk beban kerja JVM. Pilih paket x86.

Di mana saya harus menyimpan API key model?

Simpan di docker/.env.ce sebagai ANTHROPIC_API_KEY, OPENAI_API_KEY, atau GOOGLE_API_KEY sebelum start pertama. Backend dan bridge membacanya saat startup, dan key tersebut berlaku untuk seluruh instance, bukan hanya untuk satu user. Pertahankan mode file pada 600. Gunakan key yang dibuat khusus untuk server ini agar dapat dicabut secara terpisah. Tetapkan batas pengeluaran di konsol provider karena batas tersebut adalah satu-satunya pembatas yang berada di luar mesin.

Bagaimana cara mencadangkan LiveContext?

Ada tiga hal: sebuah pg_dump dari database livecontext, salinan volume MinIO, dan file docker/.env.ce. Hentikan service livecontext dan frontend saat mengambil dua cadangan pertama agar database dan object store tetap konsisten. File env juga penting karena kredensial yang disimpan dalam workflow Anda dienkripsi dengan CREDENTIAL_ENCRYPTION_PASSWORD dan CREDENTIAL_ENCRYPTION_SALT. Tanpa nilai tersebut, proses pemulihan akan menyisakan baris kredensial yang tidak dapat dibaca oleh apa pun pada server baru.

Mengapa backend berada pada health: starting selama beberapa menit setelah boot?

Healthcheck compose menetapkan start_period: 120s dan melakukan polling terhadap /actuator/health. Karena itu, Docker melaporkan service sebagai starting selama migrasi skema dan registrasi tool berjalan. Durasi dua hingga tiga menit pada boot pertama adalah normal. Jika statusnya tidak pernah berubah menjadi healthy, baca docker compose logs -f livecontext. Stack yang berhenti pada langkah migrasi biasanya mengarah ke volume database dari release yang lebih baru.