LiveContext CE: a self-hosted AI automation platform where chat builds the workflow

The problem LiveContext CE targets: four tools stitched into one automation

Most teams building an internal automation end up assembling four separate things: a chatbot for the conversational front end, a workflow tool for the triggers and steps, an app builder for the screen a human actually clicks, and an agent framework for the parts that need a model. LiveContext's README states the project is all four on one canvas, and that framing is the whole pitch. The repository is the Community Edition, described as the full platform as a single self-hosted service, free to self-host and use in production inside your organization.

The intended user is a team that wants automation without owning four vendors and four sets of credentials. The README positions it as an open-source, self-hosted alternative to n8n, Zapier and Make, with AI agents built in, and the repository topics list both n8n-alternative and zapier-alternative. That is a crowded comparison set. What distinguishes the claim is the unit of work: instead of a node graph you assemble by hand, you describe the job in chat and the platform produces a workflow you can read, agents with scoped access and budgets, and a small app. Whether the generated graph is good enough to keep is the question any evaluation has to answer, and the README does not make that argument for you.

How the workflow scopes each agent, and why that is the design decision that matters

The README's central technical claim is about containment. Agents are described as a fleet, one per job, each with its own model, tools, files, credit budget and audit trail. The workflow, not the agent, decides what each agent sees and what it ships. That is a different architecture from the common pattern of one general agent with a broad tool list, and the README argues the consequence directly: the same job runs at a fraction of the cost of a do-everything agent, every step is auditable, and your business never sits inside a black box.

Read that as a trade-off rather than a feature list. Narrow scoping means someone has to decide the boundaries, and in this design the workflow is where those boundaries live. You get auditability and budget control per agent, and you pay for it in graph complexity: more agents, more edges, more places for a mis-scoped tool to sit. The repository layout supports the split the README describes. There is a backend directory and a frontend directory, a cli directory for the npm wrapper, a mcp directory, and separate top-level directories for screenshot-renderer, searxng and websearch-service, which correspond to the optional add-ons the README mentions. The topics list names Spring Boot and Next.js, and the README badges show Java 21 and Next.js 16, so the backend and frontend are not the same runtime and you should expect to operate both.

Alongside workflows and agents, the README describes built-in data tables that workflows and agents read, write and enrich, with filter, search and export, and no external database to wire up. It also describes per-run metrics: calls, tokens, success rate and duration, sliced per agent and per tool. Those two pieces are what make the scoping claim checkable in practice. If you cannot see which agent spent what, the budget argument is theoretical.

Installing LiveContext CE with npx or Docker Compose

The README gives two install paths. The fastest is a single npm command, and Docker must be installed and running first. The CLI wraps Docker Compose; the README is explicit that it does not replace Docker.

npx livecontext

That command pulls the images, boots the whole stack, and serves on http://localhost:3000. The README documents two companion commands: npx livecontext down stops it, and npx livecontext update upgrades it. If you would rather not put an npm wrapper in front of your containers, the second path is Docker Compose from a clone of the repository.

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d
docker compose ps

The compose file in the repository pulls prebuilt images from GHCR rather than building locally, and its header comment states the image tag is pinned to the release, so a clone always runs the matching version. The README says the livecontext service runs database migrations and registers its tools on first boot, and that you should wait until it reports healthy before using the app. Then open http://localhost:3000 and create the first account; the first user becomes the admin. Requirements are Docker Engine 24 or later with Compose v2 (or Docker Desktop 4.x and later), with 4 GB RAM minimum and 8 GB recommended.

Configuration lives in an env file. The README says to copy docker/.env.ce.example to set your own values and never commit it, and points at docker/README-CE.md for LLM keys, SMTP and ports. The compose file documents passing it with --env-file docker/.env.ce. Two ports matter: FRONTEND_PORT defaults to 3000 and BACKEND_PORT defaults to 8080. If you run this on a NAS, LAN server or VPS, the README says nothing needs rebuilding, because the web UI resolves the backend origin at runtime from the address you opened it with. Publish both ports. Behind a reverse proxy on a single origin, set GATEWAY_PUBLIC_URL on the frontend service instead. Deployment through Portainer, Coolify or Dokploy is covered in templates/README.md.

One thing to settle before you expect agents to do anything: the compose file states that for agents to run you connect to LiveContext Cloud (recommended) or add your own OpenAI, Anthropic or Google key in the app.

The optional add-ons cost real memory, and they are off by default

A default docker compose up starts neither optional feature, and the compose file says that is deliberate: it keeps the stack light. The first add-on is a renderer for interface-node screenshots as PNG and PDF rendering, which the compose file describes as roughly 1 GB of Playwright and Chromium. It is enabled by passing docker/.env.ce.renderer as the env file. The second is a browser agent providing agent_browse and web_search, described as heavy Chromium plus SearXNG at roughly 2 GB, enabled through docker/.env.ce.browser-agent. The repository carries matching top-level directories for the renderer, the SearXNG configuration and the websearch service.

This is the part of the deployment that catches people out. The 4 GB minimum in the requirements is for the base stack. Turn on the browser agent and you have added roughly 2 GB of Chromium and search infrastructure on top of the application, its database work and whatever else runs on the host. On a small VPS or a NAS with modest memory, the base install may be comfortable while the add-ons are not. The compose file also notes the model for the browser agent is picked per AI provider, so the add-on is not self-contained either; it still depends on the provider configuration you set in the app.

Where LiveContext CE is the wrong tool

The gap that matters most is upgrade and rollback. The README documents npx livecontext update and a pinned image tag, and the compose file explains that the tag matches the release. Nothing in the documentation describes how to go back to a previous version, whether database migrations are reversible, or what a failed upgrade leaves behind. The README does not document rollback. If your environment requires a tested downgrade path before you touch production, this project does not give you one on paper, and you would be testing that yourself.

Second, the API surface is undocumented. There is a backend on port 8080 and a mcp directory in the repository, but the README does not publish an API reference, an endpoint list or an MCP server contract. If your plan is to drive LiveContext from your own code rather than from its canvas, you are working against something the documentation does not describe.

Third, the AGPL-3.0 licence is a real constraint if you intend to offer the software to others as a service. The README says CE is free to self-host and use in production inside your organization, which is a narrower statement than offering it to third parties. That distinction is worth taking to whoever handles licensing for you; this article is not legal advice.

Finally, if your automations are simple and deterministic, the AI layer is overhead. A handful of scheduled jobs and webhooks do not need scoped agents, budgets and token metrics, and you would be running a Java backend, a Next.js frontend and a database to get what a much smaller tool provides.

How LiveContext CE differs from n8n

The README names n8n directly as the thing it is an alternative to, and the difference is in what produces the graph. In n8n the conventional path is that you open the editor and place nodes yourself; the tool executes what you drew. LiveContext inverts the starting point: you describe the job in chat, and the platform builds the workflow in front of you. The README's own summary is one message in, a working automation out.

That changes where the effort goes. With a hand-built graph, correctness comes from you knowing each node's contract before you connect it. With a generated graph, the first job is reading what came back and deciding whether it is something you want to keep, which is why the README stresses that the workflow is readable. The second difference is that agents are part of the same object rather than an external service you call from a node. In LiveContext an agent has its own model, tools, files, credit budget and audit trail, and the workflow constrains what it can see. In n8n terms, that is closer to building the agent's permission boundary into the graph than to calling out to an agent runtime and trusting its configuration.

Neither approach is strictly better. A generated graph is faster to start and harder to reason about if you did not write it. A hand-built graph is slower to start and fully legible to whoever drew it. If your team already has a working n8n instance with well-understood workflows, the migration case rests on whether you want agents inside the same canvas, not on whether the existing graphs are wrong.

Maintenance, releases and what the licence means for self-hosting

The repository is not archived and the last push was on 2026-09-08. Releases have been frequent in the weeks before that date: v0.2.13 on 2026-08-26, v0.2.14 on 2026-08-29 and v0.2.15 on 2026-09-08. The version numbers themselves are the useful signal here. At v0.2.x the project is pre-1.0, and the compose file pins the image tag to the release, which means an upgrade is a deliberate version change rather than a moving target. That pinning is a good property for reproducibility and a bad one if you expect patches to arrive without you acting.

Operationally, the upgrade path the README documents is npx livecontext update, or pulling new images and re-running docker compose up -d from a clone. The compose file states the livecontext service runs database migrations on first boot. Those two facts together are the maintenance cost: every version bump may carry a migration, and the README does not describe a way back. Budget for a database backup before each upgrade, and note that the README does not tell you how to take one.

On licensing, the repository is AGPL-3.0 and the README states CE is the full platform as a single self-hosted service, free to self-host and use in production inside your organization. The repository also carries NOTICE, THIRD_PARTY_NOTICES.md and TRADEMARKS.md files, which is where the dependency and trademark details live. AGPL-3.0 obligations attach to distributing the software or offering it to users over a network, so internal use and offering it as a service to others are not the same situation. Read the licence text and the notices before you decide which one you are in.

Editorial conclusion

Adopt LiveContext CE if you want workflow automation and AI agents in one self-hosted service and you are comfortable running Docker Compose with 4 GB RAM, 8 GB recommended. Do not adopt it if you need a documented rollback path for upgrades or a published API reference, because the README documents neither. Before you commit, verify three things on your own hardware: that docker compose ps reports the livecontext service healthy on first boot, that the two published ports (3000 and 8080) are reachable from the machines that will use the app, and which model provider you will attach, since agents do not run until you connect LiveContext Cloud or add an OpenAI, Anthropic or Google key in the app.

Frequently asked questions

Official sources

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