LiveContext zelf hosten: handleiding en VPS vereisten

Wat LiveContext is en wat de kosten voor het draaien ervan zijn

Om LiveContext zelf te hosten heeft u een VPS nodig met ongeveer 8 GB RAM. LiveContext CE is een open-source automatiseringsplatform dat AI-agents binnen de automatisering zelf uitvoert. Het wordt geleverd als een Docker Compose-stack van zes containers, gebouwd rond een Java-backend. De upstream README vraagt om minimaal 4 GB en adviseert 8 GB; het compose-bestand toont waar dit geheugen wordt verbruikt.

Het project staat op livecontext-ai/livecontext-ce op GitHub en is gelicentieerd onder de AGPL-3.0. De huidige release per augustus 2026 is v0.2.11, gepubliceerd op 3 augustus 2026. Elke image is uitsluitend gebouwd voor linux/amd64, wat de goedkope Arm-abonnementen uitsluit. Deze handleiding zet die tag vast, plaatst de stack achter een reverse proxy en behandelt de back-upprocedure die niet in de upstream-documentatie is opgenomen.

Bepaal de grootte van de VPS voordat u LiveContext zelf host

Elke service in het meegeleverde compose-bestand heeft een expliciete geheugenlimiet, zodat u de grootte van de server kunt bepalen voordat u deze huurt. Dit zijn de limieten die in het v0.2.11 compose-bestand zijn vastgelegd, niet het gemeten verbruik.

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

De backend alleen al is beperkt tot 1536 MB. Die limiet geldt voor een Java 21-proces, dus de JVM zal het grootste deel daarvan in beslag nemen en behouden. De vijf basisservices samen verbruiken iets minder dan 3 GB, en de frontend heeft helemaal geen limiet, dus deze neemt wat Node vraagt. Op een VPS van 4 GB blijft er bijna niets over voor de kernel en de page cache; daarom staat 4 GB genoteerd als minimum in plaats van als aanbeveling.

De optionele profielen zorgen ervoor dat de server naar 8 GB gaat. Het browser agent-profiel voegt een Chromium-container toe die beperkt is tot 2048 MB naast een SearXNG-zoekinstantie, en het renderer-profiel voegt nog eens 1024 MB toe voor screenshots en PDF's. Geen van beide start tenzij u het profiel inschakelt, dus laat beide uitgeschakeld totdat u ze nodig heeft. Die SearXNG-container bestaat om als zoek-backend voor de agent te dienen, dus de pagina's die deze retourneert, komen in uw prompts terecht als niet-vertrouwde tekst. Dit is de vertrouwensgrens die in een AI-agent SearXNG-webzoekopdrachten geven in detail wordt besproken.

Als u al n8n draait, plan dan om dit te vervangen in plaats van het toe te voegen. De stack in onze handleiding voor het draaien van n8n op een VPS met Docker en HTTPS is één Node-proces naast Postgres, en dat draait comfortabel op een kleine server. LiveContext reserveert voor de backend alleen al meer dan die hele stack gebruikt. Twee automatiseringsplatformen op één VPS van 8 GB passen prima, totdat ze beide op hetzelfde moment een taak uitvoeren. Als u een host deelt, stel dan ook expliciete limieten in voor al het andere, met behulp van de methode in onze post over het instellen van geheugenlimieten in Docker Compose, zodat een uit de hand gelopen workflow de machine niet platlegt.

LiveContext installeren met Docker Compose, vastgezet op een tag

Begin met een schone Ubuntu 24.04 VPS met Docker Engine 24 of nieuwer en Compose v2. Als Docker nog niet is geïnstalleerd, volg dan eerst onze basisgids voor Docker Compose op een VPS en keer daarna terug.

De README biedt npx livecontext aan als startmethode via één regel. Dat is prima voor een laptop. Op een server wilt u dat het compose-bestand in een map staat die u beheert, omdat een upgrade dan neerkomt op een git checkout en u precies kunt lezen wat er is gewijzigd.

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

Het compose-bestand zet elke image al vast op de bijbehorende release-tag, bijvoorbeeld ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Door de bijbehorende git-tag uit te checken, blijven het compose-bestand en de images synchroon, omdat het compose-bestand voor v0.2.11 is geschreven voor die specifieke images. Wijzig de tags niet naar latest. Een latest-tag verschuift onder uw voeten, en de backend voert bij elke start database-migraties uit. Een onbedoelde pull kan uw schema dus midden in de nacht bijwerken zonder dat er een weg terug is, behalve via een restore.

Bewerk docker/.env.ce vóór de eerste start (de volgende sectie somt op wat u moet wijzigen) en breng daarna de stack omhoog.

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

Gebruik in deze handleiding bij elk compose-commando dezelfde --env-file-vlag. Compose leest dat bestand bij elke aanroep opnieuw in; een commando zonder de vlag valt terug op de standaardwaarden in het compose-bestand en kan andere poorten publiceren dan de poorten die u heeft geconfigureerd.

De healthcheck van de backend heeft een start_period van 120s en pollt /actuator/health. Daarom rapporteert docker compose ps de livecontext-service als health: starting gedurende de eerste twee minuten, terwijl de schema-migraties en de tool-registratie worden uitgevoerd. Dat is normaal. Een snelle controle vanaf de server:

curl -s localhost:8080/actuator/health

Dit zou {"status":"UP"} moeten weergeven. Zodra dit het geval is, opent u de web-UI op poort 3000. Het eerste account dat u aanmaakt wordt de admin, dus maak uw account aan voordat de poort voor anderen bereikbaar is. Dit is de belangrijkste reden om poort 3000 niet direct vanaf de eerste dag open te stellen voor het internet.

De env-waarden die u moet wijzigen

Het voorbeeldbestand bevat werkende standaardinstellingen zodat de stack op een laptop start. Verschillende daarvan zijn onveilig op een publieke server.

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

Genereer elke willekeurige waarde met openssl rand -base64 32. Opmerkingen over de waarden die problemen kunnen veroorzaken:

• POSTGRES_PASSWORD en MINIO_ROOT_PASSWORD worden geleverd als postgres en minioadmin. Geen van beide databasepoorten wordt gepubliceerd naar de host, dus ze zijn niet direct blootgesteld, maar elke container die u later aan hetzelfde netwerk koppelt, kan beide bereiken met de gedocumenteerde standaardwaarde.
• CREDENTIAL_ENCRYPTION_PASSWORD en CREDENTIAL_ENCRYPTION_SALT worden automatisch gegenereerd als ze leeg worden gelaten. Stel ze zelf in. De inloggegevens die uw workflows opslaan, worden versleuteld met dat paar. Een database-dump die op een nieuwe machine wordt hersteld zonder hetzelfde wachtwoord en dezelfde salt, resulteert in inloggegevens die door niets kunnen worden gelezen. Stel ze eenmaal in en behandel docker/.env.ce vervolgens als onderdeel van de back-up.
• FRONTEND_PORT en BACKEND_PORT worden gesubstitueerd in de poortmappings als ${FRONTEND_PORT:-3000}:3000 en ${BACKEND_PORT:-8080}:8080. Het voorbeeld-env-bestand stelt beide expliciet in en de waarden die het bevat zijn niet altijd 3000 en 8080. Lees uw eigen kopie in plaats van ervan uit te gaan.
• GATEWAY_PUBLIC_URL is de browser-facing origin van de backend. Dit is van belang zodra er een reverse proxy bij betrokken is. Zie de volgende sectie.
• De modelsleutels (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY en optioneel MISTRAL_API_KEY of DEEPSEEK_API_KEY) staan hier in platte tekst. Vul alleen de provider in die u daadwerkelijk gebruikt.

Wat de zes containers doen

• postgres draait pgvector/pgvector:pg16 als container livecontext-db, waarin de database genaamd livecontext wordt gehost. De pgvector-extensie is aanwezig voor embedding-zoekopdrachten, dus een standaard postgres:16-image volstaat niet.
• redis draait redis:7-alpine met appendonly yes en --maxmemory-policy noeviction. Dit beleid is bewust gekozen: Redis fungeert hier als wachtrij en voor de run-status. Wanneer het geheugenlimiet wordt bereikt, geeft het een foutmelding aan de schrijver in plaats van stilletjes sleutels te verwijderen. Een zichtbare fout is beter dan werk dat ongemerkt verdwijnt.
• minio is de S3-compatibele object store voor bestanden die door workflows worden verwerkt. Een eenmalige minio-init-container voert mc mb myminio/workflow-files --ignore-existing uit bij het opstarten, maakt de bucket aan en stopt vervolgens. Het zien van minio-init als exited (0) in docker compose ps is de gezonde status.
• bridge bevat de CLI-adapters en de MCP (model context protocol) tools. Deze luistert op poort 8093 binnen het Docker-netwerk en wordt niet gepubliceerd naar de host.
• livecontext is de backend, een Java 21-monoliet op poort 8080. Deze voert de workflow-engine, de schedulers en de agents uit.
• frontend is de Next.js web-UI op poort 3000. Alleen deze laatste twee zijn gepubliceerd naar de host.

De status wordt opgeslagen in vijf named volumes: livecontext_data voor Postgres, livecontext_redis, livecontext_minio, livecontext_keys en livecontext_logs. Compose voorziet deze van een prefix met de projectnaam, die standaard gelijk is aan de mapnaam. Het daadwerkelijke volume op de schijf heet daarom iets als livecontext-ce_livecontext_minio. Voer docker volume ls uit en kopieer de exacte namen voordat u back-upscripts schrijft die deze volumes gebruiken.

docker compose down -v verwijdert alle vijf de volumes. Dit is de gedocumenteerde manier om opnieuw te beginnen, maar het is ook de snelste manier om elke workflow die u heeft gebouwd te verliezen. De -v maakt het volledige verschil.

Plaats het achter Traefik in plaats van poort 3000 te publiceren

Het publiceren van poort 3000 en 8080 op een publieke VPS stelt de applicatie bloot zonder TLS (transport layer security) en zonder toegangscontrole voor de beheerdersregistratie. Een ufw-regel is op zichzelf niet voldoende, omdat Docker zijn eigen iptables-regels voor gepubliceerde poorten invoegt vóór de chain die ufw beheert. Hierdoor blijft een poort die naar 0.0.0.0 is gepubliceerd bereikbaar, zelfs als ufw aangeeft dat de poort is geweigerd.

De juiste oplossing is om niets te publiceren en de proxy de containers te laten bereiken via een gedeeld Docker-netwerk. Maak docker-compose.override.yml aan in de hoofdmap van de repository:

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

networks:
  proxy:
    external: true

Twee details bepalen of dit werkt. !override vervangt de lijst met poorten in plaats van deze samen te voegen; dit vereist Compose v2.24 of nieuwer. Controleer dit met docker compose version, want bij een oudere versie van Compose worden de twee lijsten samengevoegd en blijven de poorten gepubliceerd. Daarnaast moet default in elke networks-lijst blijven staan. Het benoemen van een netwerk vervangt namelijk het standaardnetwerk, dus als u dit weglaat, wordt de frontend afgesneden van Postgres en Redis. Controleer het samengevoegde resultaat voordat u iets start:

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

De routers, de certificaat-resolver en de HTTP naar HTTPS-redirect zijn hetzelfde als voor elke andere applicatie. Volg daarom onze Traefik reverse proxy-handleiding voor het draaien van meerdere applicaties op één VPS in plaats van hier een nieuwe TLS-configuratie te schrijven. Route één hostnaam naar frontend op poort 3000 en een tweede naar livecontext op poort 8080.

De tweede hostnaam is niet optioneel. De web-UI roept de backend aan vanuit de browser, dus de backend heeft een eigen origin nodig die een browser kan bereiken. Stel GATEWAY_PUBLIC_URL in docker/.env.ce in op die backend-URL, bijvoorbeeld https://lc-api.example.com. Slaat u dit over, dan laadt de pagina normaal, maar mislukt elke actie. De UI heeft namelijk de backend-origin bepaald op basis van het adres waarmee u de pagina opende en probeert een poort aan te roepen die uw proxy nooit heeft gepubliceerd.

Omdat de aanmeldpagina toegankelijk is voor iedereen die deze bereikt, is het raadzaam om voorwaartse authenticatie toe te passen op de frontend-router. Zo ziet niemand die pagina zonder te authenticeren bij de proxy. Dit is wat het draaien van Authentik als uw eigen SSO-laag toevoegt aan dezelfde Traefik-configuratie.

Waar de modelsleutel wordt geplaatst en waarom een inactieve instantie nog steeds kosten met zich meebrengt

Agents draaien hier binnen de automatisering, wat de economische aspecten verandert in vergelijking met een standaard workflow-tool. De providersleutel bevindt zich in docker/.env.ce als ANTHROPIC_API_KEY of OPENAI_API_KEY, wordt bij het opstarten gelezen door de backend en de bridge, en is van toepassing op de gehele instantie. Deze is niet per gebruiker gespecificeerd. Iedereen die een account op uw instantie heeft en een agent kan bouwen, verbruikt die sleutel, en de eerste persoon die zich registreert is een beheerder.

Drie gewoonten houden de factuur voorspelbaar. Maak een aparte providersleutel aan voor deze VPS, zodat u deze kunt intrekken zonder andere zaken te beïnvloeden. Stel een harde bestedingslimiet in in de console van de provider, aangezien die limiet de enige is buiten de machine die u beveiligt. Gebruik vervolgens de kredietbudgetten per agent en de statistieken per agent die LiveContext beschikbaar stelt, zodat een enkele lus de sleutel niet kan uitputten voordat u het opmerkt.

De kosten bij inactiviteit zijn niet nul zodra een agent op een schema staat. Een schema-trigger wordt geactiveerd, ongeacht of er iemand meekijkt, en elke activering verstuurt tokens. Een schema van vijf minuten resulteert in 288 runs per dag, en een agent die een pagina leest en besluit niets te doen, betaalt nog steeds voor het lezen van de pagina. Plaats uw eerste agents op een webhook of een chat-trigger, monitor de werkelijke uitgaven gedurende een week en stap pas over op een schema nadat u de kosten per run kent.

Back-up van Postgres en de object store

Er zijn twee datastores en één secret; het verlies van een van deze drie betekent dat uw instantie verloren gaat. Maak de back-up van de database en de bucket in hetzelfde venster, terwijl de backend is gestopt. Zo voorkomt u dat een bestand wordt geschreven nadat de bijbehorende databaserij is gedumpt.

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

Gebruik de waarde die u heeft ingesteld als DB_USERNAME in plaats van postgres als u deze heeft gewijzigd. Kopieer vervolgens het object store-volume met de prefix-naam die docker volume ls heeft weergegeven:

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)

Controleer of de dump niet leeg is voordat u deze vertrouwt: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 hoort CREATE TABLE- en DROP TABLE-statements te tonen, geen foutmelding van één regel. Kopieer daarna alle drie de bestanden van de server af. Een back-up die alleen op de machine staat die hij moet beschermen, is geen back-up.

Om te herstellen op een nieuwe server, installeert u dezelfde tag, plaatst u de opgeslagen docker/.env.ce terug zodat het wachtwoord voor credential-encryptie en de salt overeenkomen, start u de stack één keer zodat de volumes bestaan, stopt u de backend en laadt u vervolgens de 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 en herstel bij fouten

Maak altijd eerst een dump. De backend voert bij het opstarten schema-migraties uit en deze migraties zijn alleen voorwaarts gericht. Het terugkeren naar een oudere tag na een mislukte upgrade zorgt er dus voor dat oude code op een nieuwer schema draait. Een rollback betekent het terugzetten van de dump; daarom is de dump de eerste stap.

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

Stel TAG in op de tag die u heeft gekozen uit de lijst die het derde commando heeft gegenereerd. Monitor het backend-logbestand totdat het health-endpoint weer reageert. Uw docker-compose.override.yml wordt niet bijgehouden door versiebeheer, dus een git checkout laat dit bestand ongewijzigd. Controleer echter het verschil in docker-compose.yml tussen de tags, aangezien een nieuwe of hernoemde service uw override ongeldig kan maken zonder dat er een foutmelding verschijnt.

Foutmodi en bijbehorende meldingen

Een container blijft herstarten en docker compose ps toont exited (137). Dit is de out-of-memory killer van de kernel en docker inspect livecontext-app bevestigt dit met "OOMKilled": true in het statusblok. De backend heeft de limiet van 1536M bereikt of het geheugen van de host is uitgeput. Controleer free -m voordat u een limiet verhoogt, aangezien het verhogen van een containerlimiet op een host zonder vrije ruimte de crash enkel verplaatst naar een andere container.

De pull mislukt met no matching manifest for linux/arm64/v8 in the manifest list entries. De images zijn uitsluitend gepubliceerd voor linux/amd64. Een Arm VPS kan deze stack niet draaien met de gepubliceerde images en emulatie via QEMU is veel te traag voor een JVM in combinatie met Chromium. Stap over naar een x86-plan.

Bind for 0.0.0.0:3000 failed: port is already allocated. Een ander proces op de host gebruikt deze poort al. Wijzig FRONTEND_PORT in docker/.env.ce of pas de bovenstaande override toe en publiceer helemaal niets.

De UI is bereikbaar, maar het inlogverzoek mislukt nadat u de proxy heeft toegevoegd. De browser roept de backend aan op een origin die uw proxy niet bedient. Open het netwerktabblad van de browser en bekijk de host van het falende verzoek. Stel GATEWAY_PUBLIC_URL in op de publieke backend-URL en maak de frontend-container opnieuw aan, omdat deze waarde bij het opstarten wordt ingelezen.

Alles is in orde, maar bestanden die in een workflow zijn geüpload, verdwijnen. Controleer of minio-init de waarde exited (0) toont in plaats van een code die niet nul is. Als de bucket workflow-files nooit is aangemaakt, heeft de backend geen locatie om objecten op te slaan.

Kies tussen LiveContext of n8n

Kies voor LiveContext als de agent centraal staat: u wilt dat het model de automatisering bouwt en uitvoert, en u accepteert een 8 GB server en een Java-service als prijs. Kies voor n8n als u deterministische workflows, een uitgebreide bibliotheek aan nodes en een footprint wilt die een VPS deelt met andere services. De versienummers zijn hier nog jong, v0.2.11 per augustus 2026, dus zet uw tag vast en lees de release notes vóór elke upgrade. Voor het bredere veld, inclusief de tools die zich tussen deze twee posities bevinden, raadpleeg ons overzicht van self-hosted n8n-alternatieven in plaats van alleen een vergelijking tussen deze twee te lezen.

FAQ

Hoeveel RAM heeft een zelfgehoste LiveContext nodig?

Houd rekening met 8 GB. De upstream README vermeldt 4 GB als minimum en 8 GB als aanbeveling; het meegeleverde compose-bestand volgt deze richtlijn: de backend alleen al is begrensd op 1536 MB, en de vijf basisservices verbruiken samen iets minder dan 3 GB, nog voor de onbeperkte frontend-container. Het inschakelen van het browser-agentprofiel voegt nog eens 2048 MB toe voor Chromium plus een SearXNG-container, waardoor 8 GB op dat punt niet langer optioneel is.

Kan ik LiveContext draaien op een Arm VPS?

Nee. Elke gepubliceerde image is gebouwd voor linux/amd64, waardoor docker compose up op een Arm-abonnement faalt bij de pull met no matching manifest for linux/arm64/v8 in the manifest list entries. Het draaien onder QEMU-emulatie is in theorie mogelijk, maar in de praktijk onbruikbaar voor een JVM-workload. Kies een x86-abonnement.

Waar plaats ik mijn model API-sleutel?

In docker/.env.ce, als ANTHROPIC_API_KEY, OPENAI_API_KEY of GOOGLE_API_KEY, vóór de eerste start. De backend en de bridge lezen deze bij het opstarten; de sleutel is van toepassing op de gehele instantie in plaats van op één gebruiker. Houd het bestand op mode 600, gebruik een sleutel die uitsluitend voor deze server is aangemaakt zodat u deze afzonderlijk kunt intrekken, en stel een uitgavenlimiet in via de console van de provider, aangezien die limiet de enige beperking is die buiten de machine zelf bestaat.

Hoe maak ik een back-up van LiveContext?

Drie zaken: een pg_dump van de livecontext-database, een kopie van het MinIO-volume en het docker/.env.ce-bestand. Stop de livecontext- en frontend-services terwijl u de eerste twee kopieert, zodat de database en de object store consistent met elkaar blijven. Het env-bestand is essentieel omdat de in uw workflows opgeslagen inloggegevens zijn versleuteld met CREDENTIAL_ENCRYPTION_PASSWORD en CREDENTIAL_ENCRYPTION_SALT; een herstelactie zonder deze waarden resulteert in rijen met inloggegevens die op de nieuwe machine door niets kunnen worden gelezen.

Waarom blijft de backend na het opstarten minutenlang op health: starting staan?

De compose-healthcheck stelt start_period: 120s in en pollt /actuator/health, waardoor Docker de service als 'starting' rapporteert terwijl de schema-migraties en de tool-registratie worden uitgevoerd. Twee tot drie minuten bij de eerste keer opstarten is normaal. Als de status nooit 'healthy' wordt, lees dan docker compose logs -f livecontext. Een stack die blijft hangen bij de migratiestap verwijst meestal naar een databasevolume van een nieuwere release.