Ragguri turns a folder of files into something you can ask questions of. It indexes what is there, finds passages by meaning rather than by keyword, and answers with the passages it used. “Who handles refunds” finds the function called reverse_payment and the paragraph that explains it.

The same engine ships as two products: a server for a team and its website, and a desktop application for your own files. Both watch a directory, so a new file is indexed without anyone remembering to re-index it.

Ragguri Server — the mature one

This is the product I deploy for customers, on their premises, with their documents and their models. It runs the website chatbot, answers developers through an MCP endpoint, and keeps the index on a machine they control.

It runs on the inference you choose. Point it at your own self-hosted model servers for chat, embeddings and re-ranking, or let it run everything on the CPU — for chat and for small models that is perfectly serviceable, and it means a customer can start without a GPU budget.

A chatbot for the company website. A small widget answers visitor questions from your documentation, with citations. It is the difference between a FAQ page and a help desk that can be asked a question it was not written for.

The corpus learns from what people ask. Questions that arrive through the widget are recorded. You read them, write or amend the answer you want given, and add it back to the index. Over a few rounds the bot stops being a search box over stale docs and becomes a virtual assistant that has been taught your answers — the same loop a help desk runs, minus the ticket queue.

An MCP endpoint for coding agents. Run the server beside a repository and an agent can ask it directly instead of guessing. Which module handles authentication. Where this config value is read. What the deployment script actually does. The agent reads your code and documentation rather than inventing an answer from a filename.

Answers survive navigation. A streamed answer runs in the server, not the page, so a visitor who opens another tab and comes back finds the answer finished.

Ragguri Desktop — pre-release

The same engine as a native desktop application, built with Rust, Tauri and SolidJS. Where the server is meant for a team’s documents on a shared machine, this is for your own files on your own desk.

A first-run wizard fetches the models it needs — about 3.5 GB for embeddings, re-ranking, a chat model and OCR — and asks which folder to watch. After that it behaves like a desktop app: drop a file into a watched folder and it is indexed, ask a question and the answer arrives with citations, and if the answer is not in your files it says so rather than inventing one. Workspaces keep two projects’ documents apart.

It is pre-release and still moving. I intend to open-source it once it reaches a state I would be comfortable handing to strangers.

Why it runs locally

Your documents stay where they are: on the customer’s premises for the server, on your machine for the desktop app. Models run on hardware you control, so there is no per-query bill and no third party reading the files. The desktop app’s optional cloud account covers the model catalogue and settings sync only; the documents never leave.

That is the whole point. Uploading an internal codebase, or a client’s documentation, to someone else’s API is not a decision I want to make on another person’s behalf.

Under the hood

Elixir and Phoenix on the server, Rust and Tauri with SolidJS on the desktop, with local embedding and re-ranking models underneath. The index lives outside the repository, so a project stays clean and nothing binary gets committed by accident.