RAG Web UI: A Self-Hosted Knowledge Base Q&A Stack in TypeScript and Python
RAG Web UI is an intelligent dialogue system based on RAG (Retrieval-Augmented Generation) technology.
At a glance
- What is it?
- RAG Web UI pairs a TypeScript frontend with a Python backend to ingest documents, embed them, and answer questions against them. It is a reasonable fit if you want a browser interface and an OpenAPI surface over your own vector store, and a poor fit if you need a retrieval pipeline you can tune in depth.
- Who is it for?
- Adopt RAG Web UI if you want a working browser UI and OpenAPI surface over your own documents without assembling the frontend, job queue and vector-store adapter yourself. Skip it if your retrieval quality depends on custom chunking, custom reranking or fine-grained control of the embedding pipeline, because those stages are not where this project's configuration surface lives.
- Can I use it commercially?
- Yes. Apache-2.0 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 162 days ago.
- What is it written in?
- Mainly TypeScript, 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 gap RAG Web UI fills between a vector database and a usable interface
Most teams that want retrieval-augmented generation over internal documents can get a vector database running in an afternoon. What takes longer is everything around it: a place to upload files, a way to see whether ingestion succeeded, a chat surface that shows which passages an answer came from, and an HTTP endpoint so a script or another service can query the same index. RAG Web UI targets exactly that middle layer. The README describes it as a system that helps build intelligent Q&A systems based on your own knowledge base, combining document retrieval with large language models. The intended user is a team with documents and a model endpoint but no appetite for building the surrounding application. The project ships under Apache-2.0, and the repository lists TypeScript as the primary language, with Python 3.9+ and Node 18 or later shown as requirements in the README badges, so both runtimes are part of the deployment.
Document ingestion runs as a job, not as a request
The flowchart in the README separates the system into an ingestion path and a query path. On ingestion, a caller uploads a file (PDF, Markdown, TXT or DOCX), the system returns a job ID, and processing continues asynchronously. That asynchronous branch performs preprocessing (text extraction and cleaning), then text splitting with segmentation and overlap, then sends the chunks to an embedding API backed by an embedding server, and finally writes vectors into the vector database. Files themselves are stored in NFS according to the diagram, which is the detail that tells you the intended deployment is not a single laptop process: the document store and the processing workers are treated as separable. The caller polls a job status endpoint that reports processing, completed or failed. This is a sensible shape for large PDFs, and it also means the upload response tells you nothing about whether the document is queryable. Any integration has to handle the polling loop or the failure state. The README does not describe retry behaviour for failed jobs, so treat partial-failure handling as something to inspect in the code before you depend on it.
The query path adds a re-ranking stage that the feature list does not mention
The query flow in the diagram is more specific than the marketing copy. A user query is formed with reference to user history, embedded, and used for vector retrieval. The retrieved candidates then pass through a re-ranking step labelled cross-encoder, after which context is assembled and handed to the LLM for generation. The diagram also draws a dashed connection from the original query directly to the re-ranker, which suggests the raw query text is available to the reranking stage alongside the retrieved passages. That is a real design decision: cross-encoder reranking is slower than pure vector similarity but generally improves the order of the top passages, and it is the kind of stage that teams often have to bolt on themselves. Note the asymmetry, though. The features section advertises ChromaDB and Qdrant with switching through a factory pattern, and multi-turn dialogue with reference citations, but it does not name a configuration key for the reranker. The architecture diagram is the only place the cross-encoder appears in the supplied material.
Model and storage backends are pluggable, and that is the main configuration surface
The README states that the system supports cloud LLM services including OpenAI, DeepSeek and MiniMax, plus local deployment through Ollama, and that vector storage supports ChromaDB and Qdrant with switching handled by a factory pattern. The factory pattern matters more than the list. It means the vector store is chosen at the code level rather than by pointing one client at a different URL, so moving from ChromaDB to Qdrant is a configuration and code path decision rather than a data migration you can perform transparently. The v0.8.0 release, dated 2026-04-06, is titled HuggingFace Embeddings Support, which extends the embedding side of the pipeline beyond whatever was previously available. The repository topics list ai, deepseek, langchain, ollama and rag, so LangChain is part of the implementation stack. If you already run Ollama locally, the combination of a local model and a local vector store is the configuration that keeps document content on your own hardware, which is the scenario the README frames as meeting privacy and cost requirements.
Getting it running: Docker first, and the host networking detail that bites
The README's quick start and deployment sections point at Docker, and the v0.7.3 release note is explicitly about updating Docker configurations for host.docker.internal along with documentation. That release title is the practical warning: if your LLM or embedding endpoint runs on the host machine rather than in a container, the container needs a route back to it, and host.docker.internal is the mechanism the project settled on. Expect to set that hostname in your model or embedding base URL rather than localhost, which inside a container refers to the container itself. The README badges give the runtime floors as Python 3.9+ and Node 18 or later, so a from-source development setup needs both toolchains. The repository also exposes OpenAPI interfaces, described as a way to access the knowledge base by API, and the screenshots include an API key management screen and an API reference screen, which implies keys are issued per consumer rather than a single shared secret. The supplied material does not include the actual environment variable names or the compose file contents, so read the deployment guide in the repository for the exact keys before writing your own configuration.
Where this design will frustrate you
The chunking strategy is described as segmentation with overlap and nothing more. If your documents are tables, code, or contracts where section boundaries carry meaning, the default splitter is unlikely to respect them, and the README does not indicate a configuration surface for custom splitters. The re-ranking stage appears in the architecture diagram but not in the feature list or the release notes, so its configurability is unverified from the supplied material. The asynchronous ingestion model means your application must implement polling and handle the failed state; there is no documented webhook or callback for job completion. Storage is drawn as NFS, which is a heavier dependency than a local volume if you are deploying for a single user. And the vector store choice is mediated by a factory, so the abstraction that makes switching easy also means you are not talking to ChromaDB or Qdrant directly when you need an index setting the abstraction does not expose. None of these are defects; they are the boundaries of what the project is trying to be.
How it compares to assembling LangChain and a vector store yourself
The obvious alternative is to build the same thing from LangChain plus ChromaDB or Qdrant directly, which is the stack RAG Web UI is built on according to its topic list. The difference is where the work sits. Assembling it yourself gives you direct control over the splitter, the retriever parameters and the reranker, and no UI to maintain. RAG Web UI gives you the UI, the job tracking, the API key management and the OpenAPI surface already written, in exchange for accepting its opinions about chunking and its factory-mediated access to the vector store. A second alternative is a managed retrieval service, where you upload documents and get a hosted query endpoint. That removes the NFS and database operations entirely but reintroduces the data-residency question the README's Ollama support is designed to avoid. The choice is really about whether your differentiator is the retrieval pipeline or the application around it. If it is the pipeline, this project's abstraction will be in your way.
Maintenance, licence and what to check before you deploy
The release history shows a steady cadence rather than a burst: v0.7.3 in August 2025, 0.7.5 in November 2025 with a fix replacing passlib with a direct bcrypt implementation, and v0.8.0 in April 2026 adding HuggingFace embeddings. The bcrypt change is worth noting because it is an authentication-path change in a patch release, which is the kind of thing that can invalidate existing password hashes; test login after upgrading across that boundary. Because the project is a multi-service application (frontend, backend, vector store, NFS), upgrades are not a single binary swap, and the Docker configuration change in v0.7.3 shows that environment assumptions can shift between releases. Apache-2.0 permits commercial use and modification and includes a patent grant, with the usual requirements around preserving notices and stating changes; it is not a copyleft licence, so it does not oblige you to publish your modifications. That is a summary of the licence text, not legal advice, and if you are redistributing the software inside a product you should read the LICENSE file in the repository yourself.
Editorial conclusion
Adopt RAG Web UI if you want a working browser UI and OpenAPI surface over your own documents without assembling the frontend, job queue and vector-store adapter yourself. Skip it if your retrieval quality depends on custom chunking, custom reranking or fine-grained control of the embedding pipeline, because those stages are not where this project's configuration surface lives. Before committing, verify three things in your own environment: which vector store you will run (ChromaDB or Qdrant) and whether switching later is acceptable, whether your chosen embedding provider is reachable from inside the container given the host.docker.internal configuration noted in v0.7.3, and what the document ingestion job does when a file fails partway through.
Community notes