LiveContext selbst hosten: Docker-Stack statt n8n

Was LiveContext ist und welche Betriebskosten entstehen

Für das Self-Hosting von LiveContext benötigen Sie einen VPS mit etwa 8 GB RAM. LiveContext CE ist eine Open-Source-Automatisierungsplattform, die AI-Agenten innerhalb der Automatisierung ausführt. Die Plattform wird als Docker-Compose-Stack mit sechs Containern bereitgestellt, die auf einem Java-Backend aufbauen. Die Upstream-README nennt 4 GB als Minimum und 8 GB als Empfehlung. Die Compose-Datei zeigt, wie dieser Speicher verwendet wird.

Das Projekt befindet sich auf livecontext-ai/livecontext-ce auf GitHub und steht unter der Lizenz AGPL-3.0. Das aktuelle Release im August 2026 ist v0.2.11. Es wurde am 3. August 2026 veröffentlicht. Jedes Image wird ausschließlich für linux/amd64 erstellt. Damit sind die günstigen Arm-Tarife ausgeschlossen. Diese Anleitung verwendet dieses Tag unverändert, stellt den Stack hinter einen Reverse Proxy und beschreibt das Backup-Verfahren, das in der Upstream-Dokumentation fehlt.

Dimensionieren Sie den VPS vor dem Self-Hosting von LiveContext

Jeder Dienst in der mitgelieferten Compose-Datei hat ein explizites Speicherlimit. Daher können Sie die Maschine dimensionieren, bevor Sie sie mieten. Dies sind die in der v0.2.11-Compose-Datei eingetragenen Limits, nicht der gemessene Verbrauch.

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

Das Backend allein ist auf 1536 MB begrenzt. Dieses Limit gilt für einen Java-21-Prozess. Daher wird die JVM den größten Teil davon nutzen und belegen. Die fünf Basisdienste kommen zusammen auf knapp 3 GB. Für das Frontend gibt es überhaupt kein Limit. Es verwendet daher so viel Speicher, wie Node anfordert. Auf einem VPS mit 4 GB bleibt damit fast kein Speicher für den Kernel und den Page Cache übrig. Deshalb sind 4 GB als Mindestgröße und nicht als Empfehlung angegeben.

Die optionalen Profile erhöhen den Bedarf auf 8 GB. Das Browser-Agent-Profil fügt neben einer SearXNG-Suchinstanz einen Chromium-Container hinzu, der auf 2048 MB begrenzt ist. Das Renderer-Profil benötigt weitere 1024 MB für Screenshots und PDFs. Keiner dieser Container startet, solange Sie sein Profil nicht aktivieren. Lassen Sie beide daher deaktiviert, bis Sie sie benötigen. Der SearXNG-Container dient als Such-Backend des Agenten. Die von ihm zurückgegebenen Seiten gelangen dadurch als nicht vertrauenswürdiger Text in Ihre Prompts. Das ist die Vertrauensgrenze, über die die Bereitstellung einer Websuche mit SearXNG für einen KI-Agenten im Detail funktioniert.

Wenn Sie n8n bereits betreiben, planen Sie, es zu ersetzen, statt es zu ergänzen. Der Stack aus unserer Anleitung zum Betrieb von n8n auf einem VPS mit Docker und HTTPS besteht aus einem Node-Prozess neben Postgres und läuft problemlos auf einer kleinen Maschine. LiveContext reserviert allein für sein Backend mehr Speicher, als dieser gesamte Stack verwendet. Zwei Automatisierungsplattformen passen auf einen VPS mit 8 GB, bis beide in derselben Minute einen Auftrag ausführen. Wenn Sie den Host gemeinsam nutzen, setzen Sie auch für alle anderen Dienste explizite Limits. Verwenden Sie dafür die Methode aus unserem Beitrag zum Setzen von Speicherlimits in Docker Compose, damit ein außer Kontrolle geratener Workflow nicht die gesamte Maschine mitreißt.

LiveContext mit Docker Compose und fest auf ein Tag gesetzt installieren

Starten Sie mit einer sauberen Ubuntu-24.04-VPS mit Docker Engine 24 oder neuer und Compose v2. Wenn Docker noch nicht installiert ist, folgen Sie zuerst unserer Einführung in Docker Compose für eine VPS und kehren Sie anschließend hierher zurück.

Die README bietet npx livecontext als Startbefehl in einer Zeile an. Auf einem Laptop ist das in Ordnung. Auf einem Server sollte die Compose-Datei in einem Verzeichnis liegen, das Sie kontrollieren, denn dann besteht ein Upgrade aus einem git checkout und Sie können genau nachvollziehen, was sich geändert hat.

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

Die Compose-Datei setzt bereits für jedes Image das Release-Tag fest, zum Beispiel ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Das Auschecken des passenden git-Tags hält Compose-Datei und Images auf demselben Stand, weil die Compose-Datei für v0.2.11 mit diesen Images erstellt wurde. Ändern Sie die Tags nicht in latest. Ein latest-Tag kann sich unter Ihnen ändern. Außerdem führt das Backend bei jedem Start Datenbankmigrationen aus. Ein versehentliches Pull kann daher um 3 Uhr morgens das Schema vorziehen, ohne Rückweg außer einer Wiederherstellung.

Bearbeiten Sie docker/.env.ce vor dem ersten Start. Im nächsten Abschnitt ist aufgeführt, was Sie ändern müssen. Starten Sie anschließend den Stack.

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

Verwenden Sie bei jedem Compose-Befehl in dieser Anleitung dasselbe --env-file-Flag. Compose liest diese Datei bei jeder Ausführung neu ein. Ein Befehl ohne dieses Flag verwendet daher die in der Compose-Datei hinterlegten Standardwerte und kann andere Ports veröffentlichen als die von Ihnen konfigurierten.

Der Healthcheck des Backends hat ein start_period von 120s und fragt /actuator/health ab. Daher meldet docker compose ps den Dienst livecontext ungefähr während der ersten zwei Minuten als health: starting, während die Schema-Migrationen und die Registrierung des Tools ausgeführt werden. Das ist normal. Eine schnelle Prüfung auf dem Server:

curl -s localhost:8080/actuator/health

Dies sollte {"status":"UP"} ausgeben. Öffnen Sie anschließend die Weboberfläche auf Port 3000. Das erste von Ihnen erstellte Konto wird zum Administratorkonto. Erstellen Sie Ihr Konto daher, bevor der Port für andere erreichbar ist. Dies ist der wichtigste Grund, Port 3000 am ersten Tag nicht im Internet zu veröffentlichen.

Die zu ändernden Umgebungsvariablen

Die Beispieldatei enthält funktionierende Standardwerte, damit der Stack auf einem Laptop startet. Mehrere dieser Werte sind auf einem öffentlichen Server unsicher.

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

Generieren Sie jeden zufälligen Wert mit openssl rand -base64 32. Beachten Sie insbesondere folgende Punkte:

• POSTGRES_PASSWORD und MINIO_ROOT_PASSWORD werden mit postgres und minioadmin ausgeliefert. Keiner der beiden Datenbank-Ports wird auf dem Host veröffentlicht. Sie sind daher nicht direkt erreichbar. Jeder Container, den Sie später mit demselben Netzwerk verbinden, kann jedoch beide Ports mit den dokumentierten Standardwerten erreichen.
• CREDENTIAL_ENCRYPTION_PASSWORD und CREDENTIAL_ENCRYPTION_SALT werden automatisch generiert, wenn sie leer bleiben. Setzen Sie sie stattdessen selbst. Die von Ihren Workflows gespeicherten Zugangsdaten werden mit diesem Paar verschlüsselt. Wenn Sie einen Datenbank-Dump auf einem neuen System ohne dasselbe Passwort und denselben Salt wiederherstellen, sind die enthaltenen Zugangsdaten unlesbar. Setzen Sie die Werte einmalig und behandeln Sie docker/.env.ce anschließend als Bestandteil des Backups.
• FRONTEND_PORT und BACKEND_PORT werden in die Port-Zuordnungen als ${FRONTEND_PORT:-3000}:3000 und ${BACKEND_PORT:-8080}:8080 eingesetzt. Die Beispieldatei für Umgebungsvariablen setzt beide Werte ausdrücklich. Die darin enthaltenen Werte sind nicht immer 3000 und 8080. Lesen Sie daher Ihre eigene Datei, statt diese Werte vorauszusetzen.
• GATEWAY_PUBLIC_URL ist die für den Browser sichtbare Origin des Backends. Das ist relevant, sobald ein Reverse Proxy verwendet wird. Siehe den nächsten Abschnitt.
• Die Modell-Keys (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY und optional MISTRAL_API_KEY oder DEEPSEEK_API_KEY) werden hier im Klartext gespeichert. Tragen Sie nur den Provider ein, den Sie tatsächlich verwenden.

Aufgaben der sechs Container

• postgres führt pgvector/pgvector:pg16 als Container livecontext-db aus und enthält die Datenbank livecontext. Die Erweiterung pgvector wird für die Suche nach Embeddings benötigt. Ein einfaches postgres:16-Image reicht daher nicht aus.
• redis führt redis:7-alpine mit appendonly yes und --maxmemory-policy noeviction aus. Diese Richtlinie ist beabsichtigt: Redis speichert hier den Status von Warteschlangen und Ausführungen. Wenn das Speicherlimit erreicht ist, gibt Redis einen Fehler an den schreibenden Prozess zurück, anstatt Schlüssel stillschweigend zu verwerfen. Ein sichtbarer Fehler ist besser als eine unbemerkt verlorene Ausführung.
• minio ist der S3-kompatible Objektspeicher für Dateien, die Workflows durchlaufen. Ein einmalig gestarteter minio-init-Container führt beim Start mc mb myminio/workflow-files --ignore-existing aus, erstellt den Bucket und wird beendet. minio-init als exited (0) in docker compose ps zeigt den erwarteten Zustand an.
• bridge enthält die CLI-Adapter und die MCP-Tools (Model Context Protocol). Der Container lauscht im Docker-Netzwerk auf Port 8093. Der Port wird nicht auf dem Host veröffentlicht.
• livecontext ist das Backend, ein einzelner Java-21-Monolith auf Port 8080. Es führt die Workflow-Engine, die Scheduler und die Agents aus.
• frontend ist die Next.js-Weboberfläche auf Port 3000. Nur diese beiden letzten Container veröffentlichen Ports auf dem Host.

Der Status liegt in fünf benannten Volumes: livecontext_data für Postgres, livecontext_redis, livecontext_minio, livecontext_keys und livecontext_logs. Compose versieht sie mit dem Projektnamen. Standardmäßig entspricht dieser dem Verzeichnisnamen. Das tatsächliche Volume auf dem Datenträger heißt daher beispielsweise livecontext-ce_livecontext_minio. Führen Sie docker volume ls aus und übernehmen Sie die exakten Namen, bevor Sie dafür ein Backup-Skript erstellen.

docker compose down -v löscht alle fünf Volumes. Dies ist der dokumentierte Weg, neu zu beginnen. Gleichzeitig verlieren Sie damit am schnellsten jeden von Ihnen erstellten Workflow. Der -v macht den gesamten Unterschied aus.

Stellen Sie den Dienst hinter Traefik, statt Port 3000 zu veröffentlichen

Die Veröffentlichung der Ports 3000 und 8080 auf einem öffentlichen VPS stellt die Anwendung ohne TLS (Transport Layer Security) und ohne vorgelagerte Zugriffskontrolle für die Administratorregistrierung bereit. Eine ufw-Regel reicht allein nicht aus, weil Docker für veröffentlichte Ports eigene iptables-Regeln vor der von ufw verwalteten Chain einfügt. Ein auf 0.0.0.0 veröffentlichter Port bleibt daher erreichbar, selbst wenn ufw meldet, dass der Port abgelehnt wird.

Die saubere Lösung besteht darin, keine Ports zu veröffentlichen und den Proxy über ein gemeinsames Docker-Netzwerk auf die Container zugreifen zu lassen. Erstellen Sie docker-compose.override.yml im Stammverzeichnis des Repositorys:

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

networks:
  proxy:
    external: true

Zwei Details entscheiden darüber, ob dies funktioniert. !override ersetzt die Liste der Ports, statt sie mit ihr zusammenzuführen. Dafür ist Compose v2.24 oder neuer erforderlich. Prüfen Sie die Version mit docker compose version, denn bei einer älteren Compose-Version werden die beiden Listen zusammengeführt und die Ports bleiben veröffentlicht. Außerdem muss default in jeder networks-Liste enthalten bleiben. Sobald Sie ein Netzwerk benennen, wird das Standardnetzwerk ersetzt. Wenn Sie es weglassen, kann das Frontend Postgres und Redis nicht mehr erreichen. Prüfen Sie das zusammengeführte Ergebnis, bevor Sie etwas starten:

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

Die Router, der Zertifikatsresolver und die Weiterleitung von HTTP auf HTTPS funktionieren genauso wie bei jeder anderen Anwendung. Folgen Sie daher unserer Anleitung für einen Traefik-Reverse-Proxy zum Betrieb mehrerer Anwendungen auf einem VPS, statt hier eine neue TLS-Konfiguration zu schreiben. Leiten Sie einen Hostnamen auf frontend an Port 3000 und einen zweiten auf livecontext an Port 8080 weiter.

Der zweite Hostname ist erforderlich. Die Weboberfläche ruft das Backend aus dem Browser auf. Daher benötigt das Backend eine eigene Origin, die der Browser erreichen kann. Setzen Sie GATEWAY_PUBLIC_URL in docker/.env.ce auf die URL dieses Backends, zum Beispiel https://lc-api.example.com. Wenn Sie diese Einstellung weglassen, wird die Seite normal geladen, aber jede Aktion schlägt fehl. Die Benutzeroberfläche hat die Backend-Origin aus der geöffneten Adresse abgeleitet und ruft einen Port auf, den Ihr Proxy nicht veröffentlicht hat.

Da die Registrierungsseite für jeden erreichbar ist, der sie zuerst aufruft, sollten Sie auf dem Frontend-Router Forward Auth einrichten. So sieht niemand diese Seite, ohne sich am Proxy zu authentifizieren. Genau das ergänzt der Betrieb von Authentik als eigene SSO-Schicht auf Basis derselben Traefik-Konfiguration.

Wo der Modellschlüssel hinterlegt wird und warum eine inaktive Instanz weiterhin Kosten verursacht

Agenten laufen hier innerhalb der Automatisierung. Dadurch unterscheidet sich die Kostenstruktur von der eines einfachen Workflow-Tools. Der Provider-Schlüssel liegt in docker/.env.ce als ANTHROPIC_API_KEY oder OPENAI_API_KEY, wird beim Start vom Backend und von der Bridge gelesen und gilt für die gesamte Instanz. Er ist nicht auf einzelne Benutzer begrenzt. Jeder Benutzer mit einem Konto auf Ihrer Instanz, der einen Agenten erstellen kann, verbraucht diesen Schlüssel. Die erste Person, die sich registriert, erhält Administrationsrechte.

Drei Maßnahmen halten die Kosten vorhersehbar. Erstellen Sie für diesen VPS einen eigenen Provider-Schlüssel. So können Sie ihn widerrufen, ohne andere Systeme zu ändern. Legen Sie in der Provider-Konsole ein hartes Ausgabenlimit fest. Dieses Limit ist die einzige Absicherung außerhalb des von Ihnen verwalteten Systems. Verwenden Sie anschließend die agentenspezifischen Guthabenlimits und Metriken pro Agent, die LiveContext bereitstellt. So kann eine einzelne Schleife den Schlüssel nicht unbemerkt aufbrauchen.

Sobald ein Agent nach einem Zeitplan ausgeführt wird, sind die Leerlaufkosten nicht null. Ein Zeitplan-Trigger wird unabhängig davon ausgelöst, ob jemand die Ausführung beobachtet. Jeder Aufruf überträgt Tokens. Ein Zeitplan mit einem Intervall von fünf Minuten führt zu 288 Ausführungen pro Tag. Auch ein Agent, der eine Seite liest und anschließend entscheidet, nichts zu tun, verursacht Kosten für das Lesen der Seite. Verwenden Sie Ihre ersten Agenten mit einem Webhook- oder Chat-Trigger. Beobachten Sie die tatsächlichen Ausgaben eine Woche lang. Wechseln Sie erst danach zu einem Zeitplan, wenn Sie die Kosten pro Ausführung kennen.

Postgres und den Object Store sichern

Es gibt zwei Datenspeicher und ein Secret. Wenn einer dieser drei Bestandteile verloren geht, ist Ihre Instanz nicht mehr vollständig wiederherstellbar. Sichern Sie die Datenbank und den Bucket im selben Zeitfenster, während das Backend gestoppt ist. Dadurch kann keine Datei mehr geschrieben werden, nachdem die zugehörige Datenbankzeile exportiert wurde.

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

Verwenden Sie anstelle von postgres den Wert, den Sie für DB_USERNAME festgelegt haben, falls Sie ihn geändert haben. Kopieren Sie anschließend das Volume des Object Stores. Verwenden Sie dabei den Namen mit Präfix, den docker volume ls ausgegeben hat:

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)

Prüfen Sie, dass der Dump nicht leer ist, bevor Sie ihm vertrauen: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 sollte CREATE TABLE und DROP TABLE-Anweisungen anzeigen, nicht eine einzeilige Fehlermeldung. Kopieren Sie anschließend alle drei Dateien vom Server. Eine Sicherung, die ausschließlich auf dem zu schützenden Rechner liegt, ist keine Sicherung.

Um die Daten auf einem neuen Rechner wiederherzustellen, installieren Sie dasselbe Tag, legen Sie das gesicherte docker/.env.ce wieder ab, damit das Passwort und der Salt für die Verschlüsselung der Zugangsdaten übereinstimmen, starten Sie den Stack einmal, damit die Volumes erstellt werden, stoppen Sie das Backend und laden Sie anschließend den 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

Upgrades und Wiederherstellung nach einem fehlgeschlagenen Upgrade

Erstellen Sie jedes Mal zuerst einen Dump. Das Backend wendet seine Schema-Migrationen beim Start an. Migrationen werden nur vorwärts ausgeführt. Wenn Sie nach einem fehlgeschlagenen Upgrade den älteren Tag auschecken, läuft der alte Code daher mit einem neueren Schema. Für ein Rollback müssen Sie den Dump wiederherstellen. Deshalb wird der Dump zuerst erstellt.

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

Setzen Sie TAG auf den Tag, den Sie aus der vom dritten Befehl ausgegebenen Liste ausgewählt haben. Überwachen Sie das Backend-Log, bis der Health-Endpunkt wieder antwortet. Ihre docker-compose.override.yml wird nicht verfolgt. Ein git checkout lässt sie daher unverändert. Lesen Sie jedoch den Diff in docker-compose.yml zwischen den Tags. Ein neuer oder umbenannter Dienst kann dazu führen, dass Ihre Überschreibung veraltet ist, ohne dass eine Fehlermeldung ausgegeben wird.

Fehlerfälle mit den angezeigten Meldungen

Ein Container wird ständig neu gestartet und docker compose ps zeigt exited (137). Das ist der Out-of-Memory-Killer des Kernels. docker inspect livecontext-app bestätigt dies mit "OOMKilled": true im Statusblock. Das Backend hat sein Limit von 1536M erreicht, oder dem Host ist zuvor der Speicher ausgegangen. Prüfen Sie free -m, bevor Sie ein Limit erhöhen. Ein höheres Container-Limit auf einem Host ohne freie Ressourcen verlagert den Kill-Vorgang lediglich auf einen anderen Container.

Der Pull schlägt mit no matching manifest for linux/arm64/v8 in the manifest list entries fehl. Die Images werden nur für linux/amd64 veröffentlicht. Ein Arm-VPS kann diesen Stack nicht mit den veröffentlichten Images ausführen. Die Emulation über QEMU ist für eine JVM mit Chromium viel zu langsam. Wechseln Sie zu einem x86-Tarif.

Bind for 0.0.0.0:3000 failed: port is already allocated. Ein anderer Prozess auf dem Host verwendet diesen Port bereits. Ändern Sie FRONTEND_PORT in docker/.env.ce, oder wenden Sie den obigen Override an und veröffentlichen Sie überhaupt keinen Port.

Die UI ist erreichbar, aber die Anmeldeanforderung schlägt nach dem Hinzufügen des Proxys fehl. Der Browser ruft das Backend über einen Origin auf, den Ihr Proxy nicht bereitstellt. Öffnen Sie im Browser den Netzwerk-Tab und prüfen Sie den Host der fehlgeschlagenen Anfrage. Setzen Sie GATEWAY_PUBLIC_URL auf die öffentliche Backend-URL und erstellen Sie den Frontend-Container neu, da dieser Wert beim Start eingelesen wird.

Alles ist fehlerfrei, aber in einem Workflow hochgeladene Dateien verschwinden. Prüfen Sie, ob minio-init statt eines von null verschiedenen Codes exited (0) anzeigt. Wenn der Bucket workflow-files nie erstellt wurde, hat das Backend keinen Speicherort für Objekte.

LiveContext oder n8n auswählen

Wählen Sie LiveContext, wenn der Agent im Mittelpunkt steht: Das Modell soll die Automatisierung erstellen und ausführen, und Sie akzeptieren dafür einen Server mit 8 GB RAM sowie einen Java-Dienst. Wählen Sie n8n, wenn Sie deterministische Workflows, eine große Node-Bibliothek und einen Ressourcenbedarf wünschen, der sich einen VPS mit anderen Diensten teilt. Die Versionsnummern sind hier noch jung, v0.2.11 Stand August 2026. Fixieren Sie daher Ihren Tag und lesen Sie vor jedem Upgrade die Release Notes. Einen breiteren Überblick über das Umfeld, einschließlich der Tools zwischen diesen beiden Optionen, finden Sie in unserem Überblick über selbst gehostete n8n-Alternativen und nicht in einem Vergleich, der nur diese beiden Produkte betrachtet.

FAQ

Wie viel RAM benötigt ein selbst gehostetes LiveContext?

Planen Sie mit 8 GB. Die Upstream-README nennt 4 GB als Minimum und 8 GB als Empfehlung. Die mitgelieferte Compose-Datei bestätigt das: Das Backend allein ist auf 1536 MB begrenzt. Die fünf Basisdienste benötigen zusammen knapp 3 GB, noch bevor der Frontend-Container ohne Speicherlimit berücksichtigt wird. Das Aktivieren des Browser-Agent-Profils benötigt zusätzlich 2048 MB für Chromium sowie einen SearXNG-Container. Ab diesem Punkt sind 8 GB daher erforderlich.

Kann ich LiveContext auf einem Arm-VPS ausführen?

Nein. Jedes veröffentlichte Image wird für linux/amd64 erstellt. Daher schlägt docker compose up bei einem Arm-Tarif bereits beim Abruf mit no matching manifest for linux/arm64/v8 in the manifest list entries fehl. Der Betrieb unter QEMU-Emulation ist theoretisch möglich, in der Praxis für eine JVM-Workload jedoch nicht nutzbar. Wählen Sie einen x86-Tarif.

Wo hinterlege ich meinen Model-API-Schlüssel?

In docker/.env.ce, als ANTHROPIC_API_KEY, OPENAI_API_KEY oder GOOGLE_API_KEY, vor dem ersten Start. Das Backend und die Bridge lesen ihn beim Start ein. Er gilt für die gesamte Instanz und nicht nur für einen Benutzer. Setzen Sie die Dateiberechtigungen auf 600. Verwenden Sie einen Schlüssel, der ausschließlich für diesen Server erstellt wurde, damit Sie ihn unabhängig widerrufen können. Legen Sie außerdem im Provider-Konsolenbereich ein Ausgabenlimit fest. Dieses Limit ist die einzige Begrenzung, die außerhalb des Systems wirksam ist.

Wie sichere ich LiveContext?

Drei Dinge: ein pg_dump der livecontext-Datenbank, eine Kopie des MinIO-Volumes und die docker/.env.ce-Datei. Stoppen Sie die Dienste livecontext und frontend, während Sie die ersten beiden Sicherungen erstellen. Dadurch bleiben Datenbank und Objektspeicher konsistent. Die Env-Datei ist wichtig, weil die in Ihren Workflows gespeicherten Zugangsdaten mit CREDENTIAL_ENCRYPTION_PASSWORD und CREDENTIAL_ENCRYPTION_SALT verschlüsselt werden. Bei einer Wiederherstellung ohne diese Werte können die Zugangsdatenzeilen auf dem neuen System nicht gelesen werden.

Warum bleibt das Backend nach dem Boot für mehrere Minuten bei health: starting?

Der Compose-Healthcheck setzt start_period: 120s und fragt /actuator/health regelmäßig ab. Docker meldet den Dienst daher als „starting“, während die Schema-Migrationen und die Tool-Registrierung ausgeführt werden. Beim ersten Boot sind zwei bis drei Minuten zu erwarten. Wenn der Dienst nie den Status „healthy“ erreicht, lesen Sie docker compose logs -f livecontext. Wenn ein Stack beim Migrationsschritt stehen bleibt, verweist er meist auf ein Datenbank-Volume aus einer neueren Version.