LiveContext CE: a self-hosted AI automation platform that builds workflows from chat

The gap LiveContext CE is trying to close

Most teams end up assembling four separate things: a chatbot, an automation tool, an app builder and an agent framework. Each has its own auth, its own data store and its own notion of what an agent is allowed to touch. LiveContext CE puts those four on one canvas. The README describes the product as chat, workflow, agent and app in one self-hosted platform, and positions it as an open-source, self-hosted alternative to n8n, Zapier and Make with AI agents built in. The audience is a team that already accepts Docker and wants automation it can read, not a black box. The scoping claim is the interesting part: the workflow decides exactly what each agent sees and what it ships, so the same job runs at a fraction of the cost of a do-everything agent. That is a design position, not a benchmark. It says the workflow graph is the permission boundary, and the agent is a step inside it rather than an autonomous actor with broad access.

Four surfaces, one canvas, and how the pieces connect

The README describes four surfaces that share a canvas. Workflow is a readable graph you draw, and the app it drives is wrapped around it as forms, dashboards and live approval screens. Agents are described as a fleet, one per job, each with its own model, tools, files, credit budget and audit trail. Tables are built-in data tables that workflows and agents read, write and enrich, with filter, search and export, and no external database to wire up. Data and metrics charts every run: calls, tokens, success rate and duration, sliced per agent and per tool. The data flow implied by that layout is: a chat message produces a workflow graph, the graph invokes agents at defined steps, agents read and write Tables, and every call lands in the metrics view. The repository is Java 21 on the backend (Spring Boot is listed among the topics) with a Next.js 16 frontend, packaged as one self-hosted service rather than a set of services you compose yourself. The README does not describe the internal message bus or how a workflow step hands state to an agent, so treat the graph as the contract and the agent as a callable step, and verify the rest in the source.

Getting it running: two install paths and one env file

The README gives two ways in. The fastest is one npm command, with Docker installed and running: npx livecontext. It pulls the images, boots the whole stack and serves on http://localhost:3000. The same CLI handles lifecycle: npx livecontext down stops it and npx livecontext update upgrades it. The README is explicit that the CLI wraps Docker Compose and does not replace Docker. The second path is from a clone of the repo: run docker compose up -d from the repo root, then docker compose ps and wait until the livecontext service reports healthy and frontend is up. The livecontext service runs database migrations and registers its tools on first boot, so the first start is slower than later ones. Open http://localhost:3000 and create the first account; the first user becomes the admin. Configuration for LLM keys, SMTP and ports lives in docker/README-CE.md, and you copy docker/.env.ce.example to set your own values. The README says never commit that file. Two optional add-ons exist, one for interface screenshots and PDFs and one for a browser agent with web search, and the README describes them as one env file away. Requirements are Docker Engine 24+ with Compose v2, or Docker Desktop 4.x and later, with 4 GB RAM minimum and 8 GB recommended. Images are built for linux/amd64 and linux/arm64.

Running it on a server, NAS or VPS

Deploying to your own hardware needs no extra build step. Publish both ports, 3000 for the web UI and 8080 for the backend, and open the app at that machine's address. The README gives the example http://192.168.1.50:3000 talking to http://192.168.1.50:8080 on its own. If you put a reverse proxy in front and serve everything on a single origin, set GATEWAY_PUBLIC_URL on the frontend service to the browser-facing backend URL instead. That single key is the difference between a working single-origin deployment and a frontend that calls the wrong host, and it is the one configuration detail most likely to be missed when moving from localhost to a proxy. The README also points at templates/README.md for deployments through Portainer, Coolify, Dokploy or similar platforms. Note what is not covered: the README does not describe backup or restore for the database the livecontext service migrates, nor a documented upgrade rollback path. npx livecontext update upgrades in place, and the release cadence visible in the repository is fast, three releases between 2026-08-26 and 2026-09-08. Treat the data volume as something you need to understand before the first update, and check the Compose file for where it lives.

Where the single-service design is the wrong tool

The Community Edition is the full platform as a single self-hosted service. That is a deliberate simplification and it has edges. The first user becomes the admin, which is fine for a team instance and wrong for anything multi-tenant: there is no described path for per-organisation isolation, and the README does not mention one. The credit budget on each agent is a spend control, not a security boundary; if your requirement is that an agent cannot reach a system even when misconfigured, the workflow graph is the control you have, and it is only as good as the graph you drew. The 4 GB minimum with 8 GB recommended is for the whole stack on one host, so a small NAS that already runs other services may not have headroom, and the README does not break down which component drives the memory figure. There is also a maturity question the README cannot answer: the release history shown starts at v0.2.x, and the documentation in the supplied material does not cover failure recovery, rate limiting against LLM providers, or what happens to an in-flight workflow when the service restarts. Those are the questions to ask before this runs anything that matters.

How it differs from n8n and Zapier

The README names n8n, Zapier and Make as the alternatives it targets, so the comparison is fair to make on the axis the project itself chose. Zapier and Make are hosted: you do not run the engine, you do not hold the data, and the agent story is bolted on through integrations. n8n is the closer comparison because it is also self-hosted and graph-based, and its node catalogue is its centre of gravity. LiveContext CE differs in what sits at the centre: the README describes agents as first-class objects with their own model, tools, files and credit budget, and Tables as built-in storage so workflows and agents have somewhere to read and write without an external database. The trade-off is the other direction. n8n's breadth of pre-built integrations is the reason teams pick it, and the supplied material does not describe LiveContext's integration catalogue at all, so if your automation is mostly connecting third-party SaaS APIs, verify connector coverage before you commit. If your automation is mostly LLM work with a human approval step, the built-in agent scoping and the run-level metrics are the parts n8n does not put on the same canvas.

Licence and the cost of staying current

LiveContext CE is AGPL-3.0, and the README says it is free to self-host and use in production inside your organization. The distinction that matters is between internal use and offering the software to others over a network: the AGPL's source-availability condition attaches to network use, which is why an internal deployment and a hosted product built on this code are different propositions. The repository topics include fair-code alongside the AGPL identifier, and the README points at LICENSE for the terms. Read LICENSE rather than a summary, and get your own advice if you plan to expose a modified version to users outside your organisation. On maintenance, the visible cadence is roughly one release every one to two weeks across the three releases shown, and the upgrade command is npx livecontext update. That is a low-friction upgrade path, but it also means schema migrations run on your instance regularly, and the README does not describe a downgrade path. Pin the image tag you deploy rather than tracking latest, and take a copy of the database volume before each update.

Editorial conclusion

Adopt LiveContext CE if you already run Docker Compose, want the workflow to define what each agent can see and spend, and are comfortable with AGPL-3.0 obligations in a self-hosted service. Do not adopt it if you need a hosted control plane, a multi-tenant SaaS deployment, or a workflow engine you can embed in a closed product. Before committing, verify the docker/.env.ce.example keys against your LLM provider, confirm the first-boot migration reaches healthy in docker compose ps, and read LICENSE for what the AGPL requires of your deployment.

Official sources

1. License: AGPL-3.0
2. livecontext-ai/livecontext-ce on GitHub
3. Project website
4. README
5. Releases