Knowledge Base Self-Hosting Kit: a Docker RAG stack with an MCP connector

What the kit actually assembles

The project targets one specific gap: a local retrieval layer that an autonomous agent can query without sending documents to a hosted API. The README describes it as a self-hosted RAG memory layer that pairs with local LLMs, chains, and agents. ChromaDB holds the vectors. Docling handles parsing of PDFs and code repositories. FastAPI exposes the CRUD, ingestion, and search surface, and an nginx gateway fronts everything on a single port. The intended user is someone already running Ollama on a host and wanting a retrieval service next to it, not a team looking for a managed vector database. The MCP server in mcp-server/ is the piece that distinguishes this from a plain RAG demo: it turns the HTTP API into a stdio transport an agent can attach to.

Ingestion, chunking and the two retrieval paths

Documents enter through POST /api/v1/rag/documents/upload for PDF, MD and TXT files, or through POST /api/v1/rag/ingest-folder, which reads from the host path mounted at /host_root and configured by DOCS_DIR (default ./data/docs). Chunking is controlled by CHUNK_SIZE (512) and CHUNK_OVERLAP (128). The README calls the strategy hybrid chunking, vector plus BM25, and the query endpoint POST /api/v1/rag/query is described as semantic queries with vector and BM25 fusion returning citation data. A second endpoint, POST /api/v1/rag/search, does immediate keyword search without LLM generation. That split is the practical design decision: search when you want raw hits and no model latency, query when you want a synthesised answer with sources. Responses carry answer, sources and scoring metadata, so a caller can inspect which chunks were fused into the result. Collections are created explicitly via POST /api/v1/rag/collections with embedding metadata, and GET /api/v1/rag/collections/:name/stats reports document counts.

The config API is the part worth copying

Most self-hosted stacks make you edit .env and restart. Here, GET /api/v1/config reads current .env values through a ConfigService, POST /api/v1/config persists updates from the UI, and POST /api/v1/config/test validates downstream connections such as the LLM and Ollama before the change is deployed. The Agent Configuration tab in the frontend is built on those three endpoints, which is why the README claims you can tune the connector without restarting containers. It is a narrow mechanism, and it is the most concrete engineering claim in the repository. The risk is obvious too: an endpoint that writes .env values is an endpoint that changes what model your retrieval layer talks to. Nothing in the README describes authentication on /api/v1/config, so treat the nginx gateway as the only boundary and do not expose port 8080 beyond the host unless you have checked that yourself.

Getting it up: compose, env keys, and the MCP server

The quick start is four commands. Clone the repository, cd into it, run cp .env.example .env and adjust DOCS_DIR plus provider settings, then docker compose up -d. Confirm the backend with curl http://localhost:8080/health and open http://localhost:8080 for the UI. The OpenAPI docs sit at /docs and the API root at /api/v1/rag. The env table lists PORT (8080), DOCS_DIR, LLM_PROVIDER (ollama, with openai, anthropic, gemini and openai_compatible also named), LLM_MODEL (llama3:latest), EMBEDDING_PROVIDER, EMBEDDING_MODEL (nomic-embed-text), CHUNK_SIZE, CHUNK_OVERLAP, DEBUG and LOG_LEVEL. For a local OpenAI-compatible server you set LLM_PROVIDER=openai_compatible and point OPENAI_BASE_URL at your endpoint. The agent side is separate: the README gives openclaw mcp add --transport stdio knowledge-kit npx -y @knowledge-kit/mcp-server, and the connector itself lives in mcp-server/ where you run npm install, npm run build, npm start. The Agent Configuration tab sets KNOWLEDGE_BASE_API_URL, timeouts and log levels for that server, and the README warns that if you change MCP wiring you must keep the tab and mcp-server reading the same env names.

Where this kit will not fit

The mcp-server directory requires Node and npm on top of the Python and Docker stack, so this is not a single-runtime deployment. The published connector is fetched with npx from the npm registry, which means the agent path depends on a package outside this repository being available and unmodified; the README does not state whether the package is version-pinned to the repository. Ingestion is file-oriented: PDF, MD, TXT, plus folder scans. There is no mention of databases, issue trackers, or incremental re-indexing, so a repository that changes daily will need its own re-ingest trigger. The search endpoint returns keyword hits without generation, which is fast but will not answer a question phrased differently from the source text. And the licence situation is unresolved: the repository metadata reports NOASSERTION while the README badge links to MIT. Those two cannot both be right, and until a LICENSE file is confirmed, an organisation with a licence review process has nothing to approve.

How it differs from a LlamaIndex or LangChain retrieval setup

A typical LlamaIndex or LangChain deployment is a library you import into your own application: you own the process, the scheduler and the HTTP surface, and you assemble the vector store, parser and retriever in code. This kit inverts that. It is a running service with its own compose file, its own nginx gateway, its own UI and its own config endpoints, and your agent talks to it over HTTP or through the MCP stdio connector. The trade is control for packaging. You get health checks, an OpenAPI surface and a browser tab for MCP settings without writing them; you give up the ability to swap the retriever by editing a few lines, because the fusion of vector and BM25 is inside the service. If your team already has an application layer, adding this means running a second system beside it. If your team has agents and no retrieval service, the packaging is the whole point.

Maintenance cost, licence risk, and the README problem

The README opens with an authorship dispute: the author states that a GitHub user and an automated account are claiming credit for the architecture, names several repositories as original work, and writes that he is out of open source and that further developed repositories will appear at another account. There are no releases retrieved for this repository. Taken together, that is a maintenance signal you should weigh before building on it: the code is present and the last push is dated 2026-03-14, but the author has stated an intention to stop publishing here. Upgrades will likely mean reading docker-compose.yml and the mcp-server package yourself rather than following release notes. On licensing, the metadata says NOASSERTION and the badge says MIT; the README also references a V4.0 Manifest and a Multi-Lane Consensus Architecture as original work. None of that settles what you may do with the code. Check for a LICENSE file in the repository root and read the mcp-server package metadata separately, since the connector may carry its own terms.

Editorial conclusion

Adopt it if you want a local ChromaDB and Ollama RAG service that an MCP-aware agent can call over stdio, and you are willing to read the compose file and the mcp-server package yourself before trusting the README. Skip it if you need a licence you can hand to legal, or if you want a maintained project: the README states the author is leaving open source. Verify first that the repository actually contains a LICENSE file matching the MIT badge, then run docker compose up -d and curl http://localhost:8080/health before wiring any agent to it.

Official sources

1. 2dogsandanerd/Knowledge-Base-Self-Hosting-Kit on GitHub
2. Issues
3. README