RuoYi AI: a Spring Boot and Langchain4j stack for multi-agent chat, RAG and visual workflows
An enterprise AI development framework for building AI agents. It provides unified management of multi-provider LLMs, secure enterprise knowledge bases with high-precision retrieval, visual workflow orchestration and multi-agent coordination. Compatible with mainstream Agent Skill standards, it enables developers to efficiently build production-gra
At a glance
- What is it?
- RuoYi AI bundles model routing, vector-backed knowledge bases, an MCP tool layer and a drag-and-drop workflow designer into one Java platform. It is a sensible fit if your team already runs Spring Boot and wants an admin panel around agents; the Docker Compose path is the part to inspect first.
- Who is it for?
- Adopt RuoYi AI if your team already operates Spring Boot services and wants an admin panel, model routing and a vector-backed knowledge base in one deployable unit, and you are willing to read docs/docker/ruoyi-ai/.env before anything else. Do not adopt it if you need a Python-native agent ecosystem, a hosted SaaS with no operational surface, or a framework small enough to read end to end.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem RuoYi AI addresses: agent plumbing scattered across five vendors
Most teams building an assistant do not start with an agent framework. They start with a chat box, then add a model key, then a second model key because the first one is rate limited, then a document upload, then a vector store, then a tool-calling loop, then an admin screen so someone other than the original developer can change the system prompt. RuoYi AI is aimed at that accumulated mess. The README describes it as an "Enterprise-Grade AI Assistant Platform" and lists the pieces it absorbs: multi-model integration, knowledge management with vector databases, MCP tool integration, a visual workflow designer, and a Langchain4j-based multi-agent layer with Supervisor mode orchestration. The target reader is a Java shop. The backend is Spring Boot 3.5.8 with Langchain4j, storage is MySQL 8.0 plus Redis plus one of Milvus, Weaviate or Qdrant, and the frontends are Vue 3 with Vben Admin. If your organisation already runs a RuoYi-style admin system, the vocabulary and the deployment shape will be familiar. If you are a Python team, you are the wrong audience, and the README does not pretend otherwise.
What actually runs: Spring Boot, Langchain4j, and a Supervisor that picks the decision model
The architecture section is short, so the mechanism has to be read from the module table. Model management is a routing layer: DeepSeek, Zhipu, MIMO, Bailian and OpenAI are named as integrations, alongside platform integrations for Coze, DIFY, FastGPT and RAGFlow. That means RuoYi AI can act either as the thing holding the model credentials or as a front end to an external orchestration platform you already pay for. Knowledge management is described as "Local RAG + Vector DB (Milvus/Weaviate/Qdrant) + Document parsing", with PDF, Word and Excel parsing and image analysis in the document processing line. Tool management covers the MCP protocol plus a Skills capability. The multi-agent module is "Agent framework based on Langchain4j, Supervisor mode orchestration, supports multiple decision models, can flexibly combine tools and skills". The word Supervisor is doing a lot of work there and the README does not explain the routing rule, so the decision model selection is something you will have to read out of the code. Workflow orchestration is a visual designer with drag-and-drop nodes and SSE streaming execution; the README names model calls, email sending and manual review as the node types currently supported. That node list is the most honest sentence in the repository: three node categories is a designer, not a general automation engine.
Getting it running: the Compose file, the .env pin, and the three ports
The documented path is Docker Compose, and the README marks one-click startup as recommended. Clone the v3.1.0 tag, copy the environment template, pin the image version, then pull and start. The commands are explicit. After `git clone --depth 1 --branch v3.1.0 https://github.com/ageerle/ruoyi-ai.git` and `cd ruoyi-ai`, you run `cp docs/docker/ruoyi-ai/.env.example docs/docker/ruoyi-ai/.env`, then `sed -i 's/^RUIYI_VERSION=.*/RUIYI_VERSION=v3.1.0/' docs/docker/ruoyi-ai/.env`. The compose invocation passes the env file explicitly twice, once for `pull` and once for `up -d`, using `-f docs/docker/ruoyi-ai/docker-compose-all.yaml`. Service status comes from the same command with `ps`. Images are published to GHCR and the README states that public GHCR images do not require `docker login`. Windows users get a PowerShell variant using `Copy-Item` and a `(Get-Content ...) -replace ... | Set-Content` pipeline to do the same version pin. Ports after startup: admin panel on 25666, user frontend on 25137, backend API on 26039, all with the default account admin / admin123. The README notes that the default Compose file is truncated in the excerpt, so the dependency services it declares (MySQL, Redis, and which vector database) are not confirmed here and need checking in the file itself.
The default credentials and the exposed ports are the first thing to fix
The README publishes admin / admin123 for both the admin panel and the user frontend, and the live demo at a public IP uses the same pair. That is convenient for evaluation and unacceptable for anything else. The Compose file binds three ports, and nothing in the supplied material describes an authentication layer in front of them beyond Sa-Token plus JWT inside the application. If you deploy this on a host with a public interface, the admin panel on 25666 is reachable before you have changed anything. The material does not document a first-run password change flow, a forced rotation, or an environment variable that overrides the seeded account, so treat credential replacement as a manual step you must plan for and verify. The same applies to model provider keys: the README does not show where they are stored or whether they are encrypted at rest, and given that the platform can hold credentials for DeepSeek, Zhipu, MIMO, Bailian and OpenAI simultaneously, that is a meaningful unknown.
Where the documentation thins out: Supervisor routing, vector DB selection, and node coverage
Three gaps stand out. First, Supervisor mode is named as the multi-agent orchestration approach but the routing rule, the fallback behaviour when a decision model fails, and the cost implications of running a supervisor on every turn are not described in the README. If you are evaluating this for a high-volume assistant, that silence matters more than the feature list. Second, the vector database story is a menu: Milvus, Weaviate and Qdrant are all listed, but the material never says which one the shipped Compose file provisions, whether switching requires a schema migration, or how the local RAG path relates to the external vector store. Third, the workflow designer supports model calls, email sending and manual review. Anything beyond that, such as branching on retrieved content or calling an arbitrary HTTP endpoint, is not listed. A visual designer with three node types is a useful demo and a constrained production tool, and you should test your actual workflow on paper against that list before committing. There is also a commercial edition behind a WeChat QR login at web.ruoyiai.chat, and the README does not define the boundary between the MIT-licensed repository and that edition. That boundary is a procurement question, not a licensing one.
Choosing between RuoYi AI and a Python-native agent framework
The obvious alternative for this class of work is a Python agent framework such as LangChain or LangGraph, where you assemble the retrieval chain, the tool registry and the orchestration graph yourself. The difference in approach is not language preference, it is where the integration work sits. A Python framework gives you a library: you own the API surface, the persistence, the admin UI and the deployment. RuoYi AI gives you an application: the admin panel, the user frontend, the model credential store and the vector database wiring are already there, and you extend it through its module boundaries rather than composing your own. The trade is control against time. If your retrieval logic is unusual, or you need to instrument every model call with your own tracing, a library is easier to bend. If you need a working assistant with a management console that a non-developer can operate, and your team writes Java, assembling that on top of LangChain means rebuilding a substantial part of what this repository already ships. A second alternative worth naming is routing through DIFY, FastGPT or RAGFlow directly, since RuoYi AI lists integrations for all three. That path removes the Java layer entirely and leaves you with a platform you do not operate, at the cost of the customisation the Spring Boot backend provides.
Maintenance cost: a multi-repository project with a version pin you must manage
RuoYi AI is not one repository. The README lists six: the backend, ruoyi-web for the user frontend, ruoyi-admin for the admin panel, ruoyi-drama, ruoyi-copilot and ruoyi-uniapp, each mirrored across GitHub, Gitee and GitCode. If you deploy only the backend and the two frontends through the Compose file, you still inherit the release cadence of the backend plus whichever frontend images the compose file references. The version pin in docs/docker/ruoyi-ai/.env is the single lever: RUIYI_VERSION=v3.1.0 in the documented example. Upgrading means changing that value and re-pulling, and the README does not describe a migration path between v3.0.0 and v3.1.0, nor what happens to existing vector data when the schema changes. That is the operational risk to price in. On licensing, the repository is MIT, which permits commercial use and modification, but the README does not state which parts of the platform the MIT grant covers relative to the commercial edition at web.ruoyiai.chat, and it does not list third-party licence obligations for the bundled components. Confirm both with your own legal review rather than treating the MIT badge as covering the whole product surface.
Editorial conclusion
Adopt RuoYi AI if your team already operates Spring Boot services and wants an admin panel, model routing and a vector-backed knowledge base in one deployable unit, and you are willing to read docs/docker/ruoyi-ai/.env before anything else. Do not adopt it if you need a Python-native agent ecosystem, a hosted SaaS with no operational surface, or a framework small enough to read end to end. Verify first that the pinned RUIYI_VERSION image exists in GHCR, that your chosen vector database is actually exercised by the compose file you plan to run, and that the default admin/admin123 credentials are removed before the ports 25666 and 25137 are reachable from anywhere.
Community notes