LangChat: a Java and Vue platform for assembling AI agents

Eight Maven modules and a Vue console

The repository description calls LangChat an open source AI Agent application platform built by the LangChat Team, and the repository layout backs that up. The root `pom.xml` sits above eight Maven modules: `langchat-common`, `langchat-auth`, `langchat-aigc`, `langchat-core`, `langchat-datasource`, `langchat-monitor`, `langchat-server` and `langchat-ui`. Seven of those are Java and one is the frontend, which matches the badges on the README: Java 17, Spring Boot 3.3, Vue 3 and Apache-2.0.

One detail is worth noticing. The README describes the backend boundary as common, auth, aigc, core, datasource and server, six modules, and does not mention monitoring. The tree has `langchat-monitor/`. That is the kind of small gap between prose and directory listing you get in a project where the README is maintained as a product page rather than as a map of the code.

The frontend is not a thin skin over the API. The Dockerfile builds `@vben/web-naive` from `langchat-ui/`, which means the console is generated from an admin template project with Naive UI as the component library, and the pages cover overview, models, agents, knowledge bases, Skills, MCP, data sources, users and roles. RBAC with roles, menu entries and dynamic routes is part of the feature table rather than something to be bolted on later.

The README is also a page for the paid edition

The first substantial block of the README is not about the open source version. It describes LangChat Agentic, a commercial product for procurement, delivery and long term operation, and it lists what the paid version adds: long term memory with memory compression, isolated session workspaces and containerised sandbox execution, multi agent orchestration in Supervisor, sequential, parallel and loop patterns, hybrid retrieval with index version switching and fusion ranking, a controlled Text2SQL path, model governance, cost control and run auditing, plus private deployment and domestic technology stack adaptation.

That list is a fair description of what an enterprise buyer asks for, and it is also an admission of what the open version leaves out. The sandbox, the memory layer and the orchestrator patterns are precisely the pieces that make an agent platform hard to operate safely.

The overlap is not clean either. Smart data querying, the capability the README calls natural language data analysis, appears in the open version feature table, and then reappears in the commercial list as controlled Text2SQL with data source onboarding and explainable charts. A reader cannot tell from the README whether the open implementation is the same code path with fewer guardrails or a genuinely simpler generator.

The open version's own positioning sentence is honest about its intended use: technical validation, secondary development and internal team tooling. That is a smaller claim than the screenshots suggest, and it is the one to hold on to.

Model access, RAG, Skills and MCP in one runtime

The feature table is worth reading closely because the combinations are the point. Model access is unified across OpenAI, Azure OpenAI, Anthropic, Gemini, DeepSeek, Qwen, Zhipu, Ollama and any OpenAI compatible endpoint. Agents are configured from a model, a system prompt, a knowledge base, Skills and MCP servers, then built, debugged and run from the same screen.

The knowledge base side is the most concrete part of the table. It covers knowledge base management, document upload, parse preview, segmentation, indexing status and vector storage configuration, and the screenshot captions follow that exact pipeline: upload file, configure chunking, run vectorisation. Showing indexing state per document is the kind of detail that only appears in a tool whose authors have actually waited on an embedding job.

Skills and MCP are both first class. Skills can be uploaded as a package or a folder, browsed, downloaded, and registered as runtime tools. MCP service configuration is managed centrally, and the README says the agent runtime reuses the MCP client session. The conversation runtime adds SSE streaming and an OpenAI compatible Chat Completions interface, which means a client that already speaks that API can point at LangChat without learning a new protocol.

The topics list `langchain4j`, `java` and `spring-boot`, so the orchestration layer is LangChain4j inside Spring Boot. That is a library choice rather than a platform choice, and it is the honest frame for the whole project: LangChat is the application, the console and the permission model on top of an existing Java agent toolkit.

One image with Nginx in front and a bind-mounted database port

The `Dockerfile` is the most informative file in the repository, because its opening comment block explains the deployment shape before any instruction runs. The image bundles the built frontend and the Spring Boot jar into a single artefact supervised by Supervisor: Nginx exposes port 80 and serves the static assets while reverse proxying `/api` to the backend, and the backend keeps its embedded Tomcat bound to `127.0.0.1:8080` so it is not reachable from outside the container.

The build is two stages. The frontend stage starts from `node:22-alpine`, activates the pnpm version that matches the project's `packageManager` field, and builds `@vben/web-naive`. The comment explains why `--ignore-scripts` is passed: the root `prepare` script runs `lefthook install`, which is a local git hook tool and neither needed nor possible inside an image without a `.git` directory.

docker build -f Dockerfile -t langchat:latest .

The same comment block also documents a plain `docker run` with a read-only bind mount for `application-docker.yml`, and then recommends the compose file in the `docker/` directory instead, because it brings up MySQL, PGVector and RustFS alongside the application. PGVector matters for the knowledge base, and RustFS is the object store sitting behind document upload.

cd docker && docker compose up -d

Debugging tools are baked into the image on purpose: curl, vim, netcat, procps, the MySQL and PostgreSQL clients, and the Redis tools. A container that can reach its own databases is a container you can diagnose without leaving the shell.

No releases, and a default branch called next

GitHub shows no releases for this repository at all. There are no tags to pin, no changelog to read and no migration notes between versions, so the only handle on what you are running is the branch. The default branch is `next`, which is an unusual choice for a project whose README describes a product in the present tense, and it tells you that the branch people clone by default is not necessarily the stable one.

The `build-release.sh` script at the root suggests releases are produced by a local script rather than by an automated release workflow, and `langchat.sh` at the root looks like a convenience launcher. Both are worth opening before you deploy, since they are the parts of the tree that describe how a version is supposed to be produced.

The rest of the metadata is reassuring in small ways. The repository is not archived, the license is Apache-2.0 with both a `LICENSE` and a `NOTICE` file present, and the last push was on 2026-09-27. It has 1,288 stars and 254 forks. It also has zero open issues, which for a project this size most likely means issues are triaged or closed aggressively rather than that nobody files any, so treat the count as a signal about the workflow and not about the code.

Choosing between a platform and a framework

The useful comparison here is not against another agent product but against the two alternatives a Java team actually has. The first is a library: LangChain4j, Spring AI or the OpenAI Java SDK, wired into your own Spring Boot application. You get exactly the features you write and no console, no knowledge base UI and no permission model. The second is a hosted agent service, where none of the runtime is yours to inspect.

LangChat sits between them, and the trade is explicit. You give up a small amount of code level control, because prompts, tools and knowledge bases are configured through a web interface rather than files in your repository, and in exchange you get an operator facing product: RBAC, an application marketplace where agents are published and run from a single chat screen, streaming responses, and a knowledge base that shows you why a document is not yet searchable.

The features you would otherwise build first are the features in the table, which is the argument for adopting a platform at all. The features you cannot evaluate from the repository are the deployment and upgrade story, and that is where the missing release history bites. Before committing, read the module that owns your data path, check how `application-docker.yml` differs from a development configuration, and look at how the commercial edition's sandbox execution is described, because that is the line between a demo and something you would let colleagues point at a production database.

Editorial conclusion

LangChat is worth a look if you want an agent platform with an administration console rather than a library, because that is genuinely what this is: a modular monolith on Spring Boot with a Vue 3 front end, an OpenAI-compatible endpoint, and a knowledge base pipeline that shows its chunking and indexing state instead of hiding it. The honest limit is that the README spends more space on the paid Agentic edition than on the code you can read, and the open tree carries no version history at all, so there is no way to tell from the repository which features are finished. Start by reading the module list under `langchat-server/` and the single-image `Dockerfile`, then decide whether a Java admin console is the shape your team actually wants to own.

Frequently asked questions

Official sources

1. Issues
2. LangChat/langchat on GitHub
3. License: Apache-2.0
4. Project website
5. README