LightningRAG: a Vue + Gin starter that ships RAG and an agent canvas
LightningRAG is a full-stack Vue + Gin starter with a decoupled frontend and backend, plus built-in, extensible RAG (retrieval-augmented generation): knowledge bases, vector search, and integrations with many LLM and vector-store providers
At a glance
- What is it?
- LightningRAG bundles knowledge bases, pluggable model and vector-store providers, a canvas agent editor and channel webhooks into a Go backend with a Vue admin. The RAG layer is the reason to look at it; the admin scaffold is the reason to hesitate.
- Who is it for?
- Adopt LightningRAG if you want a Gin server where retrieval, provider configuration and an admin UI already exist and you are willing to read server/rag/README.md before trusting the README summary. Do not adopt it if you need a stable API surface: the version numbers are still in the 0.0.x range and the demo link is disabled in the README.
- 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 152 days ago.
- What is it written in?
- Mainly Go, 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 LightningRAG tries to fill between a RAG library and a product
Most retrieval-augmented generation code arrives in one of two shapes. A Python library gives you chunking, embedding and a retriever interface, and leaves you to build the document table, the upload endpoint, the permission model and the chat UI. A hosted product gives you all of that but takes the vector store and the model choice out of your hands. LightningRAG is aimed at the space in between: a Go backend built on Gin, a Vue frontend, and a RAG layer that the README describes as covering ingest, parse, chunk and vector retrieval, with pluggable LLMs, embeddings, vector stores and rerankers.
The intended user is a team that has already decided to run its own stack and wants a starting point rather than a blank repository. The README frames the project as a full-stack starter with JWT, dynamic routes and menus, Casbin, a form builder and a code generator, so the audience is developers who expect an admin console to come with the retrieval code. If you only need a retriever function to call from an existing service, the surrounding surface here is larger than the problem you have.
How a document becomes an answer: the pipeline the README describes
The flow has four visible stages. Documents are uploaded into a knowledge base, parsed to plain text, chunked, embedded and written to a vector store. Chunk metadata stays in the application database, in tables the README names as rag_knowledge_bases, rag_documents and rag_chunks, while the vectors themselves go to whatever VectorStore is configured, with PostgreSQL plus pgvector and Elasticsearch dense_vector given as examples. That split matters: the relational side holds the document and chunk records, so deleting or re-indexing a document is an application-database operation, not a vector-store one.
Retrieval sits behind a Retriever interface under server/rag/ with several implementations. The README lists vector, PageIndex and keyword retrievers, and describes hybrid or multi-path retrieval that combines them. Conversation goes through /rag/conversation/chat and chatStream, the latter using SSE, where the final frame may carry the retrieval mode, the queries that were run and a references field. A separate endpoint, queryData, returns structured retrieval results only, with no LLM call and no message persistence, which is useful when you want to inspect what retrieval would return before paying for a generation. Note the README's warning that Casbin has to allow /rag/conversation/queryData, since the permission layer sits in front of it.
Agent orchestration is a second path through the same retrieval machinery. A canvas editor exposes nodes such as Begin, Retrieval, LLM, Message and Agent, with the Agent node carrying tools. The README contrasts this with a single fixed knowledge-base chat, and points to docs/AGENT_IMPLEMENTATION_PLAN.md and docs/AGENT_COMPONENTS_DEVELOPMENT_PLAN.md for the plans. Tools are registered through an extensible registry documented in server/rag/tools/README.md.
Request fields and the rag: block in config.yaml
Per-request tuning lives in the chat body. The README points at server/model/rag/request/conversation.go and names fields including queryMode, chunkTopK, topK, enableRerank, hlKeywords, llKeywords, history, maxRagContextTokens, cosineThreshold, minRerankScore and includeReferences. Reranking is off unless you set enableRerank, and it only does anything when a rerank provider has been configured, so the flag alone is not enough.
Global defaults live under a rag: key in config.yaml. The README lists default-conversation-chunk-top-k, default-knowledge-base-retrieve-top-n, max-retrieve-top-n and max-retrieve-candidate-top-k, plus hybrid fusion weights, score floors, default-cosine-threshold and a set of knowledge-graph keys prefixed kg-. One detail worth internalising before you tune anything: a value of 0 usually means use the built-in defaults, not zero. Setting max-retrieve-top-n to 0 will not cap retrieval at nothing. The README also notes that configuration can be edited from the frontend, which it says may be disabled on a public demo instance. If your deployment exposes that page, treat it as a write path into your retrieval behaviour.
Provider configuration is stored in database tables rather than only in the file. The README names rag_llm_providers, rag_embedding_providers and rag_vector_store_configs, with an admin UI where exposed, and rag_user_llms for end users adding their own keys.
Getting it running and the pieces you must supply yourself
The README does not include an install command block, so the exact startup sequence is not something I can state from this material. What the repository layout tells you is that the backend lives under server/ and the frontend under web/, with the RAG documentation under server/rag/README.md and the config file at config.yaml. Those are the three files to read first.
Two setup items are explicit. File upload and download are implemented against Qiniu, Aliyun and Tencent Cloud object storage, and the README says you must develop your own application on each platform to obtain the corresponding token or key. There is no bundled local storage path described. Second, multi-login restriction is opt-in: set use-multipoint to true under system in config.yaml, and the README says Redis must be configured accordingly, adding a slightly hedged note to report bugs if any. That phrasing suggests the feature has seen less use than the rest.
Channel connectors are optional and only relevant if you publish an agent. The README lists Feishu, DingTalk, WeChat, WeCom, Discord, Slack, Telegram, Teams, WhatsApp and LINE, bound to published agents through public webhook URLs, authenticated with X-Webhook-Secret or vendor signatures, with per-channel extra JSON configured in the admin UI. The section covering the rag: operations keys for this is truncated in the README, so the tuning surface for webhooks is something you will have to read from the source or docs/THIRD_PARTY_CHANNEL_CONNECTORS.md.
Where LightningRAG is the wrong choice
The version numbers are the first honest signal. The recent releases are v0.0.7, v0.0.5 and v0.0.3, all dated within about a week of each other in April 2026. Three 0.0.x releases in eight days is a project moving quickly at an early stage, and the README's own demo section reflects that: the online demo link, username and password are struck through with a note that public preview is not deployed yet and the strikethrough should be removed when the server is ready. Anyone evaluating this cannot click through a running instance.
That has practical consequences. The request struct in server/model/rag/request/conversation.go is the contract for chat tuning, and at 0.0.x it can change between releases without a deprecation cycle. If you build a client against queryMode or cosineThreshold, pin the commit you deploy.
The second limitation is scope. This is a starter with an admin console, not a retrieval library. Adopting it means adopting JWT, Casbin, dynamic menus, role and API management and a form builder alongside the RAG code. A team that already has an admin system will spend more time removing the scaffold than using it. The third is that the README is thinner than its feature list in places: the multi-login note carries its own caveat, the channel-webhook tuning section is cut off, and several behaviours are delegated to linked documents rather than described inline. That is not a defect in the code, but it is a real cost in evaluation time.
How it differs from Dify and RAGFlow
The repository topics list dify and ragflow, and the README references a document named DOCUMENT_PARSE_RAGFLOW_ALIGNMENT.md, so the comparison is one the project invites. Dify and RAGFlow are applications you deploy and operate: you run their containers, use their UI, and extend them through plugins or their own configuration surfaces. LightningRAG is a codebase you fork. The retrieval layer is Go source under server/rag/ with a Retriever interface you can implement, and the admin UI is Vue source under web/ that you can edit. That is the actual difference in approach: extensibility by editing versus extensibility by configuration.
The trade-off runs both ways. Editing Go source gives you control over the retrieval path and lets you add a retriever kind or a tool without waiting for an upstream plugin API. It also means you own upgrades, merge conflicts and the security of the admin console. A deployed application gives you a supported upgrade path and a community running the same binary, at the cost of working within its abstractions. If your team is comfortable in Go and Vue and wants to own the retrieval code, the source-first model is the point. If you want a RAG system running this week without reading Go, this is not the shorter route.
Licence, maintenance and what to verify before you commit
LightningRAG is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant, which matters if you plan to ship a modified version. It also means you must preserve the licence and notice files and state significant changes. This is a description of the licence text, not legal advice; if you are embedding the project in a product with its own licensing constraints, have counsel read the NOTICE and any third-party dependency licences, since the provider integrations pull in vendor SDKs.
Maintenance cost is dominated by two things. First, the provider matrix: LLM, embedding, rerank, speech, TTS, OCR and CV providers are pluggable, and each one you enable is a dependency with its own SDK and API changes. Second, the admin surface, which includes a code generator and a form builder built on @Variant Form; generated CRUD code is yours to maintain once it is written. The README's own note about the demo server not being deployed yet is the clearest statement about the project's current stage, and it should shape your expectations about how much of the operational surface has been exercised publicly.
The concrete first step is to open config.yaml, locate the rag: block, and read the defaults for default-cosine-threshold, max-retrieve-top-n and max-retrieve-candidate-top-k in the exact commit you intend to deploy, remembering that 0 means use built-in defaults rather than zero. Then read server/rag/README.md, which the top-level README repeatedly names as the authoritative source over its own summary.
Editorial conclusion
Adopt LightningRAG if you want a Gin server where retrieval, provider configuration and an admin UI already exist and you are willing to read server/rag/README.md before trusting the README summary. Do not adopt it if you need a stable API surface: the version numbers are still in the 0.0.x range and the demo link is disabled in the README. Before writing code, open config.yaml, find the rag: block, and check what default-cosine-threshold and the max-retrieve-* keys are set to in the branch you plan to deploy.
Community notes