OpenWebUI: External vs Built-in Knowledge

OpenWebUI ships with a capable built-in Knowledge workspace: upload documents, chunk them, embed them, and attach collections to chats. For a single user or a small team experimenting locally, that is often enough.

For organizations running OpenWebUI alongside other AI tools — LibreChat, Claude Desktop, Cursor, custom agents — the built-in knowledge layer becomes a second copy of data that already lives elsewhere. CoreCube is designed for that multi-frontend reality: one governed knowledge backbone that OpenWebUI (and every other client) consumes through a headless API.

This page explains the tradeoff, introduces ERI (the protocol OpenWebUI is moving toward for external retrieval), and shows where CoreCube fits today.

What is ERI?

ERI (External Retrieval Interface) is an OpenAPI-based protocol for decentralized RAG. Instead of copying documents into the chat platform's storage, an ERI server owned by the data provider handles ingestion, retrieval, access control, and citations. The chat UI calls the server at query time.

The OpenWebUI community has proposed native ERI support as a first-class External Knowledge Source type: read-only, admin-managed, selectable in chat alongside local collections. The MVP endpoints are:

Endpoint	Role
POST /auth	Authenticate the connection (token or username/password)
POST /retrieval	Send the user's prompt; receive ranked snippets and citation metadata

Later phases add discovery (GET /datasource, GET /retrieval/info) and governance hints. ERI is described in an ICSA-C 2025 paper; a reference Swagger UI documents the contract.

Status in OpenWebUI

Native ERI is still a proposal (working Filter prototypes exist; core merge is pending). Production teams today wire external backends through OpenAI-compatible connections — the same pattern CoreCube documents in the OpenWebUI setup guide.

Two architectures side by side

Built-in OpenWebUI Knowledge

Company documents ──upload──▶ OpenWebUI storage
                                    │
                                    ├─ chunk + embed (per collection)
                                    ├─ vector index (inside OWUI)
                                    └─ RAG at chat time (inside OWUI)

Strengths: zero extra services, fast to try, familiar UI for uploads and collection management.

Limits that show up at scale:

• Duplication — the same PDFs get uploaded again in LibreChat, Cursor, or a second OpenWebUI instance.
• No shared derived knowledge — synthesis from one chat does not compound into entity pages or project summaries for the org.
• Connector sprawl — Confluence, Jira, and file shares are configured per tool, not once for the whole suite.
• Governance — enterprise ACLs and sensitivity rules live in the retrieval stack you already operate, not in a chat UI datastore.
• Operational load — community reports around duplicate vector entries, storage bloat, and per-file index overhead when collections grow large (example discussion).

Built-in Knowledge is a good sandbox. It is a weak system of record for organizational knowledge.

CoreCube as external knowledge (ERI-shaped)

Company systems ──connectors──▶ CoreCube evidence layer
       │                              │
       │                              ├─ hybrid retrieval + citations
       │                              ├─ compartments + sensitivity ACLs
       │                              ├─ derived knowledge + freshness
       │                              └─ OpenAI-compatible / MCP APIs
       │                                        │
       └────────────────────────────────────────┼──▶ LibreChat, Cursor, agents…
                                                │
                                         OpenWebUI (connection)

OpenWebUI sends each chat to CoreCube's /v1/chat/completions. CoreCube resolves the user, searches only what they may access, injects context, and returns a cited answer. Documents are not re-ingested into OpenWebUI.

This matches the intent of ERI: the chat platform is the interaction layer; the knowledge provider owns retrieval end to end.

Comparison

Concern	Built-in OpenWebUI Knowledge	CoreCube external backend
Where documents live	OpenWebUI storage + its vector index	CoreCube evidence layer (connectors, library, check-ins)
Multiple AI frontends	Re-upload or re-sync per tool	Connect once; same corpus for OpenWebUI, LibreChat, Onyx, etc.
Per-user access control	OpenWebUI groups + collection visibility	Compartments, sensitivity levels, scoped retrieval per user
Connectors (Confluence, files, …)	Manual upload or custom pipelines	Native connector sync into one index
Citations & provenance	File/chunk references in OWUI	Source paths, timestamps, authority tags across the evidence layer
Knowledge that compounds	Per-session RAG only	Derived pages, summaries, freshness propagation
Admin model	Workspace admin in OpenWebUI	CoreCube admin + service keys per integration
Wire format today	Internal to OpenWebUI	OpenAI-compatible API (setup guide)
Wire format tomorrow	ERI client (proposed)	ERI-compatible connector possible; same role as today

Mapping CoreCube to ERI

Even before a native ERI connector exists in OpenWebUI, CoreCube already plays the ERI server role:

ERI concept	CoreCube today
External retrieval provider	Headless knowledge infrastructure (not a chat UI)
POST /retrieval at query time	Retrieval inside POST /v1/chat/completions
Data stays out of chat UI storage	Ingestion via connectors/library/check-ins only in CoreCube
Admin-managed source + health	Service API keys, scopes, connector status in CoreCube admin
Per-user authorization	X-OpenWebUI-User-Email (and equivalents for other frontends)
Citations back to source	Cited responses with evidence provenance

When OpenWebUI ships a native External Knowledge Source, CoreCube can expose an explicit ERI endpoint alongside the existing OpenAI-compatible path. Until then, the OpenWebUI integration guide is the supported production setup.

When to use which

Use built-in OpenWebUI Knowledge when:

• One team, one OpenWebUI instance, no other AI clients
• Quick experiments or personal document Q&A
• No requirement to enforce enterprise ACLs beyond OpenWebUI's own groups

Use CoreCube as the backend when:

• The same organizational knowledge must serve OpenWebUI and other interfaces
• Documents already live in Confluence, file shares, or other systems you do not want duplicated
• You need compartment- and sensitivity-aware retrieval per user
• Audit, provenance, and derived knowledge that stays current matter
• You are standardizing on OpenCore's knowledge layer across the suite

How to connect OpenWebUI to CoreCube

The integration uses OpenWebUI's Connections panel: point an OpenAI-compatible connection at CoreCube, enable user identity forwarding, and assign scopes in CoreCube admin.

Full steps: OpenWebUI setup guide →

Minimal shape:

1. Create a service API key in CoreCube (integration: OpenWebUI).
2. Set ENABLE_FORWARD_USER_INFO_HEADERS=true on OpenWebUI.
3. Add connection URL http://corecube:7400/v1 with the service key.
4. Set CoreCube models to Public visibility in OpenWebUI.
5. Assign each user a scope in CoreCube.

End-to-end flow:

User message in OpenWebUI
  → POST /v1/chat/completions (CoreCube)
      Authorization: Bearer <service key>
      X-OpenWebUI-User-Email: user@company.com
  → CoreCube retrieves, cites, completes
  → OpenWebUI displays the reply

Related reading

• Frontend integrations overview
• Introduction — the multi-silo problem
• Retrieval pipeline
• Access control explained
• OpenWebUI ERI proposal: Discussion #19969