# OpenRAG: a single-package RAG platform built on Langflow, Docling and OpenSearch

> OpenRAG bundles document ingestion, retrieval workflows and a chat interface into one Python package with a Docker Compose stack. It suits teams that want a working RAG loop before they want a custom one.

**langflow-ai/openrag** — OpenRAG is a comprehensive, single package Retrieval-Augmented Generation platform built on Langflow, Docling, and Opensearch. 

- Repository: https://github.com/langflow-ai/openrag
- Website: https://www.openr.ag
- Stars: 4,602 · Forks: 501
- Language: Python
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/langflow-ai-openrag

## The gap OpenRAG fills between a vector store and a working RAG loop

A retrieval-augmented generation system is four jobs glued together: parse messy documents, embed and index them, retrieve and re-rank, then hand the result to a model with a prompt. Each job has a good open source tool. The glue is where teams lose weeks. OpenRAG's pitch is that the glue is already written. The README describes it as a "comprehensive, single package Retrieval-Augmented Generation platform" and lists the three components it stands on: Langflow for ingestion and retrieval workflows, Docling for parsing, OpenSearch for storage and search.

The intended user is a team that has documents and a model endpoint but no retrieval layer. The README's highlight list is explicit about that audience: "Pre-packaged & ready to run" comes first, before the agentic workflow and scale claims. The repository layout backs this up. There is a Dockerfile per service (Dockerfile.backend, Dockerfile.frontend, Dockerfile.langflow), a docker-compose.yml, a kubernetes directory, and an alembic directory for schema migrations. This is a deployable system, not a library you import into an existing service.

It is not for someone who wants a retrieval library. If your application already owns its HTTP layer and you only need chunking plus a vector query, OpenRAG hands you a whole stack to run alongside it.

## How the pieces connect: Langflow flows, Docling parsing, OpenSearch storage

The README states that the system "utilizes Langflow for document ingestion, retrieval workflows, and intelligent nudges." That sentence is the architecture in miniature. Ingestion is a Langflow flow, not hardcoded Python. The .env.example confirms it with a switch: DISABLE_INGEST_WITH_LANGFLOW, documented as "Set to true to disable Langflow ingestion and use traditional OpenRAG processor." The comment adds that when unset or false, "Langflow pipeline will be used (default: upload -> ingest -> delete)." So the default data path is upload, run the flow, remove the temporary artifact.

The backend is FastAPI and the frontend is Next.js, per the README. OpenSearch is not a stock image. The Dockerfile removes opensearch-neural-search and opensearch-knn from the upstream 3.8.0 image and installs a jvector-based neural-search plugin plus repository-gcs and repository-azure plugins, and applies a Netty patch. That is a real fork of the search layer, and it explains why docker-compose.yml points at docker.io/langflowai/openrag-opensearch rather than the upstream image.

One operational detail in docker-compose.yml deserves attention. A comment warns against adding extra_hosts for openrag-backend because extra_hosts writes to /etc/hosts, which libc resolves before Docker DNS, so the alias overrides service-name resolution and routes OpenSearch's JWKS lookup to the host gateway. The comment states the symptom plainly: JWT validation breaks and every /search returns 401. That is the kind of failure that costs an afternoon, and it is documented in the Compose file itself.

## Installing OpenRAG with Docker Compose and running a first chat

The README does not inline install commands. It points to three documentation pages: the quickstart, the Python package install page at docs.openr.ag/install-options, and the Docker or Podman deployment page at docs.openr.ag/docker. The quick start workflow image sequence names the entry point: "uv run openrag to start." Treat that as the documented launch command for the packaged app.

The repository ships a Compose stack, and the .env.example is the configuration surface. Copy it and set at least the OpenSearch admin password, which docker-compose.yml reads as OPENSEARCH_PASSWORD and passes to the container as OPENSEARCH_INITIAL_ADMIN_PASSWORD.

```bash
cp .env.example .env
# set OPENSEARCH_PASSWORD in .env, then:
docker compose up -d
```

The Compose file exposes OpenSearch on ${OPENSEARCH_PORT:-9200} and its performance analyzer on ${OPENSEARCH_PERF_PORT:-9600}, and the healthcheck polls the cluster health endpoint until the status is green or yellow. Expect a start_period of 60 seconds before that check counts.

For application code, the README documents two SDKs. The Python one installs from PyPI and the example opens a client, sends a chat message, and prints the response field.

```python
import asyncio
from openrag_sdk import OpenRAGClient


async def main():
    async with OpenRAGClient() as client:
        response = await client.chat.create(message="What is RAG?")
        print(response.response)


if __name__ == "__main__":
    asyncio.run(main())
```

The TypeScript SDK follows the same shape: construct an OpenRAGClient, call chat.create with a message, read response.response. If you already use an MCP-capable assistant, the README says OpenRAG mounts an MCP server at /mcp over streamable HTTP, with no subprocess and no separate install, authenticated by the same API key via the X-API-Key header.

```json
{
  "mcpServers": {
    "openrag": {
      "url": "http://localhost:3000/mcp",
      "headers": {
        "X-API-Key": "orag_your_api_key_here"
      }
    }
  }
}
```

The README flags that the standalone openrag-mcp PyPI package is deprecated and that clients should point at the endpoint instead. The MCP server exposes tools for chat, semantic search, document ingestion, knowledge filters, and settings management.

## Ingestion timeouts and the Python 3.13 floor are the constraints that bite

The .env.example is unusually candid about large documents. It notes that for documents of 300 or more pages, ingestion can take over 30 minutes, and it exposes LANGFLOW_TIMEOUT (default 2400 seconds, 40 minutes, with a 30 second connection timeout) and INGESTION_TIMEOUT (default 3600 seconds, 60 minutes) with the instruction that the ingestion timeout "should be >= LANGFLOW_TIMEOUT to allow long-running ingestion to complete." If you lower one and not the other, a long PDF fails partway through with no obvious cause. The example also documents OPENRAG_OPENSEARCH_JWT_TTL, defaulting to INGESTION_TIMEOUT plus 300 seconds, which ties per-user document security tokens to how long ingestion is allowed to run.

The Python requirement is a hard boundary. pyproject.toml sets requires-python to ">=3.13". If your platform pins 3.11 or 3.12, the package will not install, and the SDK path is closed to you until you upgrade.

The project labels itself Beta in pyproject.toml ("Development Status :: 4 - Beta"), and the version in that file is 0.5.0 while the most recent release listed is v0.7.1 from 2026-08-31. A pre-1.0 version number means the SDK surface and the API can move between minor releases. Building a long-lived integration against it means tracking release notes.

Finally, OpenRAG is the wrong tool when you do not want to operate a search cluster. The stack includes OpenSearch with a 1 GB heap setting in Compose, plus Dashboards, plus Langflow. That is several containers with meaningful memory and disk needs. A single-user desktop search over a few hundred files does not justify it.

## OpenRAG versus wiring OpenSearch yourself

The honest comparison is not OpenRAG against another packaged RAG platform. It is OpenRAG against assembling the same three components by hand. If you index documents directly with opensearch-py, you control the mapping, the analyzers and the re-ranking logic, and you carry none of the Langflow runtime. You also write the parser integration, the chunking strategy, the retry handling and the chat orchestration yourself.

OpenRAG's answer to that is the visual flow builder. The README lists "Drag-and-drop workflow builder" as a feature, and .env.example shows the consequence: you can flip DISABLE_INGEST_WITH_LANGFLOW and fall back to a traditional processor, or keep the flow. That is a genuine trade-off rather than a selling point. A flow you can edit in a UI is faster to iterate on and harder to review in a pull request. Teams with strict change control will prefer the code path; teams prototyping will prefer the flow.

The OpenSearch image is the other divergence. Because OpenRAG swaps in a jvector-based neural-search plugin and removes the stock knn and neural-search plugins, you are not running vanilla OpenSearch. If you later want to point an existing OpenSearch client at the same cluster, expect a different plugin set from what you would get from the upstream distribution.

## Licence, upgrade cost and what the repository tells you about maintenance

OpenRAG is Apache-2.0, and pyproject.toml carries the matching classifier, "License :: OSI Approved :: Apache Software License". Apache-2.0 permits commercial use and modification and includes a patent grant. It does not settle the licences of what you run alongside it. Langflow, OpenSearch, Docling and the container base images each carry their own terms, and the Dockerfile pulls plugins from third-party release URLs, including a neural-search build hosted under the IBM organisation. Anyone packaging OpenRAG for redistribution should review those separately; this is a description of the licence text, not legal advice.

The last push to the repository was on 2026-09-20, three days before this writing, and the repository is not archived. Release cadence visible in the release list is roughly monthly through mid-2026: v0.5.1 on 2026-06-30, v0.6.0 on 2026-08-10, v0.7.1 on 2026-08-31. Upgrading means more than pulling a new image. There is an alembic directory, so schema migrations exist, and the OpenSearch image is versioned 3.8.0 in the Dockerfile with a matching plugin set. A jump in the OpenSearch base version would force a matching plugin rebuild, which is a maintenance task you inherit rather than one the project hides from you.

Docker Compose also pins the Dashboards image to opensearch-dashboards:3.8.0, so the dashboards and the cluster move together.

## Conclusion

Adopt OpenRAG if you want a working ingest, retrieve, chat loop without assembling Docling, Langflow and OpenSearch yourself, and you accept a Python 3.13 floor and a Compose stack with OpenSearch, Dashboards, Langflow and the backend. Do not adopt it if you need a small embedded retriever, a non-Python runtime, or a stable public API before 1.0. Verify first that your host can run the OpenSearch container with its 1 GB heap settings, that port 3000 and 9200 are free, and that your documents survive the default Langflow ingestion path before you point it at a production corpus.

## FAQ

### What is OpenRAG and what is it used for?

It is a Retrieval-Augmented Generation platform packaged as a single Python project, used to upload, process and query documents through a chat interface backed by large language models and semantic search. The README lists document ingestion, agentic RAG workflows with re-ranking, and a drag-and-drop workflow builder among its features.

### How do I install OpenRAG?

The README points to three documentation pages: the quickstart at docs.openr.ag/quickstart, the Python package install page at docs.openr.ag/install-options, and the Docker or Podman deployment page at docs.openr.ag/docker. The repository also ships a docker-compose.yml and a .env.example for a self-managed deployment.

### Is OpenRAG the same thing as OpenSearch?

No. OpenSearch is the search engine OpenRAG is built on. OpenRAG adds document ingestion through Langflow, parsing through Docling, a FastAPI backend, a Next.js frontend and SDKs, and it runs a modified OpenSearch image with a jvector-based neural-search plugin rather than the stock plugin set.

### What is OpenRAG?

The README describes OpenRAG as a comprehensive Retrieval-Augmented Generation platform for intelligent document search and AI-powered conversations, built with FastAPI and Next.js and powered by OpenSearch, Langflow and Docling.

## Sources

- [langflow-ai/openrag on GitHub](https://github.com/langflow-ai/openrag)
- [License: Apache-2.0](https://github.com/langflow-ai/openrag/blob/main/LICENSE)
- [Project website](https://www.openr.ag)
- [README](https://github.com/langflow-ai/openrag/blob/main/README.md)
- [Releases](https://github.com/langflow-ai/openrag/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/langflow-ai-openrag