How to Self-Host LiveContext CE Without Memory Wahala

LiveContext na wetin, and how much e cost to run

To self-host LiveContext, you need VPS wey get about 8 GB RAM. LiveContext CE na source-available automation platform wey dey run AI agents inside the automation itself. E dey ship as Docker Compose stack of seven containers wey dey built around Java backend. One of the containers na one-shot job wey go exit after setup. The vendor self-hosting docs ask for 4 GB minimum and recommend 8 GB. The README for its npm launcher now talk say 6 GB na minimum. The compose file show where the memory dey go.

The project first publish as livecontext-ai/livecontext-ce for GitHub under AGPL-3.0, but CE no longer dey under AGPL. The licence wey come with the current release na LiveContext Sustainable Use License 1.1. Na source-available licence wey allow you run and modify CE, including for production inside your own business. But e no allow you offer am to third parties on hosted or embedded basis to compete with LiveContext paid versions. The vendor npm launcher show the change: livecontext@0.2.11 declare AGPL-3.0-only, while livecontext@0.3.8 point to that licence file. As of 13 October 2026, the GitHub repository and the livecontext-ai organisation both dey return 404. But the vendor docs still tell you to clone am, so this guide dey take the release files from the npm package instead. The current release na v0.3.8, wey publish on 9 October 2026. Every LiveContext image dey built for linux/amd64 only, so cheap Arm plans no go work. This guide pin that tag, put the stack behind reverse proxy, and turn the upstream backup advice into commands.

Size VPS before you self-host LiveContext

Most services for the compose file wey dem ship get clear memory limit, so you fit size the machine before you rent am. Two no get limit: the one shot minio-init job and the frontend. These na the limits wey dey inside the v0.3.8 compose file; dem no be measured usage.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 2048
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "postgres",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

The backend alone get cap of 2048 MB. This cap dey over Java 21 process wey heap set to 1 GiB (-Xmx1024m with ZGC). The comment for the compose file itself talk say the heap fit grow reach the full GiB, plus the JVM own overhead. The five base services wey get limits add up to about 3.6 GB. The frontend no get any limit, so e go use as much memory as Node request. For 4 GB VPS, these limits alone leave only few hundred MB for the frontend, kernel, and page cache. Na why the launcher's README now put the minimum at 6 GB, even though the self-hosting docs still talk say 4 GB enough.

The optional profiles na wetin push the machine reach 8 GB. The browser agent profile add Chromium container wey get cap of 2048 MB, together with SearXNG search instance. The renderer profile add another 1024 MB for screenshots and PDFs. None of dem go start unless you enable the profile, so leave both off until you need dem. Dem build the Chromium container locally from a websearch-service directory wey the npm package no ship. So, because the GitHub repository no dey reachable, you no fit build the browser agent profile from the published files as of 13 October 2026. The renderer dey use published image, so this issue no affect am. That SearXNG container dey serve as the agent's search backend. This means the pages wey e return go enter your prompts as untrusted text. Na this trust boundary giving AI agent SearXNG web search explain in detail.

If you already dey run n8n, plan to replace am instead of adding LiveContext beside am. The stack for our guide to running n8n on VPS with Docker and HTTPS na one Node process beside Postgres, and e dey comfortable for small machine. LiveContext reserve more memory for the backend alone than the whole n8n stack dey use. Two automation platforms for one 8 GB VPS go fit work until both of dem run a job for the same minute. If you share one host, put clear limits on every other service too, using the method for our post on setting memory limits in Docker Compose, so one runaway workflow no go bring the whole machine down.

Docker Compose use tag wey pin install LiveContext

Start with clean Ubuntu 24.04 VPS wey get Docker Engine 24 or newer and Compose v2. If Docker never dey installed, follow our Docker Compose basics for VPS first, then come back.

The launcher README offer npx livecontext@latest as one-line start. E dey okay for laptop, but the launcher dey copy compose file again every time e run, and the images wey e name get latest tags. For server, you want compose file dey inside directory wey you control, and pin am to one release, so upgrade go be file wey you fit compare. Vendor docs still describe git clone of the GitHub repository for this, but that repository dey return 404 as of 13 October 2026. So take the same two files — the compose file and example env file — from the npm package of the release wey you want.

sudo apt update && sudo apt install -y npm
npm view livecontext version
mkdir -p ~/livecontext-ce/docker ~/livecontext-ce/catalog-seeds
cd ~/livecontext-ce
npm pack livecontext@0.3.8
tar xzf livecontext-0.3.8.tgz
cp package/assets/docker-compose.yml .
cp package/assets/.env.example docker/.env.ce
chmod 600 docker/.env.ce

The compose file dey bind-mount ./catalog-seeds into the backend, na why dem create the directory above. The npm launcher dey fill am with model catalog bundle wey e download when e start, and the stack dey start with the directory empty.

The compose file for the npm package dey name every LiveContext image with latest tag, for example ghcr.io/livecontext-ai/livecontext-ce:latest, even though the header comment inside am talk say the tag dey pinned to the release. Pin am yourself before the first start. Vendor dey publish the same release tags for Docker Hub under livecontext namespace. v0.3.8 dey listed for backend, frontend, bridge, and renderer images on 13 October 2026, so point the four images there:

sed -i -E 's#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v0.3.8#' docker-compose.yml
grep -n 'image:' docker-compose.yml

If you take compose file from the same release as the images, the two go remain compatible, because the compose file for v0.3.8 na those images e target. No leave the tags for latest. latest tag fit change without warning, and the backend dey run database migrations every time e start. So accidental pull fit move your schema forward at 3 a.m. without any way to go back except restore.

Edit docker/.env.ce before the first start. The next section list wetin you need change. Then bring the stack up.

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

Use the same --env-file flag for every compose command for this guide. Compose dey read that file fresh every time e run. So command wey no get the flag go fall back to defaults wey dey inside the compose file, and e fit publish different ports from the ones wey you configure.

The backend healthcheck get start_period of 120s and e dey poll /actuator/health. So docker compose ps go report say livecontext service dey health: starting for roughly the first two minutes while schema migrations and tool registration dey run. That one normal. Quick check from the server:

curl -s localhost:8080/actuator/health

This suppose print {"status":"UP"}. When e do, open the web UI for port 3000. The first account wey you create go become the admin, and public registration go close after that unless admin open am again. So create your account before anybody else fit reach the port. This na the main reason why you no suppose publish port 3000 to internet on day one.

Di env values wey you must change

The example file get working default values, so the stack fit start for laptop. But some of dem no safe for public server.

DB_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
PUBLIC_BASE_URL=https://lc.example.com
GATEWAY_PUBLIC_URL=https://lc-api.example.com

Use openssl rand -base64 32 generate every random value. Pay attention to these ones:

• DB_PASSWORD and MINIO_ROOT_PASSWORD come with postgres and minioadmin. The compose file pass DB_PASSWORD to Postgres as its POSTGRES_PASSWORD. No database port dey published to the host, so dem no expose directly. But any container wey you later attach to the same network fit reach both with the documented default.
• CREDENTIAL_ENCRYPTION_PASSWORD and CREDENTIAL_ENCRYPTION_SALT dey commented out by default, and the system auto-generates dem for first boot when dem remain empty. Set dem yourself instead. The credentials wey your workflows store dey encrypted with that pair. So, if you restore database dump for another box without the same password and salt, you go get credential rows wey nothing fit read. Set dem once, then treat docker/.env.ce as part of the backup.
• FRONTEND_PORT and BACKEND_PORT dey substituted into the port mappings as ${FRONTEND_PORT:-3000}:3000 and ${BACKEND_PORT:-8080}:8080. The example env file get both commented out as # FRONTEND_PORT=3000 and # BACKEND_PORT=8080. So the defaults 3000 and 8080 go apply until you uncomment one line to override am.
• PUBLIC_BASE_URL na the browser-facing address of the web UI. The example file ask server installations to set am together with GATEWAY_PUBLIC_URL. Write both without trailing slash, because the example file warn say one fit break OAuth callbacks.
• GATEWAY_PUBLIC_URL na the browser-facing origin of the backend. E become important as soon as reverse proxy dey involved. See the next section.
• The model keys (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, and optionally MISTRAL_API_KEY or DEEPSEEK_API_KEY) dey here as plain text. Fill only the provider wey you actually use.

Wetin the seven containers dey do

• postgres dey run pgvector/pgvector:pg16 as container livecontext-db, and e dey hold the database wey dem name livecontext. The pgvector extension dey there for embedding search, so ordinary postgres:16 image no go work.
• redis dey run redis:7-alpine with appendonly yes and --maxmemory-policy noeviction. Dem set am like that on purpose: Redis dey carry queue and run state for here, so when e reach im memory limit, e go return error to the writer instead of silently dropping keys. Error wey you fit see better pass work wey just disappear.
• minio na the S3-compatible object store for files wey dey pass through workflows.
• minio-init na one-shot container wey dey run mc mb myminio/workflow-files --ignore-existing when e start, create the bucket, then exit. If you see minio-init as exited (0) for docker compose ps, na the healthy state be that.
• bridge dey hold the CLI adapters and the MCP (model context protocol) tools. E dey listen on 8093 inside the Docker network, and e no dey publish to the host.
• livecontext na the backend, one Java 21 monolith for port 8080. E dey run the workflow engine, the schedulers, and the agents.
• frontend na the Next.js web UI for port 3000. Na only these last two dem publish to the host.

State dey inside seven named volumes: livecontext_data for Postgres, livecontext_redis, livecontext_minio, livecontext_keys, livecontext_bridge_secret, livecontext_cli_home, and livecontext_logs. Compose dey prefix dem with the project name, wey the compose file set to livecontext-ce, so the real volume for disk fit get name like livecontext-ce_livecontext_minio. The npm launcher dey override that name with -p livecontext, so box wey don run npx livecontext before go carry another set wey get livecontext_ prefix. Run docker volume ls and copy the exact names before you write any backup script against dem.

docker compose down -v dey delete all seven volumes. The vendor docs talk say make you never run am, because na the fastest way to lose every workflow wey you don build. Na -v be the whole difference.

Put am behind Traefik instead of publishing port 3000

Publishing ports 3000 and 8080 for public VPS dey expose the app without TLS (transport layer security) and without any gate in front of admin registration. A ufw rule no dey enough by itself, because Docker dey insert its own iptables rules for published ports before the chain wey ufw dey manage. So, port wey publish to 0.0.0.0 go still dey reachable even when ufw say the port dey denied.

The clean fix na to publish nothing, then make the proxy reach the containers through one shared Docker network. Create docker-compose.override.yml beside docker-compose.yml:

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

networks:
  proxy:
    external: true

Two details determine whether this go work. !override dey replace the ports list instead of merging with am, and this one need Compose v2.24 or newer: check am with docker compose version. For older Compose, the two lists go merge and the ports go remain published. Also, default must remain inside every networks list, because once you name any network, e go replace the default one. If you leave am out, the backend no go reach Postgres and Redis, and the frontend no go reach the backend. Confirm the merged result before you start anything:

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

The routers, certificate resolver, and HTTP to HTTPS redirect remain the same like for any other app. So follow our Traefik reverse proxy guide for running multiple apps on one VPS instead of writing new TLS config here. Route one hostname to frontend on port 3000, and another hostname to livecontext on port 8080.

The second hostname no be optional. The web UI dey call the backend from the browser, so the backend need its own origin wey browser fit reach. Set GATEWAY_PUBLIC_URL inside docker/.env.ce to that backend URL, for example https://lc-api.example.com, and set PUBLIC_BASE_URL to the frontend URL. If you skip am, the page go load normally, but every action go fail, because the UI go resolve the backend origin from the address wey you open and call a port wey your proxy never publish.

Since the sign-up page dey open to anybody wey reach am first, e make sense to put forward auth on the frontend router. This one go stop anybody from seeing that page without authenticating at the proxy. That na wetin running Authentik as your own SSO layer add on top of the same Traefik setup.

Where model key dey go, and why idle instance still dey cost money

Agents dey run inside the automation for here, and this dey change the cost matter compared with ordinary workflow tool. Provider key dey inside docker/.env.ce as ANTHROPIC_API_KEY or OPENAI_API_KEY. Backend and bridge dey read am when dem start, and e apply to the whole instance. E no dey limited to each user. Anybody wey get account for your instance and fit build agent dey spend that key. The first person wey register na admin. If wetin you need na agents and spending for each person wey you fit assign to one colleague, self-hosting OneCLI as harness for one agent per person dey solve the same key problem from the other side. E put every model key behind gateway wey sabi who dey make the call.

Three habits fit help make bill predictable. Create separate provider key for this VPS, so you fit revoke am without touching anything else. Set hard spend cap for provider console, because na that limit be the only one outside the machine wey you dey secure. Then use per-agent credit budgets and per-agent metrics wey LiveContext dey provide, so one loop no fit drain the key before you notice.

Idle cost no be zero once agent dey run on schedule. Schedule trigger go fire whether anybody dey watch or not, and every firing dey send tokens. Five minute schedule na 288 runs per day. Agent wey read page and decide say e no go do anything still go pay for reading the page. Put your first agents on webhook or chat trigger. Watch the real spend for one week, then move go schedule after you know the cost per run.

Back up Postgres and object store

Data store two dey, plus two places wey hold secrets: the env file and the livecontext_keys volume. Vendor docs list these volumes among the ones wey you suppose back up. If you lose any of dem, you lose your instance. Back up the database and bucket within the same time window, while backend dey stopped. This one make sure say file no write after its database row don dump.

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

Use anything wey you set as DB_USERNAME instead of postgres if you change am. Then copy the object store and keys volumes. Use the prefixed names wey docker volume ls print:

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker run --rm \
  -v livecontext-ce_livecontext_keys:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-keys-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

Check say dump no empty before you trust am: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 suppose show CREATE TABLE and DROP TABLE statements, no be one-line error. Then copy all four files comot from the server, together with docker-compose.yml and your override file. Backup wey dey only for the machine wey e suppose protect no be backup.

To restore am for fresh box, install the same tag. Put the saved docker/.env.ce back so the credential encryption password and salt match. Start the stack once so the volumes fit exist. Stop the backend. Unpack the keys archive into the keys volume the same way you take collect am. Then load the 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, and how to recover if something go wrong

Always create a dump first. The backend applies schema migrations when e start, and migrations only move forward. So if bad upgrade happen and you go back to the older tag, old code go dey run against newer schema. Rollback means restoring the dump. Na why the dump must come first.

cd ~/livecontext-ce
npm view livecontext version
TAG=0.3.8
npm pack "livecontext@$TAG"
rm -rf package && tar xzf "livecontext-$TAG.tgz"
cp docker-compose.yml docker-compose.yml.prev
cp package/assets/docker-compose.yml .
sed -i -E "s#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v$TAG#" docker-compose.yml
diff docker-compose.yml.prev docker-compose.yml
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

Set TAG to the version wey the second command print. Monitor the backend log until the health endpoint answer again. Your docker-compose.override.yml no dey inside the package, so when you copy the new compose file, e go remain there. But read the diff wey the diff command print, because new service or renamed service fit make your override stale without showing any error message. Compare docker/.env.ce with package/assets/.env.example too, because new settings fit dey there.

Failure modes, plus the strings wey you go see

A container dey restart steady and docker compose ps dey show exited (137). Na kernel out-of-memory killer cause am, and docker inspect livecontext-app dey confirm am with "OOMKilled": true for the state block. The backend don reach im 2048M limit, or the host run out of memory first. Check free -m before you increase any limit, because if you increase container limit for host wey no get spare memory, na just another container go get killed.

The pull fail with no matching manifest for linux/arm64/v8 in the manifest list entries. Dem publish the images for linux/amd64 only. Arm VPS no fit run this stack from the published images, and QEMU emulation too slow for JVM plus Chromium. Move go x86 plan.

Bind for 0.0.0.0:3000 failed: port is already allocated. Another thing for the host don already hold that port. Set FRONTEND_PORT inside docker/.env.ce, or apply the override wey dey above and no publish any port at all.

The UI dey up but login request fail after you add the proxy. The browser dey call the backend through an origin wey your proxy no serve. Open the browser network tab and check the host for the request wey fail. Set GATEWAY_PUBLIC_URL to the public backend URL and recreate the frontend container, because dem dey read that value when e start.

Everything healthy but files wey you upload for workflow dey disappear. Check say minio-init dey show exited (0) instead of non-zero code. If dem never create the bucket workflow-files, the backend no get place to put the objects.

LiveContext or n8n choose

LiveContext choose when agent na the main thing: you want the model to build and run the automation, and you accept say 8 GB box and Java service na the price. n8n choose when you want workflows wey dey deterministic, plenty node library, and footprint wey fit share VPS with other services. Licences no longer dey separate the two. LiveContext CE move from AGPL-3.0 go LiveContext Sustainable Use License 1.1, wey be source-available licence from the same fair-code family as n8n Sustainable Use License, so read the hosting restriction before you offer either one to anybody outside your company. Self-hosted n8n still keep some features for paying customers only, so check which parts of n8n free be and which ones need licence key before you build team workflow around any of dem. The version numbers here still young, v0.3.8 as of 13 October 2026, and the 0.3 line release nine releases between 22 September and 9 October 2026, so pin your version and read wetin change before every upgrade. For the wider field, including tools wey dey between these two positions, see our roundup of self-hosted n8n alternatives instead of reading comparison of only these two.

FAQ

How much RAM self-hosted LiveContext need?

Plan for 8 GB. The vendor self-hosting docs list 4 GB as the minimum and 8 GB as the recommendation, while the launcher's README now says 6 GB minimum. The compose file wey dem ship explain why: the backend alone get cap of 2048 MB, and the five base services together get limits of about 3.6 GB before the frontend container wey no get limit. If you enable the browser agent profile, e add another 2048 MB for Chromium plus one SearXNG container. So from that point, 8 GB no be optional again.

I fit run LiveContext for Arm VPS?

No. Every LiveContext image wey dem publish for v0.3.8 build for linux/amd64, so docker compose up for Arm plan go fail during pull with no matching manifest for linux/arm64/v8 in the manifest list entries. E fit work under QEMU emulation in theory, but for JVM workload e no usable for real life. Choose x86 plan.

Where I go put my model API key?

For docker/.env.ce, as ANTHROPIC_API_KEY, OPENAI_API_KEY or GOOGLE_API_KEY, before the first start. The backend and the bridge read am during startup, and e apply to the whole instance, no be only one user. Keep the file for mode 600. Use key wey you create only for this server so you fit revoke am separately. Set spend cap for the provider console too, because na that cap be the only limit wey dey outside the machine.

How I go back up LiveContext?

Four things: a pg_dump of the livecontext database, copy of the MinIO volume, copy of the livecontext_keys volume, and the docker/.env.ce file. Stop the livecontext and frontend services while you take the dump and copy the volumes, so the database and object store go remain consistent with each other. The env file matter because credentials wey you store for your workflows dey encrypted with CREDENTIAL_ENCRYPTION_PASSWORD and CREDENTIAL_ENCRYPTION_SALT. If you restore without those values, credential rows go remain, but nothing for the new box fit read dem.

Why backend dey stay for health: starting for minutes after boot?

The compose healthcheck set start_period: 120s and dey poll /actuator/health, so Docker report the service as starting while schema migrations and tool registration dey run. Two to three minutes for first boot dey expected. If e never become healthy, read docker compose logs -f livecontext. If the stack stop for migration step, e usually mean say e dey point to database volume from newer release.