How to Self-Host LiveContext as n8n Alternative

Wetin LiveContext be, and wetin e cost to run

To self-host LiveContext, you need VPS wey get about 8 GB of RAM. LiveContext CE na open source automation platform wey dey run AI agents inside the automation itself. E dey come as Docker Compose stack of six containers wey Java backend dey power. The upstream README talk say 4 GB na minimum and 8 GB na recommendation. The compose file show where dem dey use that memory.

The project dey for livecontext-ai/livecontext-ce on GitHub, and AGPL-3.0 license cover am. As of August 2026, the current release na v0.2.11, wey dem publish on 3 August 2026. Every image na for linux/amd64 only, so cheap Arm plans no go work. This guide pin that tag, put the stack behind reverse proxy, and explain the backup procedure wey upstream docs no include.

Set the VPS size before you self-host LiveContext

Every service for the shipped compose file get explicit memory limit, so you fit size the box before you rent am. These na the limits wey dey inside the v0.2.11 compose file, no be measured usage.

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

The backend alone get cap of 1536 MB. This cap dey over Java 21 process, so the JVM go grow reach most of am and remain there. The five base services together use almost 3 GB, and the frontend no get any limit, so e go take wetin Node ask for. For 4 GB VPS, almost nothing go remain for the kernel and page cache. Na why dem write 4 GB as minimum, no be recommendation.

The optional profiles na wetin push the box 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. That SearXNG container dey serve as the agent search backend. Because of this, the pages wey e return go enter your prompts as untrusted text. Na this trust boundary giving an AI agent SearXNG web search explain in detail.

If you already dey run n8n, plan to replace am instead of adding to am. The stack for our guide to running n8n on a VPS with Docker and HTTPS na one Node process together with Postgres, and e dey comfortable for small box. LiveContext reserve more resources for the backend alone pass the whole stack. 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 host, put explicit limits for every other thing 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.

LiveContext install with Docker Compose, pin am to a tag

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 a VPS first, then come back.

The README get npx livecontext as one-line start command. E fit work for laptop. But for server, you need make compose file dey inside directory wey you control. This one mean say upgrade na just git checkout, and you fit read exactly wetin change.

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

The compose file don already pin every image to e release tag, like ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Checking out the matching git tag na wetin keep the compose file and the images in sync, because the compose file for v0.2.11 na for those images dem write am. No edit the tags to 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., and the only way back go be restore.

Edit docker/.env.ce before the first start. The next section list wetin you need change. After that, 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 you run command. So if command no get the flag, e go use the 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. Because of this, docker compose ps go report say livecontext service dey health: starting for about the first two minutes while schema migrations and tool registration dey run. This one normal. Quick check from the server:

curl -s localhost:8080/actuator/health

This one suppose print {"status":"UP"}. Once e do, open the web UI for port 3000. The first account wey you create go become the admin, so create your own before anybody else fit reach the port. This na the main reason why you no suppose publish port 3000 to the internet on the first day.

Env value wey you must change

The example file get working defaults, so the stack fit start for laptop. But some of dem no safe for public 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

Use openssl rand -base64 32 generate each random value. Make you note these ones wey fit cause problem:

• POSTGRES_PASSWORD and MINIO_ROOT_PASSWORD ship as postgres and minioadmin. No database port dey published to the host, so dem no expose directly. But any container wey you later connect to the same network fit reach both with the documented default.
• CREDENTIAL_ENCRYPTION_PASSWORD and CREDENTIAL_ENCRYPTION_SALT go generate by themselves if you leave dem empty. Set dem yourself instead. Your workflows store credentials encrypted with that pair. So, if you restore database dump for new box without the same password and salt, you go get credential rows wey nobody fit read. Set dem once, then treat docker/.env.ce as part of the backup.
• FRONTEND_PORT and BACKEND_PORT dey substituted inside the port mappings as ${FRONTEND_PORT:-3000}:3000 and ${BACKEND_PORT:-8080}:8080. The example env file set both explicitly, and the values wey e ship no always be 3000 and 8080. Read your own copy instead of assuming.
• GATEWAY_PUBLIC_URL na the browser-facing origin of the backend. E become important once 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 six containers dey do

• postgres dey run pgvector/pgvector:pg16 as container livecontext-db, and e dey hold 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. That policy na deliberate: 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 disappear without trace.
• minio na the S3-compatible object store for files wey dey move through workflows. One-shot minio-init container dey run mc mb myminio/workflow-files --ignore-existing for startup, create the bucket, then exit. If you see minio-init as exited (0) inside docker compose ps, that one mean say everything dey okay.
• bridge dey hold the CLI adapters and the MCP (model context protocol) tools. E dey listen for 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 live for five named volumes: livecontext_data for Postgres, livecontext_redis, livecontext_minio, livecontext_keys, and livecontext_logs. Compose dey prefix dem with the project name, wey by default na the directory name, so the real volume name for disk fit be something like livecontext-ce_livecontext_minio. Run docker volume ls and copy the exact names before you write any backup script wey go use dem.

docker compose down -v dey delete all five volumes. Na the documented way to start over, and na also the fastest way to lose every workflow wey you don build. -v na the whole difference.

Put am behind Traefik instead of publishing port 3000

Publishing ports 3000 and 8080 on 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 im own iptables rules for published ports ahead of the chain wey ufw dey manage. So, port wey publish to 0.0.0.0 go still dey reachable even when ufw talk 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 for repo root:

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

networks:
  proxy:
    external: true

Two details decide 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, because for older Compose, the two lists go merge and the ports go remain published. Also, default must remain inside every networks list. When you name any network, e dey replace the default one, so if you leave am out, frontend no go fit reach Postgres and Redis. 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 na the same ones wey you use 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 backend need im 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. If you skip am, the page go load normally but every action go fail, because the UI resolve the backend origin from the address wey you open, then e dey 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. That way, nobody go see the page without authenticating at the proxy. Na this 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 here, and this one change the economics 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.

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 one secret. If any one of the three loss, your instance go loss. Back up the database and bucket for the same time window, while backend dey stopped. This one make sure say no file fit write after dem dump the database row wey belong to am.

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 volume, using the prefixed name 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 compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

Check say the 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 three files comot from the server. 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 go exist, stop the backend, 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 when something spoil

Make dump first, every time. The backend dey apply schema migrations when e start, and migrations only dey move forward. So, if you checkout the older tag after bad upgrade, old code go dey run against newer schema. Rollback mean say you restore the dump. Na why dump come first.

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

Set TAG to the tag wey you pick from the listing wey the third command print. Monitor the backend log until the health endpoint answer again. Your docker-compose.override.yml no dey tracked, so git checkout go leave am where e dey. But read the diff for docker-compose.yml between tags, because new service or renamed service fit make your override stale without any error message.

Failure modes, plus the strings wey you go see

Container dey restart again and again, and docker compose ps dey show exited (137). Na kernel out-of-memory killer cause am, and docker inspect livecontext-app confirm am with "OOMKilled": true for the state block. Backend don reach im 1536M limit, or 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 free memory, na only 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 emulation through QEMU slow too much 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. Change FRONTEND_PORT for docker/.env.ce, or apply the override above and publish nothing at all.

UI dey up, but login request dey fail after you add the proxy. Browser dey call backend with origin wey your proxy no dey serve. Open 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 e 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 bucket workflow-files, backend no get anywhere to put the objects.

Choose LiveContext or n8n

Choose LiveContext when na the agent be the main focus: you want the model to build and run the automation, and you accept 8 GB box plus Java service as the price. Choose n8n when you want workflows wey behave predictably, plenty node library, and small resource usage wey fit share VPS with other services. The version numbers here still new, v0.2.11 as of August 2026, so pin your tag and read the release notes before every upgrade. For the wider field, including tools wey dey between these two options, 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 upstream README talk say 4 GB na minimum and 8 GB na recommendation, and the compose file wey come with am match this: backend alone get limit of 1536 MB, while the five base services together dey use a little under 3 GB before the frontend container wey get no limit. If you enable browser agent profile, e add another 2048 MB for Chromium plus one SearXNG container. So at that point, 8 GB no longer be optional.

I fit run LiveContext for an Arm VPS?

No. Every published image na for linux/amd64, so docker compose up for an 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 practical use the performance no good for JVM workload. Choose an x86 plan.

Where I go put my model API key?

Put am for docker/.env.ce, as ANTHROPIC_API_KEY, OPENAI_API_KEY or GOOGLE_API_KEY, before the first start. Backend and bridge dey 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. Also set a spend cap for provider console, because na that cap be the only limit wey dey outside the machine.

How I go back up LiveContext?

You need three things: a pg_dump of the livecontext database, a copy of the MinIO volume, and the docker/.env.ce file. Stop the livecontext and frontend services while you dey take the first two backups, so the database and object store go remain consistent. The env file matter because credentials wey dey stored 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 go fit read dem.

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

The compose healthcheck sets start_period: 120s and polls /actuator/health. Because of this, Docker reports 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 stack stop for migration step, e usually mean say e dey point to database volume from newer release.