Front-Ends: Open WebUI and Friends

By the end of this lesson you will be able to choose a chat front-end on grounds other than screenshots, connect one to any of the servers this course has taught, say what Open WebUI’s licence permits and forbids before rather than after you deploy it, set up accounts so that the household does not share one login, and describe exactly where the document-upload and web-search features stop being local.

What a front-end is, and what it is not

A server that speaks the OpenAI chat API already answers questions. It does not remember yesterday’s conversation, does not know who is asking, cannot read the PDF you dropped on it and has no opinion about which of your three models a given person should be allowed to use. A front-end is the program that adds all of that, and it adds it on its own side of the wire.

Where each responsibility lives

1. 1Browser or phoneRenders the conversation. Holds nothing; close the tab and nothing is lost, because nothing was stored here.
2. 2Front-endAccounts, roles, chat history, uploaded documents, retrieval, prompt templates, model permissions. This is the part with a database, and therefore the part that needs a backup.
3. 3OpenAI-compatible requestA list of messages and a model name, over HTTP. Nothing about users, history or files survives this boundary: the front-end has already flattened all of it into text.
4. 4Enginellama-server, Ollama, LM Studio or vLLM. Loads weights, allocates a context, generates tokens. Remembers nothing between requests.
5. 5ModelPredicts tokens. Has no idea that any of the layers above it exist.

Two consequences follow from that picture and they are worth holding on to. First, the front-end’s database is the only thing in the stack that would hurt to lose, which is why the lab backs it up and backs up nothing else. Second, everything the front-end does cleverly — retrieval, memory, system prompts — arrives at the engine as ordinary text inside the context window, competing for the same tokens as the conversation. A front-end cannot give a model a longer memory than the context length allows; it can only choose what to spend it on.

Open WebUI

Open WebUI is the front-end most people mean when they say “the chat interface”, and this course’s lab uses it. The version pinned here is Open WebUI 0.11.3 · verified 2026-09-08.

Deploying it

The documented paths are Docker and Python. The Docker quick start is one command:

RunnableAll tracks

the documented single-container start

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  -e WEBUI_SECRET_KEY=replace-this \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

The application listens on 8080 inside the container; the 3000 is only the host side of the mapping. The Python route is pip install open-webui followed by open-webui serve, listening on http://localhost:8080, with DATA_DIR choosing where its data lives; the documentation states that “Open WebUI supports Python 3.11 and 3.12. Python 3.13 is not supported yet”, which is the kind of detail that costs an hour if you meet it by surprise.

Generate the signing key rather than typing one: the hardening page describes WEBUI_SECRET_KEY as being “used to sign JWTs (login tokens) and derive encryption keys for OAuth session data”, and suggests openssl rand -base64 32.

Connecting it to a local server

Two mechanisms. Ollama is a first-class connection: OLLAMA_BASE_URL=http://server:11434, and a local install is detected automatically at http://host.docker.internal:11434 from inside Docker or http://localhost:11434 outside it. Everything else is an “OpenAI-compatible” connection, added under Settings, Admin, Connections, or set at start-up with OPENAI_API_BASE_URL=YOUR_URL/v1 and OPENAI_API_KEY.

The documentation’s own table of local servers gives the shapes to copy:

Server	Base URL to enter	API key
llama.cpp	http://localhost:10000/v1	leave blank
LM Studio	http://localhost:1234/v1	leave blank
vLLM	http://localhost:8000/v1	leave blank unless configured
Lemonade	http://localhost:8000/api/v1	leave blank

✕Common mistake

Two failures account for most “it cannot see my models”. The first is the /v1 suffix: the OpenAI-compatible connection needs it and the Ollama-native connection does not. The second is localhost inside a container, which means the container. From a container you want host.docker.internal on the host gateway, or better, a service name on a shared Docker network, which is what the lab does. If the server does not offer a /models listing, the documentation says to add the model identifiers by hand to the “Model IDs (Filter)” allowlist.

Accounts, roles and who may use which model

The first account created is the administrator, and sign-ups close automatically once it exists. The hardening page adds the piece people miss: the default role for a new account is pending, which “ensures that new accounts still cannot access the system until explicitly approved”, so re-opening registration for the household does not open the door to whoever finds the address. Feature-wise the documentation lists role-based access control with “roles, groups, per-resource permissions”, federation through SSO, OIDC and LDAP, and provisioning through SCIM 2.0 — far more than a house needs and exactly what an office does.

⛨Security

The hardening page is unusually direct about where this software belongs: “Open WebUI is built for private, trusted networks, similar to other self-hosted infrastructure like databases, container registries, and CI servers”, to be placed behind a VPN, a zero-trust proxy, or “reverse proxies with authentication and IP restrictions”, and never exposed directly to the public internet without additional protective layers. It also states that Open WebUI does not terminate TLS itself: “Place it behind a reverse proxy (Nginx, Caddy, HAProxy) that handles HTTPS.” The lab in this part is that sentence, carried out.

Five questions to ask before you install any of them

A chat front-end is the piece of this stack that other people will touch, which makes it the piece whose operational properties matter most and whose screenshots matter least. Ask these before the first docker run, not after somebody depends on it.

Where does its data live, and can you copy it? For a container that is a named volume; for a Python install it is DATA_DIR. If you cannot name the directory, you cannot back it up, and everything anybody types into it lives there.

Is the configuration a file or a settings screen? A file can be reviewed, committed and rebuilt from. A settings screen means the only record of how the service is configured is inside the thing you are trying to restore.

What does the default deployment expose? The documented Docker command publishes a port on every interface. On a machine that is only ever on your home network that is a small matter; on a laptop that sometimes has a public address it is not, and the fix belongs in the command rather than in a note to yourself.

How does it update, and what happens to the data when it does? A front-end that stores its state in a volume and its schema in the image will migrate on first start after an upgrade. That migration is the moment a backup is worth having, which is why the lab takes one before it does anything else.

What is the licence, and what does it require of your deployment? Not of your source distribution — of your deployment. That distinction is the whole of the next section.

The licence, which you must read before you deploy it for other people

Open WebUI changed its licence in 2025. The documentation states that code “up to and including release v0.6.5 remains BSD-3 licensed” and that from v0.6.6, released 19 April 2025, the licence “includes an additional branding restriction clause”. The LICENSE file in the repository is the authority, and clause 4 says that licensees are

strictly prohibited from altering, removing, obscuring, or replacing any “Open WebUI” branding, including but not limited to the name, logo, or any visual, textual, or symbolic identifiers that distinguish the software and its interfaces, in any deployment or distribution, except in the following circumstances: (i) deployments or distributions where the total number of end users (defined as individual natural persons with direct access to the application) does not exceed fifty (50) within any rolling thirty (30) day period; (ii) the licensee has obtained specific prior written permission from the copyright holder; or (iii) where the licensee has obtained a duly executed enterprise license expressly permitting such modification.

The documentation is equally plain about what that makes it: “Open WebUI v0.6.6+ is not an OSI-approved ‘open source’ license”. For a household of five this changes nothing at all — you are far under fifty people, and you were not going to replace the logo. For a company putting it in front of two hundred staff with the company’s own name on it, it changes everything, and finding out afterwards is expensive. Part 3’s licence lesson made this argument about model weights; it applies with equal force to the software around them.

Two alternatives worth knowing by name

LibreChat is MIT licensed, per the LICENSE file in its repository. Its documentation describes installation by “Docker, npm, and Helm Chart”, and a “Custom Endpoints” mechanism for connecting to “Ollama, Deepseek, Groq, and more”, configured in a librechat.yaml file rather than only through a settings screen. That file is the reason to choose it: a front-end whose configuration is a text file you can commit is a front-end you can rebuild from scratch, which is not true of a settings dialogue.

AnythingLLM is MIT licensed, per its LICENSE file, and ships in three shapes its documentation distinguishes: a desktop application for macOS, Windows and Linux, a self-hosted Docker deployment, and a cloud service. Its provider list includes Ollama, LM Studio and a generic “OpenAI (generic)” option, and it is built around workspaces with their own documents, with an embedder, a text splitter and a vector database as explicit, configurable pieces rather than hidden ones. If retrieval over your own documents is the main thing you want, that visibility is worth something.

Choosing between the three is mostly a licence-and-configuration question rather than a features question. All three will chat, all three will connect to the servers in this course, and none of them will make a small model behave like a large one.

Document upload and web search, and where they stop being local

These two features sell front-ends, and both deserve a sentence of scepticism.

Document upload is retrieval, not memory. The front-end splits your file into chunks, embeds them with an embedding model, stores the vectors, and at question time retrieves a few chunks and pastes them into the prompt. Open WebUI’s feature list names thirteen vector databases, hybrid search with BM25, several extraction engines, and a full-document injection mode as an alternative to retrieval. Two consequences follow. The embedding step needs a model of its own, which is why the course’s model reference includes qwen3-embedding-0.6b. And the retrieved chunks occupy the same context window as the conversation, so a long document and a long conversation compete; the next page in this part is about what happens when they lose.

Web search is the feature that leaves the house. Whatever the front-end labels it, a search feature sends your query to a search provider, and that provider is not on your network. Running the model locally protects the conversation; it does not protect a query you have chosen to forward. If the reason you are reading this course is that some of your text must not leave the building, that switch is one to leave off, or to point at a search service you also run.

?Reality check

The claim on offer here is that adding a front-end with document upload turns a small local model into something that “knows” your files. It does not. It gives the model a few paragraphs of your files at a time, chosen by a similarity search that has no idea what your question is for. When retrieval works it is excellent, and when it silently retrieves the wrong three paragraphs the model answers confidently from them. Part 10 builds retrieval properly and measures it, which is the only way to find out which of those two is happening to you.

Follow a message across the trust boundaries

Draw the browser, front-end server, model gateway and inference process as separate boxes, even if they run on one machine. The browser may authenticate to the front end while the front end holds a different credential for the model gateway. A browser login does not automatically protect a directly reachable engine port.

For each connection, record its address, authentication method and where message history is stored. Test access from another device without a session, then with the intended user account. Also check whether a model can be called directly by bypassing the front end. That negative test detects an exposure that a successful authenticated chat would miss.

Distinguish interface features from model features. A document upload may trigger extraction, embedding and retrieval services; a search button may contact an external service. Inspect the configured providers before describing the whole application as local. Backups should include irreplaceable accounts, configuration and conversation data according to your retention policy, with a restore test that verifies users can access the intended histories and models.

Recap

• The front-end owns accounts, history, documents and permissions; the engine owns weights and the context window. Everything clever the front-end does arrives at the engine as ordinary text competing for the same tokens.
• The front-end’s database is the thing worth backing up. Nothing else in the stack holds state you cannot rebuild.
• Connecting to a local server is an OpenAI-compatible connection with /v1 on the end, except for Ollama, which has a native connection without it.
• The first Open WebUI account is the administrator, sign-ups close behind it, and new accounts default to pending until approved.
• Open WebUI from v0.6.6 is not open source by the OSI definition: its branding clause binds any deployment with more than fifty users in a rolling thirty-day period. LibreChat and AnythingLLM are MIT.
• Document upload is retrieval into the context window; web search sends your query off your network. Both are useful and neither is free.

Check your understanding

Question 1. Your front-end runs in Docker and your engine runs natively on the same machine. You enter http://localhost:11434/v1 as the connection URL and nothing appears. Why?

• The engine needs restarting
• Inside a container, localhost is the container; the documented options are host.docker.internal on the host gateway, or a service name on a shared Docker network
• The /v1 suffix is wrong for every server
• Docker blocks outgoing HTTP

Show the answer and why

Answer: Inside a container, localhost is the container; the documented options are host.docker.internal on the host gateway, or a service name on a shared Docker network

This is the single most common connection failure and it has nothing to do with either program. The lab avoids it entirely by putting both containers on one private Docker network, where the engine is reachable by its service name.

Question 2. You want to run Open WebUI for a company of 200 people with your own logo replacing theirs. What does the licence say?

• It is BSD-3 licensed, so anything is permitted
• The branding clause prohibits altering, removing or replacing Open WebUI branding, with an exception only for deployments of 50 or fewer end users in a rolling 30-day period, prior written permission, or an enterprise licence
• Rebranding is allowed if you credit the project in a footer
• The licence only applies to redistributed source code, not deployments

Show the answer and why

Answer: The branding clause prohibits altering, removing or replacing Open WebUI branding, with an exception only for deployments of 50 or fewer end users in a rolling 30-day period, prior written permission, or an enterprise licence

The clause says "in any deployment or distribution", so running it internally counts. The documentation also states plainly that this is not an OSI-approved open-source licence. Read the LICENSE file before a deployment, not after.

Question 3. Which of these are true about a front-end's document upload feature? Select all that apply.

• It needs an embedding model in addition to the chat model
• Retrieved chunks are placed into the prompt and consume context length
• It gives the model permanent knowledge of the document
• A retrieval that returns the wrong chunks produces a confident answer from the wrong chunks

Show the answer and why

Answer: It needs an embedding model in addition to the chat model, Retrieved chunks are placed into the prompt and consume context length, A retrieval that returns the wrong chunks produces a confident answer from the wrong chunks

Retrieval is a search that writes into the prompt. Nothing about the model changes, which is why the same document has to be retrieved again for the next question, and why a long document and a long conversation compete for the same window.

Question 4. New Open WebUI accounts default to the role "pending". What is that for?

• It rate-limits new users
• It means a newly registered account cannot use the system until an administrator approves it, so re-opening registration does not hand access to whoever finds the address
• It marks accounts awaiting email verification
• It is a billing state

Show the answer and why

Answer: It means a newly registered account cannot use the system until an administrator approves it, so re-opening registration does not hand access to whoever finds the address

The hardening page calls this out because the first account becoming administrator and sign-ups closing behind it is only half the protection. The pending default is what makes re-opening registration for a household member safe.

Check my answersClear