LiveContext Kendi Sunucunuzda Nasıl Barındırılır?

LiveContext nedir ve çalıştırma maliyeti

LiveContext'i kendi sunucunuzda barındırmak için yaklaşık 8 GB RAM kapasiteli bir VPS gereklidir. LiveContext CE, otomasyon süreçlerinin içinde yapay zeka ajanlarını çalıştıran açık kaynaklı bir otomasyon platformudur ve Java tabanlı bir arka uç etrafında yapılandırılmış altı container'lık bir Docker Compose yığını olarak sunulur. Kaynak README dosyası minimum 4 GB, önerilen olarak ise 8 GB RAM talep eder; compose dosyası bu belleğin nereye harcandığını gösterir.

Proje GitHub üzerinde livecontext-ai/livecontext-ce adresindedir ve AGPL-3.0 lisansı ile lisanslanmıştır. Ağustos 2026 itibarıyla güncel sürüm v0.2.11 olup 3 Ağustos 2026 tarihinde yayımlanmıştır. Her imaj yalnızca linux/amd64 mimarisi için derlenmiştir; bu durum ucuz Arm planlarının kullanımını imkansız kılar. Bu kılavuz, ilgili etiketi sabitler, yığını bir reverse proxy arkasına alır ve kaynak belgelerde yer almayan yedekleme prosedürünü açıklar.

LiveContext self-host işlemi öncesinde VPS boyutlandırma

Dağıtılan compose dosyasındaki her servis, açık bir bellek sınırına sahiptir; bu sayede sunucuyu kiralamadan önce boyutlandırma yapabilirsiniz. Bunlar, ölçülen kullanım değil, v0.2.11 compose dosyasına yazılan sınırlardır.

[
  {
    "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
  }
]

Yalnızca backend, 1536 MB ile sınırlandırılmıştır. Bu sınır bir Java 21 süreci üzerinde yer aldığından, JVM bu alanın büyük kısmını kullanacak ve orada kalacaktır. Beş temel servis toplamda 3 GB'ın biraz altında bir alan kaplar; frontend için herhangi bir sınır tanımlanmamıştır, bu nedenle Node ne kadar talep ederse o kadarını kullanır. 4 GB'lık bir VPS üzerinde çekirdek ve sayfa önbelleği (page cache) için neredeyse hiç alan kalmaz; bu nedenle 4 GB bir öneri değil, minimum gereksinim olarak belirtilmiştir.

Sunucuyu 8 GB'a çıkaran unsurlar isteğe bağlı profillerdir. Tarayıcı aracısı (browser agent) profili, bir SearXNG arama örneğinin yanında 2048 MB ile sınırlandırılmış bir Chromium container'ı ekler; oluşturucu (renderer) profili ise ekran görüntüleri ve PDF'ler için ek 1024 MB daha ekler. Profiller etkinleştirilmediği sürece hiçbiri başlamaz, bu yüzden ihtiyaç duyana kadar her ikisini de kapalı tutun. SearXNG container'ı, aracının arama backend'i olarak görev yapar; bu nedenle döndürdüğü sayfalar istemlerinize güvenilmeyen metin olarak ulaşır. Bu durum, bir yapay zeka aracısına SearXNG web araması verme konusunda detaylıca ele alınan güven sınırını oluşturur.

Halihazırda n8n çalıştırıyorsanız, onu eklemek yerine değiştirmeyi planlayın. Docker ve HTTPS ile VPS üzerinde n8n çalıştırma rehberimizdeki yığın, Postgres'in yanında tek bir Node sürecinden oluşur ve küçük bir sunucuda rahatlıkla çalışır. LiveContext, yalnızca backend'i için o yığının tamamından daha fazla bellek ayırır. İki otomasyon platformu aynı 8 GB'lık VPS üzerinde, her ikisi de aynı anda bir iş çalıştırana kadar sorunsuz barınabilir. Eğer bir sunucuyu paylaşımlı kullanacaksanız, Docker Compose'da bellek sınırları belirleme yazımızdaki yöntemi kullanarak diğer her şeye açık sınırlar koyun; böylece kontrolden çıkan bir iş akışı makineyi devre dışı bırakamaz.

Docker Compose ile LiveContext kurulumu ve sürüm sabitleme

İşlemlere Docker Engine 24 veya daha yeni bir sürüm ile Compose v2 yüklü, temiz bir Ubuntu 24.04 VPS üzerinde başlayın. Eğer Docker henüz yüklü değilse, önce VPS için Docker Compose temelleri rehberimizi takip edin ve ardından buraya dönün.

README dosyası, tek satırlık bir başlangıç komutu olarak npx livecontext seçeneğini sunar. Bu, yerel bilgisayarlar için uygundur. Bir sunucuda ise compose dosyasının kontrolünüz altındaki bir dizinde bulunması gerekir; böylece yükseltme işlemi bir git checkout komutuna dönüşür ve tam olarak nelerin değiştiğini inceleyebilirsiniz.

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 dosyası, her imajı kendi sürüm etiketine (tag) sabitler; örneğin ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Compose dosyası ile imajların uyumlu kalmasını sağlayan şey, eşleşen git etiketine geçiş yapmaktır; çünkü v0.2.11 sürümüne ait compose dosyası bu imajlarla çalışacak şekilde yazılmıştır. Etiketleri latest olarak değiştirmeyin. Bir latest etiketi sizin bilginiz dışında değişebilir ve arka uç (backend) her başlatmada veritabanı migrasyonlarını çalıştırır. Bu durum, yanlışlıkla yapılan bir pull işlemiyle veritabanı şemanızın gece yarısı geri dönüşü olmayan bir şekilde güncellenmesine yol açabilir.

İlk başlatmadan önce docker/.env.ce dosyasını düzenleyin (bir sonraki bölümde nelerin değiştirilmesi gerektiği listelenmiştir), ardından stack'i ayağa kaldırın.

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

Bu rehberdeki her compose komutunda aynı --env-file bayrağını kullanın. Compose, her çağrıda bu dosyayı yeniden okur. Bayrağın kullanılmadığı bir komut, compose dosyasına gömülü varsayılan değerlere döner ve yapılandırdığınızdan farklı portlar yayınlayabilir.

Arka uç sağlık kontrolü (healthcheck) 120 saniyelik bir start_period süresine sahiptir ve /actuator/health adresini sorgular. Bu nedenle, şema migrasyonları ve araç kaydı tamamlanana kadar, yani yaklaşık ilk iki dakika boyunca docker compose ps komutu livecontext servisini health: starting olarak raporlar. Bu normal bir durumdur. Sunucu üzerinden hızlı bir kontrol:

curl -s localhost:8080/actuator/health

Bu komut {"status":"UP"} çıktısını vermelidir. Çıktı alındığında, 3000 numaralı port üzerinden web arayüzünü açın. Oluşturduğunuz ilk hesap yönetici (admin) olur, bu yüzden portu başkalarının erişimine açmadan önce kendi hesabınızı oluşturun. Bu, 3000 numaralı portu ilk günden internete açmamanız için en önemli nedendir.

Değiştirmeniz gereken env değerleri

Örnek dosya, yığının bir dizüstü bilgisayarda çalışabilmesi için işlevsel varsayılanlarla gelir. Bunların birçoğu halka açık bir sunucuda güvensizdir.

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

Her rastgele değeri openssl rand -base64 32 ile oluşturun. Sorun yaratabilecek olanlara dair notlar:

• POSTGRES_PASSWORD ve MINIO_ROOT_PASSWORD, postgres ve minioadmin olarak gelir. Veritabanı portlarının hiçbiri ana makineye (host) yayınlanmaz, bu nedenle doğrudan dışarıya açık değillerdir; ancak daha sonra aynı ağa bağladığınız herhangi bir container, belgelenmiş varsayılan değerlerle her ikisine de erişebilir.
• CREDENTIAL_ENCRYPTION_PASSWORD ve CREDENTIAL_ENCRYPTION_SALT boş bırakıldığında otomatik olarak oluşturulur. Bunun yerine kendiniz ayarlayın. İş akışlarınızın depoladığı kimlik bilgileri bu çift ile şifrelenir; dolayısıyla aynı parola ve salt değeri olmadan yeni bir makineye geri yüklenen bir veritabanı yedeği, okunamaz kimlik bilgisi satırları ile sonuçlanır. Bunları bir kez ayarlayın ve ardından docker/.env.ce değerini yedeğin bir parçası olarak saklayın.
• FRONTEND_PORT ve BACKEND_PORT, port eşlemelerinde ${FRONTEND_PORT:-3000}:3000 ve ${BACKEND_PORT:-8080}:8080 olarak kullanılır. Örnek env dosyası her ikisini de açıkça ayarlar ve gelen değerler her zaman 3000 ve 8080 değildir. Varsayımda bulunmak yerine kendi kopyanızı okuyun.
• GATEWAY_PUBLIC_URL, backend'in tarayıcıya bakan kökenidir (origin). Bir reverse proxy dahil olduğunda önem kazanır. Bir sonraki bölüme bakın.
• Model anahtarları (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY ve isteğe bağlı olarak MISTRAL_API_KEY veya DEEPSEEK_API_KEY) burada düz metin olarak bulunur. Yalnızca gerçekten kullandığınız sağlayıcıyı doldurun.

Altı container'ın işlevi

• postgres, livecontext adlı veritabanını barındıran livecontext-db container'ı olarak pgvector/pgvector:pg16 çalıştırır. Gömülü arama (embedding search) için pgvector eklentisi gereklidir, bu nedenle standart bir postgres:16 imajı yeterli olmaz.
• redis, appendonly yes ve --maxmemory-policy noeviction ile redis:7-alpine çalıştırır. Bu politika bilinçli olarak seçilmiştir: Redis burada kuyruk ve çalışma durumunu tutar; bellek sınırına ulaştığında anahtarları sessizce silmek yerine yazma işlemine hata döndürür. Görünür bir hata, kaybolan bir işten daha iyidir.
• minio, iş akışları boyunca taşınan dosyalar için S3 uyumlu nesne deposudur. Başlangıçta çalışan tek seferlik bir minio-init container'ı, mc mb myminio/workflow-files --ignore-existing komutunu çalıştırarak bucket'ı oluşturur ve sonlanır. docker compose ps içerisinde minio-init değerini exited (0) olarak görmek, sistemin sağlıklı çalıştığı anlamına gelir.
• bridge, CLI adaptörlerini ve MCP (model context protocol) araçlarını barındırır. Docker ağı içerisinde 8093 numaralı portu dinler ve ana makineye (host) açılmaz.
• livecontext, 8080 numaralı portta çalışan Java 21 tabanlı backend monolitidir. İş akışı motorunu, zamanlayıcıları ve aracıları çalıştırır.
• frontend, 3000 numaralı portta çalışan Next.js web arayüzüdür. Yalnızca bu son iki servis ana makineye açılmıştır.

Veri, beş adet isimlendirilmiş volume içerisinde tutulur: Postgres için livecontext_data, ayrıca livecontext_redis, livecontext_minio, livecontext_keys ve livecontext_logs. Compose, bu volume'lerin başına varsayılan olarak dizin adından oluşan proje adını ekler; bu nedenle diskteki gerçek volume adı livecontext-ce_livecontext_minio benzeri bir isim alır. Yedekleme betiği yazmadan önce docker volume ls komutunu çalıştırın ve tam isimleri kopyalayın.

docker compose down -v, beş volume'ün tamamını siler. Bu, sistemi sıfırdan başlatmanın belgelenmiş yoludur ancak aynı zamanda oluşturduğunuz tüm iş akışlarını kaybetmenin en hızlı yoludur. Aradaki -v ifadesi tüm farkı yaratır.

3000 numaralı portu dışarı açmak yerine Traefik arkasına alın

3000 ve 8080 numaralı portları halka açık bir VPS üzerinde yayınlamak, uygulamayı TLS (taşıma katmanı güvenliği) olmadan ve yönetici kaydı önünde hiçbir engel bulunmadan dış dünyaya açar. Yalnızca bir ufw kuralı yeterli değildir; çünkü Docker, yayınlanan portlar için kendi iptables kurallarını ufw tarafından yönetilen zincirin önüne ekler. Bu nedenle 0.0.0.0 adresine yayınlanan bir port, ufw üzerinde reddedilmiş olsa dahi erişilebilir kalır.

Temiz çözüm, hiçbir portu dışarı açmamak ve proxy'nin container'lara paylaşımlı bir Docker ağı üzerinden erişmesini sağlamaktır. Repo kök dizininde docker-compose.override.yml dosyasını oluşturun:

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

networks:
  proxy:
    external: true

Bunun çalışıp çalışmayacağını iki detay belirler. !override, ports listesini birleştirmek yerine tamamen değiştirir; bu da Compose v2.24 veya daha yeni bir sürüm gerektirir. Sürümü docker compose version ile kontrol edin; çünkü daha eski bir Compose sürümünde iki liste birleşir ve portlar yayınlanmaya devam eder. Ayrıca default, her networks listesinde kalmalıdır; çünkü herhangi bir ağ tanımlamak varsayılan ağı devre dışı bırakır. Bu yüzden onu listeden çıkarmak, frontend'in Postgres ve Redis ile olan bağlantısını keser. Başlatmadan önce birleştirilmiş sonucu doğrulayın:

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

Router'lar, sertifika çözümleyici ve HTTP'den HTTPS'ye yönlendirme, diğer tüm uygulamalarla aynıdır. Bu nedenle yeni bir TLS yapılandırması yazmak yerine tek bir VPS üzerinde birden fazla uygulama çalıştırmaya yönelik Traefik reverse proxy rehberimizi takip edin. Bir alan adını 3000 numaralı porttaki frontend adresine, ikincisini ise 8080 numaralı porttaki livecontext adresine yönlendirin.

İkinci alan adı isteğe bağlı değildir. Web arayüzü, backend'i tarayıcı üzerinden çağırır; bu nedenle backend'in, tarayıcının erişebileceği kendi origin adresine ihtiyacı vardır. docker/.env.ce içindeki GATEWAY_PUBLIC_URL değerini, örneğin https://lc-api.example.com gibi, bu backend URL'sine ayarlayın. Bunu atladığınızda sayfa normal şekilde yüklenir ancak her işlem başarısız olur. Bunun nedeni, arayüzün backend origin adresini sayfayı açtığınız adresten çözümlemesi ve proxy'nizin asla yayınlamadığı bir portu çağırmasıdır.

Kayıt sayfası, sayfaya ilk ulaşan herkese açık olduğundan, frontend router üzerinde kimlik doğrulama katmanı eklemek faydalıdır. Böylece kimse, proxy seviyesinde kimlik doğrulaması yapmadan o sayfayı göremez. Authentik'i kendi SSO katmanınız olarak çalıştırmak, aynı Traefik kurulumu üzerine bu özelliği ekler.

Model anahtarının konumu ve boşta duran bir örneğin neden maliyet oluşturduğu

Ajanlar, buradaki otomasyonun içinde çalışır; bu durum, standart bir iş akışı aracına kıyasla ekonomik yapıyı değiştirir. Sağlayıcı anahtarı, docker/.env.ce içerisinde ANTHROPIC_API_KEY veya OPENAI_API_KEY olarak yer alır, başlangıçta arka uç (backend) ve köprü (bridge) tarafından okunur ve tüm örneğe (instance) uygulanır. Bu anahtar kullanıcı bazlı kapsamlandırılmaz. Örneğinizde hesabı olan ve ajan oluşturabilen herkes bu anahtarı harcar; sisteme ilk kaydolan kişi ise yönetici (admin) olur.

Üç alışkanlık, fatura tutarını öngörülebilir kılar. Bu VPS için ayrı bir sağlayıcı anahtarı oluşturun; böylece diğer hiçbir şeye dokunmadan bu anahtarı iptal edebilirsiniz. Sağlayıcı konsolunda katı bir harcama sınırı belirleyin, çünkü güvence altına aldığınız makinenin dışındaki tek limit budur. Ardından, LiveContext tarafından sunulan ajan bazlı kredi bütçelerini ve ajan bazlı metrikleri kullanın; böylece tek bir döngü, siz fark etmeden anahtarın bakiyesini tüketemez.

Bir ajan zamanlanmış bir görevde (schedule) tanımlandığında, boşta durma maliyeti sıfır değildir. Bir zamanlayıcı tetikleyicisi, birinin izleyip izlemediğine bakılmaksızın çalışır ve her tetiklenme token harcar. Beş dakikalık bir zamanlama günde 288 çalıştırma demektir; bir sayfayı okuyup hiçbir şey yapmamaya karar veren bir ajan bile sayfa okuma maliyetini öder. İlk ajanlarınızı bir webhook veya sohbet tetikleyicisi üzerine kurun, bir hafta boyunca gerçek harcamayı izleyin ve çalıştırma başına maliyeti öğrendikten sonra zamanlamaya geçin.

Postgres ve nesne deposunu yedekleme

Üç bileşenden (iki veri deposu ve bir gizli anahtar) herhangi birinin kaybı, örneğinizin tamamının kaybı anlamına gelir. Veritabanı satırı döküldükten sonra dosya yazılmasını engellemek için backend servisini durdurun ve veritabanı ile bucket yedeğini aynı zaman aralığında alın.

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

Eğer değiştirdiyseniz, postgres yerine DB_USERNAME olarak belirlediğiniz değeri kullanın. Ardından, docker volume ls çıktısında yazan ön ekli ismi kullanarak nesne deposu birimini kopyalayın:

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)

Yedeğe güvenmeden önce boş olmadığını doğrulayın: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 komutu tek satırlık bir hata mesajı yerine CREATE TABLE ve DROP TABLE ifadelerini göstermelidir. Daha sonra her üç dosyayı da sunucudan dışarı kopyalayın. Yalnızca koruduğu makinede barınan bir yedek, yedek sayılmaz.

Yeni bir sunucuya geri yükleme yapmak için aynı etiketi (tag) kurun, kimlik bilgisi şifreleme parolası ve salt değerinin eşleşmesi için kaydedilen docker/.env.ce dosyasını yerine koyun, birimlerin oluşması için stack'i bir kez başlatın, backend servisini durdurun ve ardından dökümü yükleyin:

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

Yükseltmeler ve bir şeyler ters gittiğinde geri dönüş

Her seferinde önce bir yedek alın. Backend, başlatma sırasında şema migrasyonlarını uygular ve migrasyonlar yalnızca ileriye doğru çalışır; bu nedenle hatalı bir yükseltmeden sonra eski etikete (tag) dönmek, eski kodun yeni bir şema üzerinde çalışmasına neden olur. Geri alma işlemi, yedeğin geri yüklenmesi anlamına gelir; bu yüzden yedekleme ilk sırada yer alır.

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 değişkenini, üçüncü komutun listelediği etiketlerden seçtiğiniz değerle ayarlayın. Health endpoint tekrar yanıt verene kadar backend günlüğünü (log) izleyin. docker-compose.override.yml dosyanız izlenmediği için git checkout komutu dosyayı olduğu gibi bırakır; ancak etiketler arasındaki docker-compose.yml farklarını mutlaka inceleyin. Yeni veya yeniden adlandırılmış bir servis, herhangi bir hata mesajı vermeden geçersiz (stale) bir override yapılandırmasına yol açabilir.

Hata modları ve karşılaşacağınız dizgeler

Bir container sürekli yeniden başlıyorsa ve docker compose ps çıktısında exited (137) görünüyorsa. Bu, çekirdeğin out-of-memory (OOM) katilidir ve docker inspect livecontext-app, durum bloğunda "OOMKilled": true ile bunu doğrular. Backend 1536M sınırına ulaşmıştır veya ana makinenin belleği tükenmiştir. Herhangi bir sınırı yükseltmeden önce free -m değerini kontrol edin; çünkü boşta kaynağı olmayan bir ana makinede container sınırını artırmak, sadece sonlandırma işleminin başka bir container üzerinde gerçekleşmesine neden olur.

Çekme (pull) işlemi no matching manifest for linux/arm64/v8 in the manifest list entries hatasıyla başarısız oluyorsa. İmajlar yalnızca linux/amd64 için yayınlanmıştır. Bir Arm VPS, yayınlanan imajlarla bu yığını çalıştıramaz; QEMU üzerinden emülasyon ise bir JVM ve Chromium için fazlasıyla yavaştır. Bir x86 planına geçiş yapın.

Bind for 0.0.0.0:3000 failed: port is already allocated. Ana makinedeki başka bir servis ilgili portu zaten kullanıyordur. docker/.env.ce içindeki FRONTEND_PORT değerini değiştirin veya yukarıdaki geçersiz kılma (override) işlemini uygulayarak hiçbir portu dışarıya açmayın.

Arayüz çalışıyor ancak proxy ekledikten sonra giriş isteği başarısız oluyorsa. Tarayıcı, backend'i proxy'nizin hizmet vermediği bir kaynaktan (origin) çağırıyordur. Tarayıcının ağ (network) sekmesini açın ve başarısız olan isteğin host adresini inceleyin. GATEWAY_PUBLIC_URL değerini genel backend URL'sine ayarlayın ve frontend container'ını yeniden oluşturun; çünkü bu değer başlangıçta okunur.

Her şey sağlıklı görünüyor ancak iş akışında yüklenen dosyalar kayboluyorsa. minio-init komutunun sıfır olmayan bir kod yerine exited (0) döndürdüğünden emin olun. Eğer workflow-files bucket'ı hiç oluşturulmadıysa, backend'in nesneleri kaydedebileceği bir yer yoktur.

LiveContext veya n8n seçimi

Ajan odaklı bir yapı istiyorsanız LiveContext'i seçin: modelin otomasyonu oluşturmasını ve çalıştırmasını hedefliyorsanız, 8 GB RAM kapasiteli bir sunucu ve Java tabanlı bir servis maliyetini kabul etmeniz gerekir. Belirleyici iş akışları, geniş bir düğüm kütüphanesi ve diğer servislerle aynı VPS üzerinde barınabilecek kadar düşük bir kaynak tüketimi istiyorsanız n8n'i seçin. Ağustos 2026 itibarıyla v0.2.11 bu sürümler henüz yenidir; bu nedenle imaj etiketlerinizi sabitleyin ve her yükseltme öncesinde sürüm notlarını okuyun. Bu iki seçenek arasında kalan araçlar da dahil olmak üzere daha geniş bir yelpaze için, yalnızca bu ikisini kıyaslayan bir metin yerine self-hosted n8n alternatifleri özetimize göz atın.

FAQ

Self-hosted LiveContext ne kadar RAM gerektirir?

8 GB RAM planlayın. Upstream README dosyasında minimum 4 GB, önerilen ise 8 GB olarak belirtilmiştir; sunulan compose dosyası da bu değerlerle uyumludur: yalnızca backend servisi 1536 MB ile sınırlandırılmıştır ve beş temel servis, sınırsız frontend container'ı hariç toplamda 3 GB'ın biraz altında bir kullanım sergiler. Browser agent profilini etkinleştirmek, Chromium ve SearXNG container'ı için ek 2048 MB bellek gerektirir; bu noktada 8 GB RAM artık bir seçenek değil, zorunluluk haline gelir.

LiveContext'i Arm tabanlı bir VPS üzerinde çalıştırabilir miyim?

Hayır. Yayınlanan tüm imajlar linux/amd64 mimarisi için derlenmiştir, bu nedenle docker compose up bir Arm planında çekilmeye çalışıldığında no matching manifest for linux/arm64/v8 in the manifest list entries hatası ile başarısız olur. QEMU emülasyonu altında çalıştırmak teorik olarak mümkün olsa da, JVM tabanlı bir iş yükü için pratikte kullanılamaz durumdadır. x86 tabanlı bir plan seçin.

Model API anahtarımı nereye koymalıyım?

İlk başlatmadan önce docker/.env.ce dosyası içerisine, ANTHROPIC_API_KEY, OPENAI_API_KEY veya GOOGLE_API_KEY olarak ekleyin. Backend ve bridge servisleri bu anahtarı başlangıçta okur; bu ayar tek bir kullanıcı için değil, tüm instance için geçerli olur. Dosyayı 600 modunda tutun, yalnızca bu sunucuya özel bir anahtar oluşturun (böylece gerektiğinde sadece bu anahtarı iptal edebilirsiniz) ve sağlayıcı konsolu üzerinden bir harcama limiti belirleyin; çünkü makine dışındaki tek koruma katmanı bu limittir.

LiveContext yedeğini nasıl alırım?

Üç öğe gereklidir: livecontext veritabanının bir pg_dump yedeği, MinIO volume kopyası ve docker/.env.ce dosyası. Veritabanı ile nesne deposunun tutarlı olması için ilk iki öğeyi alırken livecontext ve frontend servislerini durdurun. Env dosyası kritiktir çünkü iş akışlarınızda saklanan kimlik bilgileri CREDENTIAL_ENCRYPTION_PASSWORD ve CREDENTIAL_ENCRYPTION_SALT ile şifrelenir; bu değerler olmadan yapılan bir geri yükleme, yeni sunucuda okunamaz durumdaki kimlik bilgisi satırlarına yol açar.

Backend neden açılıştan sonra dakikalarca health: starting durumunda bekliyor?

Compose healthcheck mekanizması start_period: 120s değerini ayarlar ve /actuator/health adresini sorgular; bu nedenle Docker, şema migrasyonları ve araç kayıtları devam ederken servisi başlatılıyor olarak raporlar. İlk açılışta iki ila üç dakika bekleme süresi normaldir. Eğer servis hiçbir zaman sağlıklı (healthy) duruma geçmezse docker compose logs -f livecontext dosyasını inceleyin. Migrasyon adımında takılan bir stack, genellikle daha yeni bir sürüme ait bir veritabanı volume'una işaret ediyordur.