Open WebUI RAG and vector database setup guide

How Open WebUI RAG and vector database setup works in production

Most teams that want staff to ask questions over internal documents in Open WebUI start with a single container, upload a few files and get useful answers within an afternoon. The trouble begins when the deployment grows beyond one process. Once more than one worker or replica serves users, the default retrieval setup stops being enough, and the vector store becomes the first production decision you have to make. This section explains what changes and what to settle before users depend on the knowledge base. Retrieval-augmented generation adds a pipeline behind every knowledge collection and uploaded file. Open WebUI extracts text from each document, splits it into chunks, converts the chunks into embeddings and writes them to a vector database. When a user asks a question, the system embeds the question, retrieves the closest chunks and passes them to the model as context. Each stage can fail or degrade quietly, so the answer quality depends on every step, not only on the model you chose. The vector database choice comes first because it determines where embeddings live, how they are shared between processes and how the knowledge base is backed up and rebuilt. Open WebUI's features documentation lists 13 supported vector databases, including ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch. The default ChromaDB setup is the one the scaling guide warns will crash in multi-process setups, so an external store is required once you run several workers or replicas. Confirm with your own platform team which of the supported options you already operate, since running an additional stateful service has its own backup, monitoring and upgrade obligations. Retrieval quality is harder to get right than the install itself. The install is a fixed set of steps, while answer quality depends on extraction of your actual file formats, chunk size and overlap, the embedding model, and whether hybrid BM25 plus vector search and cross-encoder reranking are enabled and tuned. Scanned PDFs, tables and mixed-language content often fail in ways that look like model errors. Build a small set of representative questions with known source documents before go-live, and measure whether the right passages come back. Sizing the knowledge base also needs attention early. Ask the team that owns each source how many documents exist, how often they change and who may see them, because Open WebUI's per-resource permissions and group roles determine which collections a user can query. Plan for re-embedding when you change the embedding model or chunking settings, and confirm how long a full reindex takes on your storage before you promise a rollout date.

Which parts of Open WebUI retrieval you have to configure

Open WebUI retrieval is a chain of components, and a weak link in any one of them degrades answers for every user. The cards below separate what you set inside Open WebUI from what you run as an external service, so you know who owns each decision before you build.

Vector database connection

The vector database stores the embeddings that retrieval searches. Open WebUI supports 13 vector databases, including ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch, but the default ChromaDB is documented as crashing in multi-process setups. Choose an external store before you add workers or replicas, then confirm the connection type and credentials in the features documentation for your version. The database host, its backups and its capacity remain with your team.

Extraction engine for uploaded files

The extraction engine turns uploaded documents into text before anything is chunked or embedded, so poor extraction limits every later step. Open WebUI exposes a choice of extraction behavior in its settings, and the options differ by version. Test with your real file types, including scanned pages, tables and multi-column layouts, and confirm which engines your release offers and where they run. If an engine runs as a separate service, that service needs its own sizing and monitoring.

Embedding model

The embedding model converts text chunks and user queries into vectors, so it determines what the search can match. Open WebUI lets you select the embedding model and its endpoint, and changing it later means re-embedding the whole knowledge base. Confirm whether the model runs locally or through a remote provider, what data leaves your network if it is remote, and how your users' documents will be handled during processing.

Hybrid BM25 and vector search

Hybrid search combines BM25 keyword matching with vector similarity, which helps when users search for exact product codes, names or identifiers that embeddings handle poorly. Open WebUI documents hybrid search as a retrieval option, but the switch, weighting and result count are version-specific. Test queries that mix exact terms with natural language, and confirm the exact setting names in the features documentation before you write them into a runbook.

Cross-encoder reranking

A cross-encoder reranker rescores the candidate passages returned by search and reorders them by relevance to the question. It improves precision but adds a model call to every retrieval, which affects response time and the hardware or API spend behind it. Decide whether the reranker runs on your infrastructure or through an external service, and check the supported reranking models and the number of candidates each option evaluates in your version.

Knowledge collections and file storage

Knowledge collections group documents for access control, and their uploaded files must sit on storage that every replica can reach. Permissions on collections should follow your group model, so confirm how Open WebUI scopes knowledge to users and groups in your release. Plan the storage location, retention, deletion behavior and backup scope together, since the vector index and the original files can drift apart if they are restored separately.

Shared PostgreSQL and Redis state

Multi-replica setups need PostgreSQL instead of SQLite and Redis for shared sessions, websocket connections and application state. Without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. Retrieval depends on this state as much as on the vector store, so size and back up both services with the same care. Confirm the connection settings for each service in the scaling documentation for your version.

Which vector database fits your Open WebUI deployment

This table compares the vector stores Open WebUI supports for document retrieval by the conditions under which each fits and what it asks of your team to run. Read each row against two questions: can you reuse a PostgreSQL platform you already operate, and do you have tested backup and monitoring for another stateful service. Confirm the supported list and each option against the Open WebUI release you plan to run before you choose.

Vector store	Fits when	Operational load and cost to run
ChromaDB (bundled default)	Single-instance pilots and evaluation on one process	No extra service to run. The scaling guide warns it crashes under multiple workers or replicas.
PGVector on existing PostgreSQL	Multi-instance deployments where PostgreSQL is already required and backed up	Adds vector workload to a shared database. Watch index build time, memory and storage growth on that server.
Qdrant	A dedicated retrieval service once the knowledge base grows or needs isolation from the application database	Adds a stateful service to back up, monitor, patch and capacity plan. Confirm its deployment and upgrade steps for your release.
Milvus	Large collections, or teams that already run Milvus and its supporting components	Runs as a multi-component system, so the operational footprint is larger than a single-service store. Confirm the full dependency set with the vendor.
Elasticsearch	Teams already operating Elasticsearch that want keyword and vector search in one cluster	Cost follows the existing cluster. A new dedicated cluster adds sizing, patching and license tier decisions. Confirm which features your tier includes.
Other supported stores	Only when your organization already standardizes on one of the remaining supported options	Treat as a new stateful service unless it is already in your estate. Confirm support in your release before design.
Backup and monitoring already in place	Choose a store your team can back up, restore and alert on from day one	Without tested restores and alerting for the store, a dedicated service adds risk. Confirm recovery objectives with your own team.

Open WebUI RAG and vector database setup in build order

This sequence takes a retrieval setup from the deployment decision through to a signed-off test set. Each step closes with a check, so no later setting is tuned before the layer beneath it works.

Confirm deployment model and user count
The platform lead and the business owner agree on the replica count, the expected number of signed-in users and the identity method, then record them in a design note. A single-replica install for a small team can use SQLite only when the database file sits on locally attached SSD or NVMe storage. Any multi-instance design changes every later step, so ask the vendor or your architect to confirm which storage and vector options your installed version supports for that model. Done when the design note names the replica count, user count, storage choices and the person who approves the design.
Provision PostgreSQL, Redis and shared storage
The infrastructure team provisions PostgreSQL as the application database, Redis as the shared state store for sessions and websocket connections, and shared file storage that every replica can read for uploads and knowledge files. The scaling guide requires PostgreSQL for multi-instance deployments because SQLite does not handle concurrent writes from several processes well. Without Redis, signing out does not revoke tokens, which stay valid until they expire. Done when a file uploaded through one replica opens from a second replica, and signing out on one replica ends the session on the other.
Deploy and connect the vector database
The platform team deploys the vector database chosen in the design, such as ChromaDB, PGVector, Qdrant, Milvus or Elasticsearch, from the 13 options the retrieval documentation lists. The default ChromaDB crashes in multi-process setups, so it cannot serve several workers or replicas. Confirm which options your installed version integrates with and where the data will be hosted. The administrator then enters the endpoint and credentials in the retrieval settings, keeping secrets in the deployment's secret store. Done when the connection check passes on every replica and a test document's chunks appear in the vector store.
Choose and test the extraction engine
The business owner and an engineer assemble a sample set from the document types the team will load, including long PDFs, scanned pages, tables, spreadsheets and any internal formats. They run each file through the extraction engines available in the installed version and compare the extracted text with the source. Extraction options vary by release, so confirm them in your version's documentation before testing. Done when the team holds a written table showing which file types extract correctly, which need preprocessing and which stay out of the knowledge base.
Set embedding and chunking, then baseline
The engineer fixes the embedding model and the chunk size and overlap, then loads a pilot collection using dense vector search only. Confirm in your version's documentation whether changing the embedding model requires re-indexing existing collections, since mixing embedding models within one collection degrades retrieval. Run a short set of questions with known answers and record which source document each answer cites. This recorded result is the baseline. Done when the baseline shows the expected source document for the questions the owner marked required, and the settings are written into the configuration record.
Enable hybrid search and reranking
Only after the baseline exists, the engineer turns on hybrid BM25 plus vector search and cross-encoder reranking, changing one setting at a time. The same questions run again, and the team compares which source document ranks first and how long each answer takes. Reranking adds processing to every query, so measure the added latency in your environment rather than assuming it. Keep each setting that improves the baseline without breaking questions that already passed. Done when the comparison record shows each change, its effect on each question and the final settings signed off by the owner.
Create collections with group permissions
The administrator creates knowledge collections by business domain, assigns each one to the groups that need it, and grants read or write access at the collection level. Production documents load only after the extraction and baseline checks pass. Then the team signs in with a non-admin account from each group. Done when the account from the permitted group can query its collection, and an account from another group cannot see or query that collection at all.
Run the retrieval test set
The owner and an engineer write a retrieval test set of questions, each linked to the document that should answer it, covering every collection and group. Run the set through non-admin accounts from each group, because administrators can see collections that ordinary users cannot. Record whether the expected source document is cited and whether any answer draws on a collection the account should not reach. Done when the required questions return their expected source documents, cross-group queries return nothing, and the results are filed as the go-live baseline for later changes.

Why the default ChromaDB stops being the safe choice once you scale

The Open WebUI scaling guide warns that the default ChromaDB will crash in multi-process setups, so an external vector database is required once you run several workers or replicas. The practical consequence is that the vector store is not a detail you can revisit later. A single container with the bundled default is a reasonable place to evaluate retrieval-augmented generation, but the moment you add workers or replicas, you need a vector database that several processes can reach at once, and you need to move the knowledge collections that already exist into it. Decide this before the architecture is fixed, not after the first crash in a shared environment.

The decision changes the shape of the work. For an evaluation container, the default store is acceptable and the knowledge base can be rebuilt quickly if the team changes its mind. For a multi-replica deployment, the existing collections become a migration item. Confirm with your Open WebUI version and chosen vector database how the knowledge collections are stored, whether the embeddings can be exported or must be regenerated, and which embedding model and chunking settings were used. If the embedding model or chunk size changes, the stored vectors are no longer comparable with new queries, so the whole corpus must be re-embedded, not just copied.

Plan the reindexing scope explicitly. List every knowledge collection, the source files behind it, the extraction engine used to read them, and the embedding model. Then decide, collection by collection, whether to copy the existing vectors, re-embed from the original files, or retire the collection. Re-embedding from source is usually the cleaner path when the extraction engine or embedding model changes, because it avoids carrying forward chunks produced under old settings. Ask your DeployOpen team or your own platform owner to document these choices in the migration plan before any data moves.

Before users are moved onto the new deployment, verify that document counts match. Count the source documents, the chunks produced per document, and the stored vectors in the new store for each collection, and compare them with the counts recorded in the old environment. Run a fixed set of test questions against both systems and check that the same source documents are returned. Discrepancies usually point to failed extraction, skipped files or permission mismatches, and they are far cheaper to fix while the old system still serves as a fallback.

Plan this before onboarding users, not after. Once people have built knowledge collections and trust answers from them, a rebuild becomes a visible outage and a loss of confidence, and any change to the embedding model forces a second round of re-embedding. A planned migration lets you schedule reindexing, set a cutover date, and keep the previous store available for rollback. Ask any partner quoting this work to show the reindex scope, the count verification method and the rollback path as written deliverables, and confirm the supported vector databases and their versions for your target environment with the Open WebUI documentation.

What drives Open WebUI RAG effort and how to keep it down

This table lists the factors that most change the work of a retrieval setup in Open WebUI, how each one raises effort, and the practical step that keeps it contained. Read each row as a decision to make early, because several drivers, such as the vector store and collection access model, are costly to change after users have loaded content.

Driver	Why it raises effort	How to keep it down
Document volume and formats	Large corpora with mixed PDFs, Office files, email exports and images take longer to ingest, re-index and validate, and each new format adds extraction testing.	Start with a pilot corpus of representative files, agree the supported formats in writing, and set a size limit for uploads.
Number of knowledge collections and access groups	Each collection needs an owner, a group permission model and checks that users see only what they should, so effort grows with every group boundary.	Onboard collections in phases, starting with one or two owners, and reuse a small set of groups rather than creating a group per project.
Number of users and replicas	Multiple replicas need PostgreSQL, Redis, shared file storage and an external vector database, which adds components to configure, monitor and test together.	Confirm the replica count in the scope before design, and keep a single-replica pilot until retrieval quality is accepted.
Choice of vector store and whether it is new to the team	The default ChromaDB is not suitable for multi-process setups, so a外部 store is needed; an unfamiliar store adds skills, backup and monitoring work.	Pick a store the team already operates where possible, and confirm the Open WebUI version supports it before procurement.
Extraction quality for scanned or table-heavy files	Scanned pages need OCR and tables often lose structure during extraction, so answers can be wrong even when ingestion succeeds, which means more manual sampling.	Limit the first corpus to born-digital text, test a sample of tables and scans early, and decide which document types are out of scope.
Compliance and data residency constraints	Residency rules decide where embeddings, extracted text and vector indexes may live, and assessors expect evidence of where each copy sits and who can delete it.	Document the data flow before build, keep all vector and file storage inside approved locations, and collect retention and deletion evidence as the system is built.
Amount of retrieval tuning expected	Chunk size, overlap, hybrid search weighting, top-k and reranking each need measured trials, and every change can shift answers across collections.	Fix an evaluation question set with expected sources before tuning, limit tuning to agreed parameters, and record each run so changes can be compared.

How the vector store changes single node, HA and Kubernetes setups

A single Open WebUI process, started with Docker, Docker Compose or pip install open-webui followed by open-webui serve, can use the default vector store included with the install. The vector data, the database and the uploaded knowledge files sit on the same host as the application, so backups follow that host's data directory. This layout is the simplest to build, and it is where most teams test extraction and embedding settings before they scale.

Vector database location: The default store runs inside the container or host process, unless you point retrieval at an external database.
SQLite placement: The scaling guide accepts SQLite for single-replica use, evaluation and small teams only on locally attached SSD or NVMe storage.
Sharing and backup: Back up the data volume or directory as one unit, covering the database, uploads and vector files, and test a restore on a second host.
Failure modes: A full disk or a container restart with an unmounted volume can leave knowledge bases empty while chats still load.
Upgrades: Test each new version against a copy of the data directory before changing the live instance.

Confirm that the data directory sits on a volume you back up, and run one restore test before any user loads a knowledge base.

How access control applies to knowledge bases and vector data

A retrieval setup is only as safe as its weakest access path. Knowledge collections, vector store credentials, network placement and sessions each control whether a user can reach a document, so they need to be designed and tested together.

Group and per-resource access to collections

Open WebUI documents role-based access control with groups and per-resource permissions, so knowledge collections can be shared with specific groups instead of every account. Map each collection to the team that owns the source documents before ingestion starts. Check who can edit a collection, who can only query it, and whether any collection is open to all users by default.

Vector store credentials as secrets

The connection details for an external vector database, such as PGVector, Qdrant, Milvus or Elasticsearch, grant direct read access to every embedded chunk. Store them in the deployment's secret mechanism, not in environment files readable by users or in shared configuration exports. Confirm that no admin-facing screen or API response returns the raw credential, and rotate it when an administrator changes roles.

Network placement of the vector database

Place the vector database on an internal network segment that accepts connections only from the Open WebUI application instances. Users should never reach the database port directly, and other workloads should not share its network path. Verify the rule from a user-facing subnet and from a workstation to confirm the connection is refused.

Retrieval must respect document permissions

A document a user cannot open should not come back as a retrieval result for that user, even when its embeddings sit in the same vector collection. Confirm that retrieval filters by the same permissions that govern the source collection, and do not rely on the prompt to avoid quoting restricted text. Test this with a restricted document, a user outside its group, and a query that closely matches the document's content.

Access testing for retrieval results

Build a short test matrix that pairs each collection with a user who should see it and a user who should not. Run the same queries as both users and record whether restricted chunks appear in results or citations. Repeat the test after each change to groups, collection sharing, retrieval settings or the reranker, because any of these can alter what is returned.

Session end and token revocation

Without Redis, signing out does not revoke tokens. They remain valid until they expire, by default after 4 weeks, so retrieval access continues until the session does. Decide whether that window is acceptable for the data in each collection, and add Redis if a sign-out or account disablement must end access immediately. Test a disabled account's existing token against a retrieval request.

Scope review for API keys

API keys can query knowledge bases without the interactive session controls that apply to users. List every key that can reach retrieval endpoints, its owner, and the collections it can read. Remove keys for departed staff or retired integrations, and confirm that keys are not used to bypass the group rules set on each collection.

How to test retrieval quality and failure behavior

Retrieval quality should be tested with a fixed question set before and after every change that affects what the model is shown. Build the set from the pilot corpus: for each question, record the source document or documents that should answer it, and where useful, the passage or section. Run the set against the Open WebUI knowledge base once to establish a baseline, then rerun it after any change to chunk size or overlap, to the hybrid BM25 and vector weighting, to the embedding model, or to the cross-encoder reranker. Score each run on whether the expected file appears in the retrieved context and whether the final answer cites it. Changes that improve one group of questions while quietly breaking another are common, so compare per question, not only in aggregate.

The test set should be owned by the business team that will rely on the answers, not by the engineers who configured the system. Engineers tend to write questions that match the documents they already understand, and they rarely know which questions staff ask under pressure or which mistakes would cause real harm, such as a policy answer that cites a superseded version. Ask the business owner to supply the questions, the authoritative document for each, and a short note on what a wrong answer would cost. Keep the set under version control with a date and owner, and expand it when users report misses. Record the results for each Open WebUI release upgrade as well, because the upgrade notes and the project's release cadence can change retrieval behavior without any change on your side.

Access checks belong in the same plan. Create a test account that is not a member of the group that holds a restricted knowledge collection, then confirm through the interface and the API that it cannot list the collection, retrieve its chunks or receive an answer grounded in it. Repeat the check for a user who holds the group but not the per-resource permission, if your design separates them. Run these checks after every change to groups, roles or knowledge sharing settings, not only at go-live. A retrieval test that uses an administrator account will pass even when the permission model is wrong, so the test identities should match the roles your users actually hold.

Failure behavior needs its own tests. Stop the vector database deliberately in a test environment and send questions that depend on the knowledge base. The expected result is a clear error or a visible statement that retrieval is unavailable, not an answer that appears grounded but cites nothing. Then restart one Open WebUI replica while the others serve traffic, and confirm that uploaded files and knowledge remain reachable from every replica and that sessions survive where the Redis and shared storage design says they should. Confirm the exact behavior of your vector store version and deployment with the vendor and the Open WebUI scaling guide, since the guide warns that the default ChromiumDB-style local store is unsuitable for multi-process setups. Store the output of each test with the release and configuration it ran against.

What to monitor, back up and document after go-live

This table lists what operators should watch, protect and record once Open WebUI RAG is in production, with the signal to track and the evidence to keep for each item. Read it as a runbook baseline: each row names what to measure, how it fails quietly, and what a restore or re-index depends on. The main takeaway is that a vector store backup is only useful if its source files and embedding settings are recorded alongside it, and restore has been tested.

Area	What to track or keep	Why it matters for this setup
Vector store health and disk growth	Store availability, index size and free disk over time, per collection	Vector indexes grow with every ingested document and chunk, and a full disk can stop ingestion or retrieval without an obvious user-facing error
Extraction failures per file type	Failed and partial extractions counted by file type (PDF, Office, HTML, images) and by extraction engine	Failures often cluster in one file type, so a single average hides gaps that leave parts of a knowledge collection unsearchable
Ingestion queue backlog	Number of documents waiting, time since the oldest queued item, and retry counts	A growing backlog means newly uploaded documents are not yet retrievable, which users may read as the assistant ignoring their files
Retrieval test results per release	A fixed set of test questions per collection, with expected source documents, rerun after each Open WebUI or model change	Upgrades and setting changes can alter ranking, hybrid search and reranking results without any error being logged
Backups of vector data and source files	Vector store backups paired with the original uploaded files, plus a tested restore into a separate environment	Vectors can be regenerated only if the source files are kept, and an untested vector backup may not restore cleanly when it is needed
Embedding and chunking configuration record	Embedding model name and version, chunk size, overlap, extraction engine, reranker and hybrid search settings, with the date each changed	Changing the embedding model usually means re-indexing the collection, so the recorded settings are what allow a rebuild to match the original results
Owner list for each knowledge collection	Named business owner, technical contact, data classification and review date for every collection	Without a named owner, stale or sensitive documents remain searchable and no one is accountable for approving re-indexing or removal

What buyers and engineers ask before setting up Open WebUI RAG

Can we keep the default ChromaDB vector store for Open WebUI RAG?

Yes for a single instance, evaluation or a small team, but plan to move off it before you run several workers or replicas. The Open WebUI scaling guide warns that the default ChromaDB will crash in multi-process setups, so an external vector database is required once you run several workers or replicas. Open WebUI's retrieval features support 13 vector databases, including PGVector, Qdrant, Milvus and Elasticsearch. The decision depends on how many people query the knowledge base at once, how many Open WebUI instances you run, and how large the document set will grow. Confirm the configuration with a load test in your own environment. Moving later means reindexing knowledge, so make the choice before users load their documents.

How much does an Open WebUI RAG and vector database setup cost?

The cost depends on the written scope, and DeployOpen quotes from that scope and does not publish a price list. The one-time costs are the design, installation, vector database setup, document pipeline testing, and handover documentation. Recurring costs include the infrastructure for PostgreSQL, Redis, the vector database, shared file storage, and the embedding or reranking models, plus any ongoing support or retainer you choose. The Open WebUI software itself is distributed under the Open WebUI License, but deployments above 50 users in a rolling 30-day period that alter the branding need an enterprise license, which Open WebUI prices after contacting its sales team. Ask the quote to separate labor, infrastructure, licenses and recurring support so you can compare it with your internal estimate.

How long does it take to set up document retrieval in Open WebUI?

The duration is set by the written scope, and DeployOpen does not publish fixed timelines. The main drivers are the number of document sources and their volume, the extraction engine and vector database choices, whether hybrid search and reranking are included, the identity integration, and how many environments need testing before production. Retrieval quality also takes time to tune, because answers must be checked against realistic questions from the people who will use the knowledge base. Ask the quote to state the phases, the document collections in scope, the acceptance tests, and the dependencies on your team, such as access approvals, infrastructure provisioning and change windows. A scope that names these items lets you compare timelines across proposals.

What must our team provide before a RAG setup engagement starts?

Your team provides access, decisions and people, and the engagement depends on all three. Typical inputs include cloud accounts, data center or air-gapped network access, and approval to provision PostgreSQL, Redis and shared file storage, since multiple replicas need all three. Identify the document sources, a representative sample set, and the owners who can classify each collection by sensitivity. Name the model providers and embedding models that are approved, whether that is Ollama, OpenAI, Anthropic or another OpenAI-compatible endpoint. If you use SSO, provide identity provider details and group structures. Finally, name test users, success criteria and a change window for go-live. Missing inputs are the most common reason fixed-scope work slips, so list them in the written scope.

Can our own engineers set up Open WebUI RAG without a partner?

Yes, if your engineers have the skills and time, and Open WebUI supports Docker, Docker Compose, Kubernetes with Helm, and pip install open-webui followed by open-webui serve. The work requires container or Kubernetes operations, PostgreSQL and Redis administration, vector database operations, and a way to measure retrieval quality. Teams usually underestimate the evaluation work, which means building test questions, checking cited sources and tuning chunking and retrieval settings. A partner can take on fixed-scope delivery, documentation and handover, and DeployOpen implements, integrates and documents platforms inside the client's own infrastructure. Compare the skill gaps and the operating load after go-live with the cost of a fixed-scope engagement, and confirm which settings your version of Open WebUI exposes.

What changes when we turn on hybrid search or reranking in Open WebUI?

Open WebUI supports hybrid BM25 plus vector search and cross-encoder reranking, and each adds work at indexing time and at query time. Hybrid search builds a keyword index alongside the vector index, which increases storage and indexing work. Reranking adds a model that scores candidate passages before the answer is generated, which adds compute, memory and response latency. The reranker and embedding models must also run inside your environment, so an air-gapped deployment needs the model files staged in advance. Retrieval quality needs testing again after each change, because the results can shift for keyword-heavy questions and for long documents. Confirm the exact settings and supported reranker options in the documentation for the version you deploy, and include the testing effort in the written scope.

How do we control who sees sensitive documents in Open WebUI knowledge bases?

Start by classifying documents into collections that map to groups, then control access through role-based permissions and per-resource permissions in Open WebUI. Open WebUI documents role-based access control with groups and per-resource permissions, and SSO with SCIM 2.0 can keep group membership in sync with your identity provider. Use separate knowledge bases for different sensitivity tiers, so that a broad group never inherits access to a restricted collection by accident. Limit API key scope, since keys bypass the interactive sign-in path. With several replicas, Redis lets sign-out revoke tokens immediately; without it, tokens stay valid until they expire, by default after 4 weeks. Confirm how each permission applies to retrieved content, and test it with a user from each group before go-live.

How DeployOpen scopes, builds and hands over Open WebUI retrieval

DeployOpen plans, builds, documents and supports Open WebUI retrieval inside your own infrastructure, from the choice of vector database and extraction engine through to a knowledge base your team can run. Engagements are fixed-scope, so the retrieval design, deliverables and timeline are agreed in writing before build work starts.

How we scope

Inventory the document sources, formats and expected volume that the knowledge bases must cover before choosing components.
Confirm the deployment method, whether Docker Compose, Kubernetes with Helm or pip, and whether more than one replica is planned.
Agree in writing which vector database, extraction engine, hybrid search and reranking options are in scope, and which are excluded.

How we build

Configure the chosen vector database alongside PostgreSQL and shared storage, and avoid the default ChromaDB for multi-process or multi-replica setups.
Set up hybrid BM25 plus vector search and cross-encoder reranking, then test retrieval quality on representative questions from your users.
Document chunking, access permissions per knowledge base and sizing assumptions so the configuration can be reviewed and reproduced.

How we hand over

Deliver a runbook covering configuration values, reindex steps, backup and restore for the vector store and known failure modes.
Walk your platform and security teams through permissions, knowledge base ownership and how new documents are added and removed.
Provide test results and a list of open decisions so your team knows what was verified and what still needs review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
Retrieval changes are tested before they reach production, including reindexing effects when Open WebUI or the vector database is upgraded.
Confirm with DeployOpen during scoping which support hours, response paths and upgrade coverage the retainer includes.