OpenViSTAI · Agents · Blockchain · Crypto
Submit a project
Menu
Agent Memory & RAG

Dd Rag

Dd Rag is an open-source, self-hosted web application for organizational knowledge bases and AI assistance. It combines document lifecycle management and group permissions with PgVector and Elasticsearch hybrid retrieval, evidence-grounded question answering, and a conversational assistant with short-term memory summaries and an optional knowledge-base search tool.

Explore the practical guide ↓

Independent OpenViST project profile, based on linked sources.

Dd Rag — OpenViST project profile in Agent Memory & RAG.
OpenViST project illustration. See the linked sources for product details.
Understand the project

Practical overview

When it fits

Use Dd Rag when you need a self-hosted, group-scoped knowledge assistant and want document ingestion, hybrid retrieval and conversational model use in one application. It is also a relevant codebase to study how those components are assembled with Spring AI.

Who it is for

  • Organizations that want a permission-aware assistant over group-based document collections.
  • Developers exploring a full-stack Spring AI RAG application, including ingestion, hybrid retrieval, assistant tool calling and model governance.

Documented uses

  • Upload and manage documents through parsing, cleaning, chunking, indexing, status tracking and deletion.
  • Retrieve organizational information through combined semantic and keyword search, with answers grounded in retrieved evidence and cited files.
  • Hold multi-turn assistant conversations using short-term context summaries and optional KB_SEARCH calls.
  • Configure shared or user-managed model connections, permissions, routing and usage records.
Before you choose

Requirements & limits

The repository is public and the project is identified as open source, but the supplied repository evidence does not specify a license. A Docker Compose setup is documented for self-hosting.

  • The documented retrieval stack uses PostgreSQL with pgvector for semantic search and Elasticsearch with IK for keyword search; substituting either backend requires modification.
  • The application separates system roles (ADMIN/USER) from group roles (OWNER/MEMBER) and describes permission checks at group boundaries.
  • The assistant uses short-term memory summaries rather than an automatic long-term-memory path; KB_SEARCH is an optional assistant tool, not the QA service itself.
  • Docker Compose runs the documented services on one machine. High availability, multi-instance deployment and production secret management are outside that deployment design.
  • Chat-provider keys are configured through the application after startup, either by an administrator for shared connections or by a user through BYOK.

Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.

Source-based practical guide

Prepare a single-machine Docker Compose deployment

Start the documented self-hosted application and open its frontend.

Before you start

  • Docker Desktop or Docker Engine
  • Docker Compose v2
  • Access to Docker Hub and the Ollama model download source

Steps

  1. From the repository root, run the command below.

    Documented command
    docker compose up -d --build

  2. Run the command below to inspect the Compose services.

    Documented command
    docker compose ps

  3. Open http://localhost:5173 for the frontend.

Expected outcome

Compose starts PostgreSQL, Elasticsearch, MinIO, Ollama, the backend and frontend; the frontend is available at the documented local address.

Guide limitations

  • Initial startup pulls container images and downloads the qllama/bge-small-zh-v1.5 embedding model, with duration dependent on network and disk conditions.
  • The documented Compose setup targets single-machine self-hosting; production high availability, secret management and multi-instance deployment need separate design.
Documentation 1 ↗
Source-based practical guide

Configure a model connection for assistant conversations

Set up an authorized, tested model for use in an assistant session.

Before you start

  • A running application
  • For a shared connection, a platform administrator; alternatively, a user-managed BYOK connection
  • Credentials for the selected model provider

Steps

  1. For shared access, have a platform administrator create a model connection in /admin/model-governance, test the model, grant user access and configure scenario routing.

  2. Alternatively, manage a personal BYOK connection in /ai-settings.

  3. In an Assistant session, select an authorized and tested model before starting a conversation.

Expected outcome

The assistant can use the selected authorized model connection for a conversation.

Guide limitations

  • Chat-provider API keys are not configured at application startup; a model connection must be configured in the application.
  • Model connection secrets are stored in the database. The README advises restricting database access and not placing real keys in Git, logs or README files.
Documentation 1 ↗
Evidence and transparency

Sources & review

Official repository ↗
Source record details
Source availability
Active
Sources checked
16 October 2026
Original website title
t1804330987/DD_Rag · Official homepage title · retained in its source language
How we review sourcesSuggest a correction