ruoyi-web: the Vue 3 chat front end that only makes sense with the RuoYi-AI backend
RuoYi-AI user frontend for AI conversations, agent interactions, and knowledge-base Q&A.
At a glance
- What is it?
- ageerle/ruoyi-web is the user-facing Vue 3 client for the RuoYi-AI platform, covering AI conversations, agent interactions and knowledge-base Q&A. It is MIT-licensed and deployable via Docker, but its value depends entirely on whether you are already running the RuoYi-AI backend.
- Who is it for?
- Adopt ruoyi-web if you are already committed to the RuoYi-AI backend and want its user-facing chat, agent and knowledge-base surfaces without building them yourself; skip it if you need a backend-agnostic chat UI, since the README documents no adapter layer for other APIs.
- 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 Vue, 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-web solves is narrow and deliberate
RuoYi-AI is a self-hosted AI assistant platform, and it is split across three repositories: the backend service (ageerle/ruoyi-ai), an admin panel (ageerle/ruoyi-admin), and this user front end. The README describes ruoyi-web as the surface for "AI conversations, agent interactions, and knowledge-base Q&A." That phrasing matters. This is not a general-purpose chat widget you drop into an existing product, and it is not a model playground. It is the end-user half of a specific stack, paired with a backend that owns the conversation state, the agent definitions, and the retrieval layer.
The audience follows from that. If you are standing up RuoYi-AI for an organisation and you need a chat interface that ordinary users can open in a browser, this repository is the piece you deploy. If you are looking for a standalone client that can point at OpenAI, Anthropic, or a local Ollama instance, nothing in the supplied material suggests ruoyi-web is built for that. The README names one upstream integration and one configuration variable for it, UPSTREAM_URL, and that is the whole story of how the front end finds a model.
The stack is conventional for a 2026 Vue project: Vue 3 with TypeScript, Ant Design Vue for components, Pinia for state, Vite for the build. There is no bespoke framework here to learn, which keeps the maintenance surface small but also means the project offers little that is architecturally novel. Its reason to exist is integration, not invention.
How the front end reaches the model: one upstream, no adapters
The architecture visible in the README is a thin client in front of the RuoYi-AI backend service. The front end renders conversations, agent interactions and knowledge-base queries; the backend service, listening on port 6039 by default, handles the actual model calls, agent orchestration and retrieval against the vector store. The front end's only documented link to that backend is the UPSTREAM_URL environment variable, which the FAQ identifies as the thing to check when the front end "cannot connect to the backend service."
That single variable is the entire integration contract as far as the public documentation goes. There is no mention of a plugin system, a provider registry, or a request transformer. In practice this means the front end does not know or care which model answers a question; swapping models is a backend concern. It also means the front end has no fallback path. If the backend is down or UPSTREAM_URL points at the wrong host, the user interface has nothing to talk to, and the failure is opaque from the browser side.
The rest of the deployment topology is spelled out in the ports table, and it is worth reading as a description of the system rather than a list of numbers. MySQL on 23306 and Redis on 6379 hold relational data and cache. Weaviate on 28080 is the vector database, which is where the knowledge-base Q&A feature gets its retrieval. MinIO on 9000 and 9090 provides object storage, presumably for uploaded documents that feed that knowledge base. None of those services belong to ruoyi-web, but the front end's knowledge-base feature is only as functional as the backend's connection to Weaviate and MinIO. A front-end-only deployment is therefore not a meaningful configuration.
Getting it running: two Docker paths and a local dev server
The README gives two Docker routes. The recommended one starts the whole platform from the backend repository using a compose file named docker-compose-all.yaml, which pulls pre-built images for the backend, admin panel, user front end and dependencies:
git clone https://github.com/ageerle/ruoyi-ai.git cd ruoyi-ai docker-compose -f docker-compose-all.yaml up -d
The README states the user front end then appears at http://localhost:25137 with the credentials admin / admin123. Note that this port differs from the 5137 listed in the ports table for the user front end, so the all-in-one compose file remaps it. That is a genuine source of confusion when you move between the two deployment methods, and the documentation does not explain the discrepancy.
The second route builds each service from source. You start the backend first with docker-compose up -d --build and follow its logs with docker-compose logs -f backend. Then, from the ruoyi-web directory, you run docker-compose up -d --build and open http://localhost:5137. The admin panel is optional and lands on 5666. The README frames the choice plainly: pre-built images are faster, source builds are for when "custom changes are required."
For local work outside Docker, the project uses pnpm. The README lists pnpm install, pnpm dev for the development server, and pnpm build for a production bundle. Nothing in the supplied material documents the Node version, the package manager version, or any .env file beyond the UPSTREAM_URL variable, so treat those as things to confirm from the repository itself before you commit to a build pipeline.
Where it breaks: the UPSTREAM_URL failure mode and the front-end-only trap
The most explicit limitation in the README is also the most common one. The first FAQ entry asks what to do when the user front end cannot connect to the backend, and the answer is to confirm the backend is running and that UPSTREAM_URL is set correctly. That is a two-point checklist, which tells you the project treats connectivity as a configuration problem rather than something the client can recover from. There is no documented retry strategy, no offline mode, and no diagnostic page. When the upstream is wrong, the symptom is a front end that does not work, and the fix is on the environment, not in the code.
The second limitation is structural. Because the front end is coupled to the RuoYi-AI backend through a single upstream URL, it is the wrong tool for anyone who wants a chat UI over an API the project was not built for. If your organisation already has a model gateway with its own authentication scheme and streaming format, ruoyi-web does not offer a documented way to adapt to it. You would be adopting the backend as well, and with it MySQL, Redis, Weaviate and MinIO. That is a substantial operational footprint for what a user sees as a chat box.
A third point is simply that the supplied material is thin on internals. The README covers deployment and a two-item FAQ. It does not describe the component structure, the Pinia store shape, how streaming responses are handled, or how knowledge-base documents are uploaded and chunked. The repository layout would answer some of that, but none of it is in the material available here, so any claim about the front end's internal design would be speculation.
How it differs from a self-contained chat UI like Open WebUI
The natural comparison is a self-contained chat interface such as Open WebUI, which bundles its own backend and talks directly to model providers. The difference in approach is where the intelligence lives. Open WebUI owns the request path: it authenticates against a provider, manages conversations, and can point at a local runtime without a separate application server. ruoyi-web owns only the rendering layer. Everything behind UPSTREAM_URL, including model selection, agent behaviour and retrieval, belongs to the RuoYi-AI backend service.
That split has consequences in both directions. On the plus side, it means the front end stays small and the heavy dependencies (Weaviate, MinIO, MySQL, Redis) are the backend's problem, not the client's. If your organisation needs a knowledge base with vector search and document storage under its own control, the RuoYi-AI arrangement gives you a place to put that. On the minus side, it means ruoyi-web cannot be adopted incrementally. You either run the whole platform or you run none of it.
A second, quieter difference is the presence of an admin panel. RuoYi-AI separates user-facing surfaces from administrative ones across two repositories, with the admin panel on port 5666. A single-binary chat UI typically folds administration into the same application. Whether the split is an advantage depends on who operates the system: it is cleaner for organisations that separate end users from administrators, and more moving parts for a single developer running everything on one machine.
Maintenance cost, release cadence and the MIT licence
The release history in the supplied material shows v3.0.0 in April 2026 and v3.1.0 in August 2026, with the last push to the default branch in September 2026. Two tagged releases in roughly five months is a moderate cadence, and the version jumps are major-version increments, which suggests the project is willing to make breaking changes between releases. If you pin to a tag, plan for the possibility that upgrading to the next one requires configuration or code changes. The README does not include a migration guide, so the release notes are the place to look before you move.
Operationally, the cost of running ruoyi-web is not the front end itself. It is the platform around it: the backend service, MySQL, Redis, Weaviate and MinIO, as enumerated in the ports table. Any upgrade to the front end should be checked against the backend version it expects, because the two live in separate repositories and the README does not state a compatibility matrix. That is an unquantified risk you carry.
The licence is MIT, stated in the README and pointing to a license file in the repository. MIT is permissive: it allows commercial use, modification and redistribution, and it requires that the copyright notice and permission notice be preserved. It does not grant trademark rights, and it offers no patent grant. This is a description of the licence text, not legal advice; if your organisation has specific compliance requirements, have counsel review the actual license file rather than the README's summary.
Who should deploy this, and what to check before you do
The decision reduces to a single question: are you running the RuoYi-AI backend service? If yes, ruoyi-web is the intended user-facing client, it is MIT-licensed, and the Docker path gets you to a working interface with one compose command and a documented set of default credentials. If no, this repository gives you a Vue 3 application with no model to talk to, and the effort of adapting it to a different backend is undocumented.
Before deploying, verify three things against your actual environment. First, that the backend service is reachable at the host and port you place in UPSTREAM_URL, since the FAQ treats that as the primary cause of connection failures. Second, which port you will actually see the front end on: 5137 in the separate deployment, 25137 in the all-in-one compose file, and the README does not reconcile the two. Third, whether the dependency services (MySQL on 23306, Redis on 6379, Weaviate on 28080, MinIO on 9000 and 9090) are running and reachable from the backend, because the knowledge-base feature depends on Weaviate and MinIO and the front end will surface their absence as a broken experience rather than a clear error.
The project is actively maintained and not archived, so the practical risk is not abandonment. It is version skew between three repositories that are released separately and whose compatibility the documentation does not state.
Editorial conclusion
Adopt ruoyi-web if you are already committed to the RuoYi-AI backend and want its user-facing chat, agent and knowledge-base surfaces without building them yourself; skip it if you need a backend-agnostic chat UI, since the README documents no adapter layer for other APIs. Before deploying, verify that the backend is reachable at the URL you set in UPSTREAM_URL and that the port mapping matches the table (5137 for the front end, 6039 for the API), because a mismatch there is the failure mode the FAQ calls out first.
Community notes