open-webui / open-webui
Open WebUI gives a team its own AI workspace, and an application to run
Open WebUI is a self-hosted interface for local and hosted models, with Ollama and OpenAI-compatible connections, document retrieval, tools, plugins and user management. It saves a great deal of assembly work. In exchange, whoever runs it is operating a multi-user application that can execute code and hold an organization's documents.
WHAT TO KNOW FIRST
- The first account becomes the administrator, sign-up then closes, and accounts created after an admin reopens it wait as Pending until approved.
- Tools, Functions, Pipes, Filters and Pipelines execute arbitrary Python on the server; the docs say to install only from trusted sources and that featured community listings are not vetted.
- The :main and :latest tags roll forward with every merge to the main branch; the docs recommend pinning a version tag for production.
01A chat front end that grew into a platform
The README calls Open WebUI a self-hosted AI platform built to run entirely offline, with support for Ollama and OpenAI-compatible APIs. The feature list now reaches well past chat: retrieval over documents with a choice of nine vector databases, web search through many providers, image generation and editing, voice and video calls, notes, team channels, calendars, scheduled automations, usage analytics and model evaluation. Authentication covers LDAP and Active Directory, OAuth and trusted-header single sign-on, and SCIM 2.0 provisioning.
That breadth is the reason to choose it and the reason to plan for it. An instance that began as a private chat window can become the place where a team keeps prompts, files and conversations, with users, groups and links into other systems. Decide early which features the instance is for and which stay off, and name the person responsible for it. The settings surface is large enough that an instance without an owner drifts into configuration nobody remembers choosing.
02Installing it the way the docs intend
The quick start's Docker command maps host port 3000 to the container's 8080, adds a host gateway so the container can reach an Ollama on the same machine, mounts a named volume at /app/backend/data and sets WEBUI_SECRET_KEY. The docs explain each flag. The volume holds chats, users and settings and survives updates, and the docs say never to run without it. Without a fixed secret key, every recreated container logs everyone out. A pip install on Python 3.12 with open-webui serve is also documented, listening on port 8080.
Image choice matters more than it first appears. The :main image bundles speech-to-text and embedding models, while :slim downloads at about 197 MB instead of 1.62 GB and leaves out the local machine-learning stack, so local embeddings, local Whisper and document extraction then need outside services. The docs list :cuda and :ollama variants for GPU support and a bundled Ollama. Choose the image from the features the instance will actually use and write the choice down, because the slim image refuses some settings the standard one accepts.
03The first account is the administrator
On first start, the setup screen offers to create an admin account, and that account manages users and every instance-wide setting. Sign-up then switches itself off. To let other people join, an admin turns on New Sign Ups in the authentication settings, and new accounts wait as Pending until they are approved in the Admin Panel. The docs ask operators to keep the admin password safe, since losing it locks them out of instance settings.
The flow is reasonable for a private instance and risky for one exposed to the internet before setup is finished, because whoever reaches the setup screen first becomes the administrator. Create the admin account before the service is reachable from outside, put it behind the same reverse proxy and TLS as other internal tools, and connect it to the organization's identity provider once there are more than a handful of users. Group permissions then decide who sees which models, knowledge bases and tools.
04Plugins run arbitrary code
Open WebUI's extensibility comes from Tools, Functions, Pipes, Filters and Actions, plus connections to MCP and OpenAPI tool servers. The plugin documentation opens with a critical security warning: these extensions execute arbitrary Python code on the server, by design. It tells operators to install only from trusted sources, says that a plugin being featured or popular on the community site is not an endorsement and does not mean its code was reviewed, and recommends auditing installed plugins regularly.
The same page warns that write access to the data directory would let an attacker plant code that runs on the server, because cached Tools and Functions live there, and it says only trusted administrators should have Workspace permission to create or import them. In practice, treat every plugin as a dependency with full server access: read the code, pin the version you reviewed, and keep a list of what is installed and why. Features that hand a model a terminal deserve an isolated environment of their own.
05Retrieval is only as good as its inputs
Retrieval-augmented generation is a large part of the feature set. Documents can be loaded into a chat or pulled from a library with the # command, extraction engines include Tika and Docling among others, and search can be hybrid, combining BM25 with vectors and a reranker. The vector store can be ChromaDB, PGVector, Qdrant, Milvus, Elasticsearch, OpenSearch, Pinecone, S3Vector or Oracle 23ai. The main database is SQLite, with optional encryption, or PostgreSQL, and files can sit on local disk or in S3, Google Cloud Storage or Azure Blob Storage.
Answers built from retrieved text inherit every flaw in that text: outdated versions, scanned PDFs that extract badly and documents some users should not see. Test retrieval on a small, known set before connecting a large share. Check that access to each knowledge base matches who may read the source files, and decide how deleted or replaced documents leave the index. A retrieval feature that answers confidently from the wrong file does more harm than one that answers nothing.
06Updates, tags and multi-worker migrations
The docs explain that :main and :latest are the same rolling image, rebuilt whenever a change lands on the main branch, and that :latest does not point to the newest stable release. Version tags such as :vX.Y.Z are pinned and never change, :X.Y follows the newest patch of a minor line, and the docs recommend pinning a version for production. Updates can be applied by hand or with Watchtower. The GitHub releases API showed v0.12.4, published October 25, 2026, as the latest release when this guide was checked.
One warning stands out for larger installs: when running with more than one Uvicorn worker, the update migration must run on a single worker first to avoid database schema corruption. Build that into the upgrade runbook, together with a backup of the data volume or PostgreSQL database taken just before the change. Keep the previous image tag at hand so a rollback means starting a known version against restored data, not guessing which rolling build was running last week.
07Read the license before rebranding
Open WebUI's current license is not a standard open-source license. The LICENSE file uses BSD-3-Clause style terms with a fourth clause: licensees may not alter, remove or replace the Open WebUI branding in any deployment or distribution, except when the deployment has 50 or fewer end users in any rolling 30-day period, when the copyright holder has given written permission, or under an enterprise license. Contributions are also covered by a contributor license agreement.
LICENSE_HISTORY records that code created before particular commits stays under earlier terms, BSD-3-Clause and before that MIT, and GitHub's API reports the license as other because of the custom clause. For an internal team that keeps the name and logo, the branding condition may never come up. For an agency, a product that embeds Open WebUI or anyone planning a white-labeled assistant for more than 50 people, it is a central decision that deserves legal review before work starts.
08When it is the right layer
Open WebUI fits a group that wants one self-hosted place to use several models, local and hosted, with shared knowledge bases and per-user permissions. It works in front of Ollama, vLLM or an OpenAI-compatible gateway, and the slim image keeps the footprint small when the model servers live elsewhere. Built-in OpenTelemetry support and Redis-backed sessions for multi-worker, multi-node setups show that larger deployments are expected.
It is a weaker fit for a product that needs its own branded interface for many users, for teams with nobody to own updates and plugin review, or for a single developer who only needs an API. Start with one model connection, a few users and no plugins. Add retrieval, tools and identity integration one at a time, each with a named owner, and the instance stays understandable as it grows.
A SENSIBLE FIRST HOUR
Start small enough to learn the repo
- Generate a key with openssl rand -hex 32, then run the Docker command from the quick start, which maps port 3000 to 8080, mounts the open-webui volume at /app/backend/data and sets WEBUI_SECRET_KEY to that key.
- Open http://localhost:3000 and create the first account, which becomes the administrator; sign-up then switches itself off until an admin enables New Sign Ups.
- Under your avatar, Settings, Admin, Connections, add a local Ollama or an OpenAI-compatible endpoint, send a test message, then upload one document and check what retrieval returns.
- Before inviting others, pin a version tag instead of :main, schedule backups of the data volume, and restrict Workspace access so only trusted admins can add Tools and Functions.
SOURCE LEDGER
What this review is built on
We use the project repository and first-party documentation. Access, licenses and project direction can change, so recheck the linked source before making a production decision.