Chipper: A Self-Hosted RAG Layer That Sits Between Ollama Clients and Your Local Models

The gap Chipper fills between Ollama and a retrieval pipeline

Ollama gives you a local model endpoint. It does not give you a document store, a chunker, an embedding step, or a way to tell an existing chat client to consult your files. Chipper is the layer for that gap. The README describes it as a web interface, CLI, and modular architecture for RAG pipelines, document splitting, web scraping and query workflows, built on Haystack, Ollama, Hugging Face, Docker, TailwindCSS and ElasticSearch. The intended user is stated plainly: the project began as a personal tool for working on a book with local RAG and LLMs, keeping the material off cloud services. That origin explains the feature set. Someone who wants private retrieval over their own corpus, with a chat surface attached, is the target. Someone shopping for a managed vector database product is not.

How the retrieval path is assembled

The architecture is a composition of named components rather than a single binary. Haystack supplies the pipeline abstraction, ElasticSearch stores and retrieves the vectorized data, Ollama or the Hugging Face API supplies inference, and the web UI is vanilla JavaScript with TailwindCSS so it works offline. Documents enter through chunking or web scraping, audio files can be transcribed first, and the resulting segments are embedded and indexed. At query time the pipeline retrieves from ElasticSearch and feeds the result into the model. Two details in the README are worth noting because they are behavioural, not marketing. For reasoning models such as DeepSeek-R1, Chipper suppresses the think output in the UI while keeping the reasoning steps in the console output, which means the console is the place to look when a response seems truncated. And the README states that multiple Chipper instances can be chained together for workload distribution, though it does not describe the protocol for that chaining, so treat it as a claim to verify in the docs rather than a documented interface.

Proxy mode is the most interesting design decision

Chipper can act as a proxy between an Ollama client such as Enchanted or Open WebUI and an Ollama instance. That is a different proposition from building a chat app. Instead of asking users to move to a new interface, you point their existing client at Chipper and the retrieval happens server side. The README says this enables server-side model selection, query parameters and system prompt overrides, and that RAG can be enabled for any Ollama client or used as a centralized knowledge base. The trade-off is that you are now inserting a service into a path that previously went straight to the model. If Chipper is down, the client is down. The README also lists API security as a feature, describing API key-based and bearer token service authentication on the proxied API, but it does not publish the exact header names or route decorations in the material available here. That is the first thing to confirm in the docs before exposing the proxy beyond localhost.

Getting it running: Docker first, then the /help command

The README does not inline installation commands. It points to a Quickstart page at chipper.tilmangriesel.com/get-started.html and to the project website, and it describes the deployment as fully containerized with minimal configuration. There is a Docker Hub image referenced in the badge links as griesel/chipper and a publish-docker workflow in the repository, so the container path is the documented one. Once the web interface is up, the README gives one concrete operational instruction: run the /help command to learn how to switch models, update the embeddings index and more. That is the only command-level detail in the supplied material. Configuration keys, environment variable names and compose file contents are not reproduced here, and I have not run the project, so I will not guess at them. If you need the exact set, the Quickstart page is the source.

Where Chipper is the wrong tool

The README carries an explicit note: this is a personal project and not designed for commercial or production use, and anyone using it in production should conduct their own due diligence. That sentence should be taken at face value. Beyond it, the architecture implies costs. ElasticSearch is a JVM service with its own memory footprint and operational surface, so a fully containerized Chipper deployment is not a lightweight laptop install in the way a single Ollama process is. The release cadence is modest, with v2.5.0 in June 2025, v2.4.0 in March 2025 and v2.3.0 in February 2025, which is fine for a personal tool and thin for anything with an upgrade window. And because the project is explicitly hackable and modular, the pipeline shape is something you are expected to adjust, not something the maintainer has frozen. If you want a retrieval stack that never asks you to read Haystack documentation, this is the wrong choice.

Alternatives and the actual difference in approach

Open WebUI appears in the README as a client that can talk to Chipper, and it is also a plausible alternative for the chat surface: it provides its own interface and document handling, and the difference is that Chipper positions itself as the retrieval and proxy layer beneath such clients rather than replacing them. The other comparison worth drawing is with a hand-written Haystack pipeline. Chipper is a packaged version of that, with the web UI, the CLI, the scraper, the transcriber and the proxy already wired together. The difference is control. A hand-written pipeline gives you the index schema, the chunk sizes and the deployment shape as your own code, and you pay for that in the work Chipper has already done for you. Chipper is the faster start with less say over the internals.

Maintenance, upgrades and the MIT licence

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence, and it does not override the README's warning about production readiness: a licence grants rights, it does not grant a warranty, and the MIT text disclaims liability. On maintenance, the material supports a limited statement. Releases arrive as tagged versions with names like Chipper 2.4.0, and the project is not archived, with a last push in May 2026. What the supplied material does not contain is a migration guide, a deprecation policy, or a statement about ElasticSearch index compatibility between minor versions. If you run Chipper and upgrade, the thing to check first is whether the release notes for the version you are moving to mention index or configuration changes, because a RAG service that loses its embeddings index loses its value. I am not giving legal advice here; read the MIT text and your own obligations.

Editorial conclusion

Adopt Chipper if you already run Ollama locally, want retrieval without writing a Haystack pipeline yourself, and accept the author's own statement that it is a personal project not intended for commercial or production use. Do not adopt it if you need vendor support, a published compatibility matrix, or a guarantee that the ElasticSearch index schema will stay stable across releases. Before committing, verify three things against the repository and the docs site: which ElasticSearch version the compose setup expects, whether the Ollama proxy route requires the API key decoration you plan to use, and whether the v2.5.0 release notes mention index or configuration migrations from v2.4.0.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TilmanGriesel/chipper on GitHub