Open WebUI: A Private Chat Interface for Teams

Open WebUI is a self-hosted web application that gives staff a ChatGPT-style chat window in front of a model running on your own hardware. The project's quick-start command is one docker run line with a single volume mounted at /app/backend/data, and that one directory ends up holding nearly everything that matters: user accounts, every chat, settings, uploaded files and the search index built from them. Understanding that directory is most of what it takes to run Open WebUI responsibly for a team.

What it is and where it sits

Open WebUI does not run models. It is the front end. Behind it sits a model server, usually Ollama or any runtime that speaks the OpenAI-style HTTP API. Open WebUI sends each prompt to that server, streams the answer back to the browser, and keeps the conversation history.

The model server and its GPU decide speed and concurrency; Open WebUI decides who logs in, what they see, and what gets stored. If the model server is not yet set up as a shared office service, start with running Ollama for a whole office, then put Open WebUI in front of it.

Accounts, roles and groups

The first account created on a fresh install automatically becomes the administrator. Everyone after that gets the role set by DEFAULT_USER_ROLE, which defaults to pending according to the environment variable reference. A pending user cannot log in until an admin activates the account. Sign-up itself is controlled by ENABLE_SIGNUP, which defaults to True, so anyone who can reach the login page can request an account. In a small office the pending queue may be enough; otherwise turn sign-up off and create accounts deliberately, or connect a directory.

There are three roles: admin, user and pending. Finer control comes from groups. Default permissions apply to everyone, and groups add permissions on top. The documentation is explicit that permissions are additive and that there is no "deny": if any group grants a feature, the user has it. To take a feature away from someone, it has to be off in the defaults and in every group that person belongs to. A "restricted" group cannot override a broader one.

For sign-in, the documented options include OAuth and OpenID Connect, LDAP, and trusted headers from an authenticating reverse proxy. Two limits are worth knowing before choosing:

• Only one OIDC provider can be configured at a time through OPENID_PROVIDER_URL.
• Trusted-header mode trusts whatever header arrives, so the docs warn it must only be reachable through the proxy. Otherwise a user can impersonate anyone by setting the header themselves.

Can the admin read everyone's chats?

By default, yes. ENABLE_ADMIN_CHAT_ACCESS defaults to True; setting it to False hides other users' chats from the admin panel. The reference is clear that this toggle covers the interface only: anyone with access to the server or the database can still read every chat, and admin exports include chats unless ENABLE_ADMIN_EXPORT is turned off too. Either setting is defensible, but staff should be told which one is in force and who can reach the server.

Documents and knowledge bases

Users can attach a file to one chat or add files to a named knowledge base that several people can query. Open WebUI extracts and embeds the text, then passes the closest pieces to the model with each question.

The defaults are fully local. Uploads go to local disk under DATA_DIR/uploads. The embedding model defaults to sentence-transformers/all-MiniLM-L6-v2, run locally, and the vector store defaults to an embedded ChromaDB, itself backed by SQLite. That embedding model is small and English-oriented, so test retrieval on documents in other languages or long technical text before relying on it.

Knowledge bases are private resources that can be shared with specific groups or users, and separate permissions control whether users may share knowledge bases at all and whether they may make them public. That is coarse access control at the collection level. It is not document-level permission inherited from a file server. If HR files and sales files end up in one collection, everyone with access to that collection can get answers drawn from both. The design questions behind a proper document Q&A system are covered in private RAG over internal documents.

What is stored, and where

With default settings, everything below lives in the data directory, so in the Docker setup it lives in one named volume.

What	Default location	What is inside
Application database	webui.db (SQLite) in the data directory	Users, roles, groups, chats, settings
Uploaded files	uploads under the data directory	The original documents users attached
Vector store	Embedded ChromaDB in the data directory	Text chunks and their embeddings
Audit log	audit.log in the data directory, only if enabled	Request metadata, optionally bodies
Secret key	Environment, or generated on first start	Signs login tokens, encrypts some data at rest

Three details change how this table should be read.

First, the vector store holds the text of documents in chunk form. Deleting an original from a file share does not remove what was already indexed here.

Second, many settings are stored in the database after first launch. The reference marks these as persistent config: changing the environment variable later is ignored unless ENABLE_PERSISTENT_CONFIG is set to False. An admin who edits a compose file and restarts, expecting a change, may see nothing happen.

Third, SQLite and the embedded ChromaDB suit one instance on one server, with the database file on a local SSD rather than network storage. The scaling guide says several instances need PostgreSQL, a client-server vector database, shared file storage and Redis, and that Open WebUI does not migrate data between databases. Choose before staff build up months of chat history.

Backup and restore

Because the state is concentrated, the backup is simple: stop the container, archive the data volume, store the archive elsewhere, start again. Stopping first matters because SQLite can be mid-write. The community backup guide in the docs follows this pattern and finds the volume with docker volume inspect open-webui.

Keep WEBUI_SECRET_KEY with the backup, stored separately and securely. The quick-start notes that recreating the container without a fixed key logs everyone out, and the key also encrypts some data at rest, so a restore without it is incomplete.

Size the backup from the uploads, not the chats. Take a 40-person firm where each person uploads 50 PDFs a year at an average of 2 MB. That is 40 x 50 x 2 MB = 4,000 MB, about 4 GB of originals per year, plus the vector store, which grows with the amount of text. A year of chat text from the same 40 people is usually far smaller. Thirty nightly full archives at the end of that first year come to roughly 30 x 4 GB = 120 GB plus the index, which fits on an ordinary NAS; incremental backups shrink it further.

Upgrades are where backups get used. The :main tag is rolling; the docs recommend pinning a version tag such as :vX.Y.Z for production. Back up, change the tag, start, and check that logins and old chats open. If something breaks, restore and return to the previous tag. Test a restore into a fresh volume once, before you need it.

License terms

Since version 0.6.6, released April 19, 2025, Open WebUI ships under its own license: BSD-3 style terms plus a branding clause. Code up to and including 0.6.5 remains plain BSD-3. The clause says you may not alter, remove or obscure the "Open WebUI" branding unless an exception applies. The exceptions are deployments with 50 or fewer users in any 30-day window, substantive contributors with written permission, and holders of an enterprise license that allows branding changes. The license FAQ adds that researchers can request permission for a specific, time-limited study. The project itself says the license is not OSI-approved open source.

For internal use with the branding intact, the clause changes little; it matters for a custom logo above 50 users. This is general information, not legal advice; read the license text on the project's site before deciding.

What Open WebUI does not solve

• The model server's exposure. If Ollama listens on the network without authentication, anyone can bypass Open WebUI and call the model directly. See how to lock down a local LLM server.
• Cloud connections. ENABLE_OPENAI_API defaults to True and OPENAI_API_BASE_URL defaults to OpenAI's public endpoint. Once an admin pastes in a cloud API key, prompts sent to those models leave the building. If the policy is local only, disable this and check the connections page after every upgrade.
• Community sharing. ENABLE_COMMUNITY_SHARING defaults to True. Turn it off internally.
• Audit trail. AUDIT_LOG_LEVEL defaults to NONE. If you need to reconstruct who asked what, it has to be switched on and its retention decided.
• Retention. Chats persist until someone deletes them. A rule for how long chat history and uploads are kept has to come from you.
• Answer quality. The interface cannot make a small model accurate. Wrong answers with confident wording are a model and retrieval problem.

A workable decision rule: if one instance on one server can carry the team, the defaults (SQLite, embedded ChromaDB, pinned image tag, nightly volume archive) are enough, provided sign-up, cloud connections and community sharing are reviewed on day one. If a second instance or extra workers are likely within the year, move to PostgreSQL before go-live.

Frequently asked questions

Does Open WebUI send any data outside the network by default?

The chat itself goes only to the model servers configured in it. The software does check for updates and downloads embedding models from Hugging Face, and OFFLINE_MODE=True turns those off. Download the embedding model before switching it on, or document upload fails on a fresh install. Connections an admin adds to cloud model APIs still work in offline mode, so those have to be removed separately.

Can staff delete their own chats, and is the data really gone?

Users can delete chats from their own history. Deleted data may still exist in earlier backups, so the backup retention period effectively sets how long a deleted chat survives.

Which image should be used on a server with an NVIDIA GPU?

The documentation points NVIDIA users to the :cuda tag, started with --gpus all added to the run command. The :slim tag is much smaller, but it drops the local embedding stack: knowledge bases then need an external embedding provider and PostgreSQL with pgvector, and PDF uploads need an external extractor. For a team that relies on documents, the standard image is simpler. Either way, pin a version tag for production instead of tracking :main.