jonfairbanks/local-rag: Offline RAG with Ollama, GPL-3.0, and a Thin README
Ingest files for retrieval augmented generation (RAG) with open-source Large Language Models (LLMs), all without 3rd parties or sensitive data leaving your network.
At a glance
- What is it?
- Local RAG ingests local files, GitHub repositories and websites into a LlamaIndex pipeline, then answers questions with Ollama chat models and Ollama or local Hugging Face embeddings. The premise is sound and the licence is copyleft, but the repository's own README is a link index rather than a setup guide, so most operational detail lives in docs/ that this review could not open.
- Who is it for?
- Adopt Local RAG if your documents cannot leave your network and you already run Ollama, and treat the ingestion guardrails as the feature worth evaluating first. Do not adopt it if you need a supported, versioned API, a documented configuration schema, or permissive licensing for redistribution.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, 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 Local RAG targets: retrieval where the documents cannot leave the network
Most RAG tooling assumes a hosted embedding endpoint and a hosted chat model. Local RAG takes the opposite position. The README describes it as "Offline, open-source retrieval augmented generation" and states that chat, embeddings and indexed source content stay "on your machine or network". That single constraint drives the rest of the design: models run through Ollama, and the embedding step can use Ollama or a local Hugging Face model instead of a remote API.
The intended user is not a team building a product on top of a retrieval API. It is someone with a corpus that cannot be uploaded, such as internal documents, and a machine or LAN host capable of running a model. The repository topics list large-language-models, llm, ollama, rag and retrieval-augmented-generation, which matches that reading. If your corpus is public and you are optimising for answer quality per dollar, the offline constraint costs you more than it buys.
What the ingestion layer actually accepts, and why that list is the interesting part
The README names three ingestion sources: local files, GitHub repositories and websites. Those are different shapes of input. A directory of files is a filesystem walk. A GitHub repository is a remote fetch that has to decide what counts as a document and what is code noise. A website is a crawl with the same question plus a politeness problem. The README also lists "Upload, URL, repository, and ingestion guardrails" as a feature, which suggests the project has thought about bounding what gets pulled in.
That guardrail claim is the most load-bearing line in the README and the least explained. There is no description of file size caps, extension filters, crawl depth, or per-source limits. docs/usage.md and docs/troubleshooting.md are linked but not included in the material available here, so the concrete rules cannot be confirmed. Treat the guardrails as a claim to verify rather than a specification. If you plan to point this at a large repository or an external site, that is the first thing to test.
How the pipeline is assembled: LlamaIndex for orchestration, Ollama for models
The README states that streaming RAG responses go "through LlamaIndex". That places LlamaIndex as the orchestration layer: it owns the index structure, the retrieval step and the streaming response path, while Ollama serves the chat model and optionally the embedding model. The alternative embedding path is a local Hugging Face model, which means the embedding stage does not have to depend on Ollama at all.
This split matters when you debug. A wrong answer can come from three places: the ingestion step stored the wrong text, the embedding model placed it badly in vector space, or the chat model ignored the retrieved context. Because LlamaIndex sits in the middle, its abstractions are what you inspect. docs/pipeline.md is the linked reference for this, and without it the exact node structure, chunking parameters and retrieval settings are unknown. The README does not state chunk sizes, overlap, top-k, or whether a reranker is used.
Settings live in the browser, which changes how you operate it
One feature listed in the README is "Browser-local settings persistence". This is a deployment decision with real consequences. Configuration is not described as a server-side config file that you commit and review. It persists in the browser. That is convenient for a single user on a single machine and awkward for anything else: a second browser profile starts from defaults, and there is no obvious artifact to diff when a setting changes.
Chat history export is listed alongside it, which suggests the intended workflow is one person, one browser, with the option to take the transcript out. If you were hoping to run this as a shared internal service with centrally managed model and ingestion settings, the README does not describe how that would work. The setup document may cover it. The README does not.
Getting it running: what the README does and does not tell you
The README gives no install command, no environment variable, no port and no model name. What it gives is a set of links: docs/setup.md for setup and deployment, docs/usage.md for operation, docs/pipeline.md for the RAG pipeline, docs/troubleshooting.md for failures, and docs/todo.md for planned features and known bugs. A SECURITY.md and a CHANGELOG.md sit at the repository root.
The only concrete instruction the README supports is the order of operations: read docs/setup.md before anything else. Beyond that, the material here does not contain a single copy-pasteable command. I will not invent one. If you are evaluating this project, the honest first step is to open docs/setup.md and check whether the deployment model it describes matches your environment, because the README alone will not get you to a running instance.
The maintenance signal: a two-year gap, then v2.0.0
The release history is the clearest evidence about the project's rhythm. v1.4.1 was tagged 2024-05-04 as a security update, v1.4.3 followed on 2024-07-05, and then v2.0.0 arrived on 2026-05-18. That is roughly a twenty-two month gap between the last 1.x release and the major version. The last push to the repository is dated 2026-09-07, so work continued after the 2.0.0 tag.
A major version after a long quiet period usually means breaking changes, and the README does not describe what changed. The CHANGELOG.md is linked but not included here, so the migration path from 1.4.3 to 2.0.0 cannot be summarised. Anyone running a 1.x deployment should read the changelog before upgrading rather than assuming a drop-in replacement. The OpenSSF Best Practices badge in the README indicates the project has gone through that programme's criteria, which is a process signal, not a statement about code quality.
Licence and the cost of living with GPL-3.0
Local RAG is GPL-3.0. For an internal tool that never leaves your network, that is largely a non-issue: you run it, you modify it if you want, and you do not distribute it. The obligation attaches when you distribute the software or a derivative. If you were considering embedding this into a product you ship, or offering it as a hosted service in a way that triggers copyleft obligations, the licence is the first thing to examine, and it is a question for your own legal review rather than for this article.
The practical cost is different from the legal one. A GPL-3.0 Python application that depends on Ollama, LlamaIndex and optionally Hugging Face inherits the upgrade treadmill of all three. Ollama model tags change, LlamaIndex has a history of API churn, and the 1.x to 2.0.0 jump here shows this project is not insulated from that. Budget for re-testing your ingestion sources after any dependency bump, because the guardrails and the pipeline are the parts most likely to shift underneath you.
The alternative to weigh: a hosted RAG service, and where the trade actually lands
The obvious alternative is a hosted retrieval service that handles ingestion, embedding and retrieval for you, with a documented HTTP API and no local model to run. The difference is not quality, it is where the boundary sits. A hosted service removes the Ollama dependency and the hardware requirement, and gives you a stable interface you can call from anything. Local RAG removes the data-egress question entirely and gives you a browser UI instead of an API.
That trade is only worth taking if the egress constraint is real for you. If your documents are already public, you are paying in operational complexity (running Ollama, managing local embeddings, reading docs/troubleshooting.md when ingestion misbehaves) for a guarantee you do not need. If the documents cannot leave, the same complexity is the price of the only acceptable architecture. There is no middle position in this repository's design: it is offline by construction, not offline by configuration flag.
Editorial conclusion
Adopt Local RAG if your documents cannot leave your network and you already run Ollama, and treat the ingestion guardrails as the feature worth evaluating first. Do not adopt it if you need a supported, versioned API, a documented configuration schema, or permissive licensing for redistribution. Before installing anything, open docs/setup.md, docs/pipeline.md and docs/todo.md in the repository and confirm that the model names, ports and ingestion limits they describe match the Ollama instance you intend to point it at.
Community notes