WeKnora: A Self-Hostable Knowledge Platform That Turns Documents into a Living Wiki

What WeKnora Solves and Who It Is For

WeKnora addresses a problem that many knowledge management tools ignore: documents are static, but the questions people ask about them change. The platform ingests raw files, makes them queryable through RAG, and then goes further. It adds a ReAct agent that can orchestrate retrieval, call MCP tools, and use a tenant skill catalog. It also introduces a Wiki Mode where agents distill documents into interlinked markdown pages with a knowledge graph. This is aimed at enterprises that need more than a chatbot. Teams that want to maintain a living knowledge base, not just answer one-off queries, are the intended users. The project is built in Go and is designed for self-hosting, which matters for organizations with data sovereignty requirements. The README emphasizes complete data sovereignty through local or private cloud deployment. That positioning is clear: this is not a hosted SaaS product, it is a platform you run yourself.

How the Architecture Fits Together

WeKnora's architecture is modular, which is evident from the list of swappable components. You can change the LLM provider, the vector database, and the storage backend. The platform supports 20+ LLM integrations, including OpenAI, DeepSeek, Qwen, Zhipu, Hunyuan, Gemini, MiniMax, NVIDIA, LiteLLM, and Ollama. That breadth is useful for teams that want to avoid vendor lock-in. The data flow starts with multi-source ingestion. The README lists Feishu wiki, Feishu Drive, GitLab, Tencent IMA, Notion, Yuque, and RSS as sources. Documents are parsed in-process using anydoc, which handles PDF, Word, images, Excel, and XMind. Once parsed, the system creates chunks that can be edited in the UI with revision history. That chunk editing is a distinctive feature. It treats retrieval units as first-class objects, not hidden internals. The agent layer sits on top of this, using retrieval and MCP tools to answer complex questions. The Wiki Mode is separate from the RAG pipeline, though it uses the same underlying document store. Agents generate markdown pages, and users can edit them manually with version control.

Getting It Running: Commands and Configuration

The README does not provide a single docker run command in the cleaned text, but it points to a VitePress documentation site with quickstart sample data and standalone Docker or Nginx deployment instructions. The project has a version 0.8.0 release, and the CHANGELOG is referenced. For configuration, the documentation site covers about 150 environment variables. One example is RESOURCE_URL_MODE, which controls whether file URLs are directly loadable. The README mentions resource_urls=public as a mode. That setting affects how third-party apps render images and files without a second authenticated proxy call. The platform also supports scoped API keys with a principal model, which suggests you configure access at a granular level. For the agent sandbox, v0.8.0 introduced session-persistent Docker, E2B, and Cube backends. Docker is opt-in, meaning you must enable it explicitly. The local host-process backend was removed. That is a breaking change. If you want to run skills, you need to choose one of the remaining backends. The official MCP server is available as a PyPI package, tencent-weknora-mcp, which you can install separately.

The Wiki Mode and Chunk Editing: A Different Kind of Knowledge Base

Most RAG tools treat documents as immutable sources. WeKnora takes a different approach by allowing chunk editing with revision history. You can edit a retrieval chunk in the UI, see a diff, and roll back to a previous version. The system automatically reindexes after edits. That is a practical feature for fixing errors in source material without reprocessing the entire document. The Wiki Mode goes further. Agents distill raw documents into a self-maintaining, interlinked markdown knowledge base. The result is an interactive knowledge graph. Users can edit wiki pages manually, and the system keeps snapshots with line-level diffs and one-click rollback. This is not a static export; it is a living artifact that changes as the source documents change. The trade-off is that an agent-generated wiki can drift from the original documents. The revision history helps, but it does not solve the fundamental problem of trust. You need to verify what the agent produced, especially if the wiki is used for critical decisions.

Sandboxed Skills and the Tenant Skill Catalog

The v0.8.0 release introduced a tenant skill catalog, which lets you install skills from ClawHub, SkillHub, git, or a zip file. Skills run in sandboxes, and the platform supports session-persistent Docker, E2B, and Cube backends. Each tenant has a network policy, which is a security boundary. The README mentions per-sandbox snapshots, live progress, file browse and edit, and personal or workspace environment variables. This is a serious attempt at running untrusted code safely. However, the removal of the local host-process backend is a warning. Running skills in-process was convenient but risky. Now you must manage Docker or rely on a cloud sandbox like E2B. That adds operational overhead. The network policy per tenant is a good idea, but the README does not explain how it is enforced. You would need to check the documentation for details. The official DeepSeek Harness plugin, @wxg-prc-cpg/dsh-weknora, is an npm package that integrates with WeKnora. This suggests the skill ecosystem is still young, with limited third-party plugins.

Multi-Tenancy, RBAC, and Observability

WeKnora is designed for enterprise use, and that shows in its access control and monitoring features. It supports multi-workspace RBAC with a 4-tier role matrix, per-resource ownership, and a per-workspace audit log. That is more granular than many open-source knowledge tools, which often have a single admin role. The platform also integrates with Langfuse for observability. You can trace agent reasoning, token usage, and pipeline execution. That is essential for debugging agent behavior and for cost control. The README also mentions a runtime task-queue dashboard with worker-pool governance. That gives you visibility into background jobs, such as indexing and wiki generation. Multi-instance storage backends per workspace are supported, so you can place data in different locations based on sensitivity. This is a strong feature for organizations with data residency requirements. However, all of this complexity means you need to understand the system deeply before deploying it at scale. The 150 environment variables are a hint that the platform is not trivial to configure.

Limitations and When It Is the Wrong Tool

WeKnora is not a simple plug-and-play RAG server. The configuration surface is large, and the documentation site covers about 360 API endpoints and 150 environment variables. That is a lot to learn. The project is also young, with the latest release being v0.8.0 as of September 2026. The codebase is in Go, which is unusual for LLM applications that often use Python. That may be a strength for performance, but it could be a barrier if your team is Python-only. The sandbox situation is a real limitation. If you want to run agent skills, you must either run Docker, which is opt-in, or use a cloud sandbox like E2B or Cube. That introduces external dependencies. The local host-process backend was removed in v0.8.0, so there is no easy local execution mode. For a small team that just wants to chat with a PDF, WeKnora is overkill. A simpler RAG tool would be easier to deploy. Also, the README does not mention any built-in evaluation framework, despite the topic listing including evaluation. That gap means you need to bring your own evaluation tooling to measure retrieval quality.

Alternatives and How They Differ

The most direct alternative is a dedicated RAG framework like LlamaIndex or Haystack. These tools focus on retrieval pipelines and offer more control over chunking, embedding, and reranking. They do not include a built-in agent sandbox or an auto-wiki feature. You would need to assemble those components yourself. Another alternative is a document management system with AI features, such as Notion AI or a commercial tool. Those are hosted and easier to use, but they do not offer self-hosting or the same level of customizability. WeKnora's approach is distinct because it combines RAG, agentic reasoning, and wiki generation in one platform. The closest comparison might be something like Danswer or RAGFlow, which also provide a full-stack RAG experience. However, WeKnora's Wiki Mode and chunk editing with revision history appear to be unique. If your primary need is a simple question-answering bot, those alternatives may be simpler. If you need a knowledge platform that evolves, WeKnora's integrated design is worth evaluating.

Maintenance, Upgrade Cost, and License Implications

The project is actively maintained, with three releases in as many months: v0.8.0 in September 2026, v0.7.2 in August, and v0.7.1 in July. That cadence suggests frequent feature additions and bug fixes. However, it also means you need to track the CHANGELOG carefully. The v0.8.0 release notes mention breaking changes, such as the removal of the local host-process sandbox. Upgrading may require configuration changes, especially if you used the old sandbox. The README states the license is MIT, although the repository metadata says NOASSERTION. The README badge shows MIT, and the LICENSE file is linked. The discrepancy is worth noting. If you rely on the license, you should verify the exact text in the LICENSE file. MIT is permissive, allowing commercial use and modification with attribution. That is favorable for enterprise adoption. The project also depends on many external services, such as LLM providers, vector databases, and sandbox backends. Those dependencies introduce ongoing cost and maintenance. The documentation site, with its 150 environment variables, is a sign that configuration drift is a real risk. You should version your configuration and test upgrades in a staging environment.

Editorial conclusion

Adopt WeKnora if you need a self-hostable, multi-tenant knowledge platform that goes beyond simple RAG, with agentic workflows, sandboxed skill execution, and a self-maintaining Wiki. Avoid it if your team lacks capacity to manage Docker, multiple backends, and a growing set of environment variables. Before committing, verify that your LLM provider and vector database are supported, test the sandbox network policies against your security requirements, and review the CHANGELOG for v0.8.0 breaking changes, such as the removal of the local host-process sandbox.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Tencent/WeKnora on GitHub