Open WebUI

Open WebUI is a self-hosted web interface for large language models. The chat runs in the browser, but there is no single provider behind it: the interface connects to Ollama and to OpenAI-compatible APIs, so local and remote models appear in the same UI. A connection is a URL and an API key in the admin settings.

The project describes itself as extensible and able to run entirely offline, with the interface and its data staying on the machine. In our stack it is the single browser surface over several local models: the container runs on Docker and points at the local OpenAI-compatible endpoint.

One interface, several endpoints

The interface knows three connection protocols: Ollama, OpenAI-compatible APIs and Open Responses, so any local server that speaks one of them can be attached.

• On our machines the local models are served by LM Studio, and Open WebUI talks to it as an OpenAI-compatible endpoint.
• A multi-model chat sends the same prompt to every selected endpoint, so several models can be compared side by side.
• The selected endpoint decides where inference happens: local inference does not make a configured cloud tool or embedding service local.

Installing in a container

The documented install publishes the UI port, keeps persistent data in a named volume, and lets the container reach host services.

• Running without the volume is not advisable: chats, users and settings live there and survive an update.
• The secret key should be set once and kept, because without a fixed key every recreated container signs the users out. Inside a container localhost means the container, not the host.
• The :main image carries the speech-to-text and embedding models; :main-slim leaves the local machine learning stack out and expects external services for embeddings, speech, reranking, vector storage and document parsing. :main is a rolling tag, so production should use a version tag.

Data model and updates

The volume holds the whole state of the instance: conversations, accounts and settings. That makes the container replaceable, and it is why the volume is backed up before an update.

• Pulling a new image is not an update: the running container has to be stopped and removed, then a new one started with the same volume and secret.
• Under heavier load the instance can run as several containers behind a load balancer, with an external database and persistent storage. We use PostgreSQL for that.

Accounts and permissions

Access control rests on three roles and their permissions, and the model is additive: group memberships add capabilities to a role’s defaults.

• The roles are admin, user and pending: an admin has full control, a user’s abilities come from permissions and groups, and a pending account can do nothing until approved.
• The first account created becomes an admin and cannot be deleted through the API; on a shared instance a pending default role keeps new sign-ups locked out until an admin activates them.

What to watch

• No built-in context trimmer: a long conversation runs into the model’s context window, and the fix is a filter function that rewrites the message history.
• A role change does not revoke the token, so a demoted admin stays signed in and only loses the admin endpoints.
• A stock install still calls out on its own: a version check to GitHub, a model list request on the default OpenAI connection, and an embedding model update check.

Further reading

• Quick Start
• Connect a Provider
• Role-Based Access Control

At CyberElectro Open WebUI is the internal entry point to our local models: one browser surface in Docker over several models.