The Complete Open WebUI Guide: Build Your Own Private ChatGPT (2026)

You have a model running in Ollama or LM Studio. It works, but the terminal is spartan and the LM Studio window only lives on one machine. What you really want is the ChatGPT experience — a beautiful chat interface with saved conversations, folders, file uploads, web search, multiple users, and access from any device in your house — except entirely yours, entirely private, running on your own hardware.

That is Open WebUI. It is the front end that turns a local model into a polished, multi-user, self-hosted AI platform. This complete guide takes you from a single Docker command to a fully featured private assistant: installation on every platform, connecting your models, document chat (RAG), web search, image generation, voice, user management, custom models, remote access, and the plugin system that lets it do almost anything. Beginner-friendly, but thorough enough to run for a whole team.

Table of contents

• What Open WebUI is and why you want it
• How the pieces fit together
• Installing Open WebUI
• First launch: the admin account
• Connecting your models
• Your first hour: a guided walkthrough
• Configuration and environment variables
• The feature tour
• Chatting with your documents (RAG)
• Web search: grounding answers in live results
• Image generation
• Voice: speech-to-text and text-to-speech
• Users, groups and permissions
• Custom models and prompt presets
• Pipelines, tools and functions
• Open WebUI for families, students, teams and developers
• Accessing it from anywhere, safely
• Updating and backing up
• Performance and scaling
• Open WebUI vs cloud ChatGPT
• Getting genuinely good results from RAG
• Best practices and common mistakes
• The operations cheat sheet
• Recommended stacks by budget
• Troubleshooting
• Frequently asked questions

What Open WebUI is and why you want it {#what-it-is}

Open WebUI is a self-hosted web application — you run it on a computer you control, and you reach it through a browser. It began life as "Ollama WebUI" and grew into a full platform that rivals commercial chat products feature-for-feature, while keeping the one thing they cannot offer: everything stays on your hardware.

Think of the local-AI stack as three layers. At the bottom is the engine that runs the model (Ollama, LM Studio, llama.cpp, or vLLM). In the middle is the model itself (Qwen, DeepSeek, Gemma). On top is the interface — and that is where Open WebUI lives. It does not run models itself; it makes the models you already run genuinely pleasant and powerful to use.

Why bother, when the terminal or LM Studio already works?

• It is the ChatGPT experience, self-hosted. Saved conversations, folders, regenerate, edit, branch, markdown, syntax-highlighted code, LaTeX math — all the polish you expect.
• It is multi-user. Give your family or team accounts, each with their own chats and permissions. One machine serves everyone.
• It is device-agnostic. Because it is a web app, you use it from your laptop, your partner's tablet, or your phone — no install per device.
• It bundles the hard parts. Document RAG, web search, image generation, and voice are built in and click-to-enable, instead of scripts you assemble yourself.
• It is extensible. A plugin system (Pipelines, Tools, Functions) lets it do nearly anything, from calling external APIs to enforcing rate limits.

If you are weighing it against alternatives, our review Open WebUI vs LM Studio vs Jan lays out the trade-offs. The short version: LM Studio is the best single-user desktop experience; Open WebUI is the best multi-user, self-hosted platform. Many people run LM Studio or Ollama as the engine and Open WebUI as the face. It is also the natural front end for a private AI assistant for business.

How the pieces fit together {#architecture}

Before installing, it helps to see the shape of the system. Open WebUI is the hub; the model engine and optional services plug into it.

The key insight: Open WebUI talks to the engine over the same OpenAI-compatible API the rest of local AI uses. That is why it works with Ollama, LM Studio's server, a remote vLLM box, or even a cloud API you add deliberately — all at once, switchable from a dropdown. You are assembling Lego bricks that share one connector.

Installing Open WebUI {#installing}

Open WebUI runs best in Docker. If you do not have Docker, install Docker Desktop (Windows/Mac) or Docker Engine (Linux) first — it is a one-time setup.

If you already run Ollama

This is the most common case. This command starts Open WebUI and points it at the Ollama already running on your machine:

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

Then open http://localhost:3000. That is it. The -v open-webui:... part creates a persistent volume so your accounts, chats, and settings survive restarts and updates. --restart always brings it back after a reboot.

All-in-one (Open WebUI + Ollama bundled)

If you do not already have Ollama and want everything in one container, use the bundled image. For an NVIDIA GPU:

docker run -d -p 3000:8080 --gpus=all \
  -v ollama:/root/.ollama \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:ollama

This starts both services together — convenient for a single dedicated box.

Docker Compose (recommended for a real deployment)

For anything you plan to keep, a docker-compose.yml is cleaner to manage and upgrade. Compose lets you pin versions, add the optional services (a vector database, image generation), and bring the whole stack up or down with one command. The project ships example compose files; adapt one to your setup.

Python / pip (no Docker)

There is also a pip install (pip install open-webui then open-webui serve) for environments where Docker is awkward. It works, but Docker is the supported, reproducible path and the one to prefer on a machine you will rely on. A dedicated always-on box is the ideal home — see Personal AI Home Server.

First launch: the admin account {#first-launch}

The first time you open http://localhost:3000, Open WebUI asks you to create an account. This first account is special: it becomes the administrator, with full control over settings, users, and models. Everyone who signs up after is a normal user until you promote them.

There is no cloud sign-in and no email verification — this account lives only in your local database. Choose a real password; if you ever expose the instance beyond localhost, this is the front door.

Once in, you land in a familiar chat window. If you connected an engine that already has models, they appear in the model dropdown at the top left, and you can start chatting immediately. If the dropdown is empty, head to the connections settings — the next section.

Connecting your models {#connecting}

Open WebUI needs to know where your models live. Under Settings → Admin → Connections you manage two kinds of backend:

• Ollama API. If Open WebUI is on the same machine as Ollama, the default http://host.docker.internal:11434 usually just works. If Ollama is on another machine (a home server), enter its address, e.g. http://192.168.1.50:11434.
• OpenAI-compatible API. Add any endpoint that speaks the OpenAI protocol: LM Studio's server on :1234, a remote vLLM box, or a genuine cloud API (OpenAI, or an open-model cloud provider) if you want a mix of local and hosted models in one interface.

You can register several backends at once, and every model from every backend shows up in the same dropdown. That means a single Open WebUI can offer, say, a fast local qwen3:8b for everyday chat, a heavyweight local deepseek-r1:32b for hard problems, and a cloud model for the rare task that needs it — the user just picks from a menu. You can even pull new Ollama models directly from Open WebUI's admin panel, no terminal required.

Your first hour: a guided walkthrough {#walkthrough}

Reading about features is one thing; here is the concrete path from zero to a genuinely useful private assistant, in about an hour. It assumes you already have Ollama installed.

Minutes 0–5 — pull a model and start Open WebUI. In a terminal, ollama pull qwen3:8b (or a bigger model if your GPU allows — check the Hardware Analyzer). Then run the Docker command from the install section and open http://localhost:3000. Minutes 5–10 — create your admin account and say hello. Sign up (this first account is the admin), pick your model from the top-left dropdown, and send a message to confirm everything is wired up. Watch the response stream in — that is your local model talking through a real interface. Minutes 10–20 — set up a useful custom model. Go to Workspace → Models → create a new model. Base it on qwen3:8b, name it "Assistant," and give it a system prompt that matches how you work — for example, "You are a concise, practical assistant. Prefer bullet points. Admit when you are unsure." Set temperature to 0.6. Now you have a tuned assistant, not a raw model. Minutes 20–40 — build a knowledge base. Under Workspace → Knowledge, create a collection called "My Docs" and upload a handful of PDFs or notes you actually care about. Set a local embedding model (ollama pull nomic-embed-text first, then select it in RAG settings) so this stays fully offline. Back in a chat, type #My Docs and ask a question about your files. The model answers with citations — you have built private document RAG. Minutes 40–60 — add reach and polish. Optionally enable web search for current-events questions, add Open WebUI to your phone's home screen as a PWA, and — if you want household access — set up remote access over Tailscale. Approve a family member's account if they want in.

At the end of the hour you have a named, tuned assistant that can chat, read your documents, optionally search the web, and be reached from any device — all private, all yours. Everything after this is refinement.

Configuration and environment variables {#config}

Most of Open WebUI is configured in the admin UI, but a handful of environment variables (set in your docker run command or compose file) control important behavior. These are the ones worth knowing:

# --- Auth & sign-up ---
WEBUI_AUTH=True                 # require login (keep True unless single-user demo)
ENABLE_SIGNUP=False             # after creating your accounts, disable new sign-ups
DEFAULT_USER_ROLE=pending       # new users need admin approval (safe default)
WEBUI_SECRET_KEY=<random>       # signing key for sessions; set a strong value

# --- Model backends ---
OLLAMA_BASE_URL=http://host.docker.internal:11434
OPENAI_API_BASE_URL=http://host.docker.internal:1234/v1   # e.g. LM Studio
OPENAI_API_KEY=lm-studio        # placeholder for local, real key for cloud
DEFAULT_MODELS=qwen3:8b         # what loads by default

# --- RAG ---
RAG_EMBEDDING_ENGINE=ollama
RAG_EMBEDDING_MODEL=nomic-embed-text

# --- Behaviour ---
ENABLE_WEB_SEARCH=True
WEBUI_NAME=Home AI              # brand the interface for your household/team

Two of these matter most for security: after you have created the accounts you need, set ENABLE_SIGNUP=False so no one else can register, and always set a strong WEBUI_SECRET_KEY. Leaving sign-up open on a reachable instance is the most common self-hosting mistake. For a business deployment, the private AI for business guide covers the fuller hardening checklist; for a home box, approval-only sign-up plus a VPN is plenty.

Because these live in your compose file, your entire configuration is reproducible and version-controllable — redeploy the same stack on new hardware in minutes, which is exactly what you want for a home server you might rebuild.

The feature tour {#features}

Open WebUI has accumulated a genuinely large feature set. Here is the map of what you get out of the box.

We will cover the big ones in depth below. But even the chat basics are a step up: you can edit any earlier message and regenerate from there, branch a conversation to explore two directions, switch models mid-chat to hand a hard question to a bigger model, and organize everything into folders. Code blocks are syntax-highlighted with copy buttons, and math renders as LaTeX — small touches that add up to a serious daily tool.

Chatting with your documents (RAG) {#rag}

This is Open WebUI's flagship feature and the reason many people install it. Retrieval-Augmented Generation lets the model answer questions about your files — PDFs, Word docs, spreadsheets, markdown, code — without any of it leaving your machine.

There are two ways to use it:

• Attach a file to a single chat. Click the upload button, add a document, and ask about it. Good for one-off "summarize this" or "what does clause 7 say?"
• Build a knowledge base. Under Workspace → Knowledge, create a collection and upload many documents into it. Then reference the whole collection in any chat with #. This is how you make a persistent, queryable library — a company handbook, a research corpus, a codebase.

Under the hood, Open WebUI chunks each document, turns the chunks into vectors with an embedding model, and stores them in a vector database. When you ask a question, it retrieves the most relevant chunks and hands them to the chat model, which answers with citations back to the source passages. You can choose which embedding model to use (a local one via Ollama, like nomic-embed-text, keeps RAG fully offline) and tune chunk size and retrieval count in settings.

For the theory and a from-scratch build, see Intro to RAG: Chat with Docs and the advanced Complete Local RAG Pipeline. RAG is what makes local AI genuinely useful for private document analysis — the documents that are too sensitive for a cloud tool are exactly the ones this handles safely.

Web search: grounding answers in live results {#web-search}

Local models have a knowledge cutoff — they do not know about events after training. Open WebUI's web search fixes that: enable it, and the model can search the web, read the results, and answer with current information and citations. It is RAG, but the "documents" are live search results.

You enable it under Admin → Settings → Web Search and choose a search backend (several providers and self-hostable options like SearXNG are supported; some need a free API key). Once on, a toggle appears in the chat box. Ask "what happened in AI this week?" and the model actually looks it up rather than guessing. Combined with a good local model, this closes much of the gap with cloud assistants while keeping your queries under your control (aside from the search itself, which by nature hits the web). For fully offline setups, simply leave web search off — see running LLMs offline.

Image generation {#images}

Open WebUI can generate images too, by connecting to an image backend — a local ComfyUI or AUTOMATIC1111 Stable Diffusion install, or a cloud image API. Once configured under Admin → Settings → Images, you can ask the assistant to create an image and it renders inline, or turn a chat reply into an image prompt. Running the image backend locally keeps this private and free, though image models want a capable GPU of their own — another reason a card with generous VRAM like the RTX 5090 is a comfortable home for a do-everything AI box.

A practical note on resources: image generation and a large language model both want VRAM, and running them on the same GPU at the same time can cause contention or spills. On a single card, either use a smaller chat model while generating images, or accept that the first image after a big chat may be slow as memory is juggled. On a machine with two GPUs, dedicating one to image generation and one to the language model is the clean solution. For most people, occasional image generation alongside chat works fine on a 16–24 GB card; heavy, simultaneous use is where a second GPU or more VRAM pays off.

Voice: speech-to-text and text-to-speech {#voice}

Open WebUI has built-in voice. Speech-to-text (via Whisper, which can run locally) lets you dictate prompts; text-to-speech reads answers aloud. There is also a hands-free call mode that turns the whole thing into a spoken conversation — talk, listen, repeat. Point the STT and TTS engines at local models and you have a private voice assistant that never phones home, the same idea as the Offline Voice Assistant guide but wrapped in a friendly UI. It pairs naturally with vision and RAG for a genuinely capable multimodal assistant.

Configuring it is straightforward under Admin → Settings → Audio: choose a speech-to-text engine (local Whisper keeps dictation private; it runs well even on modest hardware) and a text-to-speech engine (from a simple built-in voice to higher-quality local models for more natural speech). Call mode is especially good on a phone — with Open WebUI added to your home screen and reached over a VPN, you have a spoken, private assistant in your pocket that works on mobile data without any of your speech leaving your own server. It is a genuinely futuristic experience that, a couple of years ago, only cloud giants could offer.

Users, groups and permissions {#users}

Because Open WebUI is multi-user, it has real access control — the feature that makes it viable for a family, a class, or a company rather than just one person.

New sign-ups arrive as pending and cannot log in until an admin approves them — so even if someone finds your login page, they cannot get in without your say-so. Admins assign models, tools, and features per user or per group, so you could give the family the general chat models while reserving a heavyweight reasoning model for yourself, or give a work team a specific knowledge base. For an organization, this role model plus on-prem hosting is what makes Open WebUI fit into a private AI for business strategy and satisfy the access-control expectations discussed across the Enterprise hub.

Custom models and prompt presets {#custom-models}

Open WebUI has a Model Builder (Workspace → Models) that lets you create custom model configurations without touching a file. Pick a base model, write a system prompt, set the temperature and other parameters, optionally attach a knowledge base and tools, give it an avatar and a name — and it appears as its own entry in the model dropdown.

This is how you build purpose-made assistants for everyone to share: a "Support Agent" wired to your help-desk knowledge base, a "Code Reviewer" with a strict system prompt, a "Legal Analyst" that only answers from the contract collection. It is the GUI equivalent of an Ollama Modelfile, but with RAG and tools bolted in. Writing effective system prompts is a skill worth developing — System Prompts & Personas 101 is the primer. You can also save reusable prompt presets (slash-command style) for text you type often.

Pipelines, tools and functions {#pipelines}

This is the layer that turns Open WebUI from an app into a platform. Three extension mechanisms let you add behavior:

• Tools — functions the model can call mid-conversation: fetch a web page, query a database, do math, hit your company API. This is how you build a local agent with a friendly UI.
• Functions — lightweight Python that customizes the app itself: new buttons ("Filters"), custom model providers ("Pipes"), and UI actions.
• Pipelines — a separate companion service for heavier logic: multi-step RAG, request routing, rate limiting, usage monitoring (e.g. Langfuse), or offloading expensive work off the main app.

There is a community library of ready-made tools and functions you can import in a click. Start simple — most people never need Pipelines — but knowing the ceiling is high is reassuring. It means the private assistant you stand up today can grow into an agentic system without switching platforms, connecting to the coding-agent and automation workflows the site covers elsewhere.

A concrete example makes it click. Suppose you want your assistant to answer "what's the weather in Berlin?" with real data. You add a weather Tool — a small Python function that takes a city and returns the current conditions from a weather API — and grant your model access to it. Now, when someone asks, the model recognizes it needs live data, calls the tool with city="Berlin", receives the result, and weaves it into a natural answer with the real numbers. The same pattern extends to querying your database, searching an internal wiki, creating a calendar event, or running a calculation. Filters (a kind of Function) can pre-process every prompt — redacting sensitive strings before they reach the model, say — or post-process every reply. And a Pipe can present an entirely custom "model" in the dropdown that actually runs a multi-step chain behind the scenes. This is the machinery that turns a chat window into an application platform, and it is why teams standardize on Open WebUI rather than outgrowing it.

Open WebUI for families, students, teams and developers {#audiences}

The same software fits very different needs. Here is how each kind of user gets the most from it.

For a family / household. Run Open WebUI on one always-on machine (a spare PC, a mini PC, or a Mac) and give each family member an account. A mid-range GPU serves everyone. Kids get a homework helper, adults get a private assistant for email and admin, and none of it goes to a company that profiles your household. Reserve heavier models for yourself with per-user model access, and reach it all from phones over Tailscale. It is a one-time hardware cost instead of several monthly subscriptions — the math is in the Cost Calculator. For students and self-learners. A tuned "Tutor" custom model plus a knowledge base of your course PDFs turns Open WebUI into a patient study partner that quizzes you, explains concepts, and answers from your actual materials — offline, free, and without the usage caps of cloud tools. See Using LLMs for Learning. For a small team or business. This is where multi-user, permissions, and knowledge bases shine. Stand up shared assistants ("Support Agent," "Policy Bot") wired to internal documents, control who can use what, and keep every byte on-premise — which is often the entire reason a regulated team can use AI at all. Pair it with a throughput engine like vLLM for many concurrent users. The Enterprise hub and private AI for business cover governance, and on-premise AI under the EU AI Act covers compliance. For developers. Open WebUI is a fast way to give your projects a UI. Point it at multiple backends, expose your own tools and pipelines, attach knowledge bases as testable RAG, and use it as the front end for agentic systems. Because it speaks the OpenAI protocol underneath, everything you prototype here ports cleanly to production.

Accessing it from anywhere, safely {#remote}

The magic of a web app is reaching it from any device. Inside your home network, that is free: from another device, browse to http://:3000 and log in. Add it to your phone's home screen and it behaves like a native app (it is a PWA).

Reaching it from outside your home requires care, because now you are exposing a login page. Do it the safe way:

The VPN route is strongly preferred for a home setup — it is the approach in Personal AI Home Server (Tailscale), and it means you can use your private AI from your phone on mobile data without opening a single port. A reverse proxy with HTTPS is the right pattern when you genuinely need a public URL, e.g. a small team without a shared VPN.

Updating and backing up {#updating}

Updating. Open WebUI moves fast. To update the Docker container, pull the new image and recreate the container — your data survives because it lives in the named volume, not the container:

docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui && docker rm open-webui
# re-run your original docker run command

Many people automate this with Watchtower, which watches for new images and updates containers for you. Pin to a specific version tag instead of :main if you prefer stability over the newest features.

Backing up. Everything — accounts, chats, knowledge bases, settings — lives in the open-webui Docker volume. Back that volume up (a simple docker run --rm -v open-webui:/data -v $(pwd):/backup alpine tar czf /backup/owui-backup.tar.gz /data) and you can restore or migrate the whole instance. Do this before major updates.

Performance and scaling {#performance}

Open WebUI itself is light — it is a web app, and the heavy lifting is done by the model engine behind it. So performance tuning is really about the engine and the hardware:

• Model speed is set by your GPU and the model size, exactly as in the Ollama and LM Studio guides. Keep models fully in VRAM; the benchmarks page shows expected tokens/sec per GPU.
• Concurrency — if several people use the instance at once, the engine must serve parallel requests. For Ollama, raise OLLAMA_NUM_PARALLEL. For a busy team, a throughput-focused engine like vLLM behind Open WebUI handles many simultaneous users far better than a single-user runner.
• RAG cost — large knowledge bases spend time embedding and retrieving; a decent embedding model and a real vector database (pgvector, Qdrant) keep it snappy at scale.
• The host — a modest CPU and 8–16 GB of system RAM run Open WebUI comfortably; the GPU is what matters, and it is doing the model work, not the UI.

For a household, one good GPU is plenty. For a team, size the engine and GPU to the number of concurrent users — the Enterprise hub and cost calculator help you plan capacity and compare against per-seat cloud pricing.

Open WebUI vs cloud ChatGPT: an honest comparison {#vs-cloud}

Open WebUI deliberately mimics the commercial chat experience, so it is fair to ask how it actually stacks up. The honest answer: for privacy, cost-at-scale, and control it wins decisively; on raw peak capability, the biggest cloud models still lead — but the gap has narrowed to the point where it rarely matters for everyday work.

The practical takeaway: for the large majority of real tasks — drafting, summarizing, coding help, document Q&A, learning — a good open model like Qwen 3 in Open WebUI is more than capable, and the privacy and cost benefits are decisive. Keep a cloud option in the same dropdown for the rare frontier-level task, and you get the best of both. The deeper economics are in cloud AI vs local AI and the Cost Calculator; the capability picture is in who is winning the local LLM race.

Getting genuinely good results from RAG {#rag-tips}

RAG is powerful but not magic — a badly tuned setup returns irrelevant chunks and the model answers poorly. A few habits make the difference between "wow" and "useless":

• Chunk sensibly. Too-small chunks lose context; too-large chunks dilute retrieval. The defaults are a reasonable start; for dense technical docs, moderately larger chunks with some overlap help.
• Use a strong embedding model. The embedding model decides what counts as "relevant." A good local one like nomic-embed-text or mxbai-embed-large markedly outperforms a tiny default. This is the highest-leverage RAG setting.
• Retrieve enough, but not too much. Returning the top 3–6 chunks usually beats stuffing 20 in; more context is not always better and costs speed.
• Ask targeted questions. "What is the notice period in the employment section?" retrieves better than "tell me about the contract."
• Ground the model. A system prompt that says "answer only from the retrieved context and cite it" prevents the model from filling gaps with invention.
• Curate the knowledge base. Garbage in, garbage out — a focused collection of relevant documents beats a giant dumping ground.

For a large or mission-critical corpus, move to a dedicated vector database and the techniques in the Complete Local RAG Pipeline. Done well, local RAG turns your private files into a searchable expert you can interrogate in plain language — the core of privacy-safe document analysis.

Best practices and common mistakes {#best-practices}

A short list that will save you the headaches most first-time self-hosters hit:

• Always mount the data volume. The number-one mistake is running the container without -v open-webui:/app/backend/data and losing everything on the next update. The volume is your database; treat it as precious and back it up before upgrades.
• Disable open sign-up once you're set. Leaving ENABLE_SIGNUP=True on a reachable instance means anyone who finds the URL can register. Set it to False after creating accounts, and keep new users on approval-only.
• Never expose the raw port to the internet. Use a VPN (Tailscale/WireGuard) or an HTTPS reverse proxy. A plain http://your-ip:3000 on a public address is an open door.
• Fix speed at the engine, not the UI. If responses are slow, the bottleneck is the model/GPU, not Open WebUI. Ensure the model fits fully in VRAM — see the Ollama and LM Studio tuning sections.
• Use a real embedding model for RAG. The tiny default underperforms; set a proper local embedding model and your document answers improve dramatically.
• Keep a small, fast model in the mix. A speedy qwen3:8b for everyday questions plus a heavyweight for hard ones gives the best day-to-day feel; switch per chat.
• Update deliberately. Open WebUI ships often. Pin a version tag for stability, read the release notes, and back up the volume before jumping to a new major version.
• Right-size before you scale. For a household, one GPU is plenty; only reach for a multi-user throughput engine when you actually have concurrent users. Plan with the Cost Calculator.

Follow these and your instance stays fast, private, and durable. Ignore the first two and you will eventually have a bad day.

Troubleshooting {#troubleshooting}

Frequently asked questions {#faq}

Is Open WebUI free and open source?

Yes — it is open-source software you self-host at no cost. Your only expense is the hardware it runs on, which you likely already own. Compared to per-seat cloud chat subscriptions, a self-hosted instance for a household or team is dramatically cheaper over time; the Cost Calculator quantifies it and why local is cheaper and more secure makes the broader case.

Do I need Ollama to use Open WebUI?

No, but it is the easiest pairing. Open WebUI works with any OpenAI-compatible backend — LM Studio, vLLM, or a cloud API. Ollama is the most common because both are free, local, and effortless together.

Does Open WebUI keep my data private?

Yes, provided your model engine and services are local. Chats, documents, and accounts live in your instance's database on your hardware. The exceptions are things you deliberately connect to the internet — web search, or a cloud API you add. For a fully offline instance, use local models and turn web search off.

Can my whole family or team use one instance?

Yes — that is a core feature. Create accounts (approve them as admin), organize people into groups, and control which models and features each can use. One machine with one good GPU serves everyone.

Can I use it on my phone?

Yes. It is a responsive web app and a PWA, so it works in a mobile browser and can be added to your home screen. Reach it over your home network or a VPN — see run a local LLM on your phone.

How is this different from LM Studio?

LM Studio is a single-user desktop app that also runs the model. Open WebUI is a multi-user web platform that does not run models itself — it sits in front of an engine. Use LM Studio to run and explore models on one machine; use Open WebUI to give many people a polished shared interface. The three-way comparison covers it fully.

Can it do RAG, web search, images, and voice all at once?

Yes — those are all built in and can be enabled together, turning one model into a multimodal, up-to-date, document-aware assistant. Each is optional and independently toggled.

Is it suitable for a business?

Yes. Self-hosting, per-user permissions, knowledge bases, and audit-friendly deployment make it a common choice for private AI in business and on-premise AI, especially where data cannot go to the cloud.

Can I mix local and cloud models in one interface?

Yes. Register an Ollama or LM Studio backend for local models and an OpenAI-compatible cloud endpoint for hosted ones; all appear in the same dropdown. Users pick per chat — a fast free local model for routine work, a frontier cloud model for the occasional hard task. You control who can use which via permissions.

Do I need to know how to code to use Open WebUI?

No. Installation is a single copy-paste Docker command, and everything else — models, RAG, users, custom assistants — is point-and-click in the admin UI. Coding only enters the picture if you want to write custom tools or pipelines, which is entirely optional.

How much disk and RAM does Open WebUI itself need?

The app is light: a couple of GB of disk and a few GB of RAM cover it. The real resource is the GPU/VRAM used by the model engine behind it. Knowledge bases grow with the documents you add, so budget disk for your corpus and its vector index.

Can I brand it for my family or company?

Yes — set WEBUI_NAME, add a logo, and configure default models and prompts so it feels like your product. Combined with custom assistants, you can ship a polished internal tool that looks bespoke.

What happens to my chats and knowledge bases if I move machines?

Back up the open-webui Docker volume and restore it on the new host — accounts, chats, settings, and knowledge bases all come with it. Because your compose file captures the configuration, the whole stack is reproducible.

The operations cheat sheet {#cheatsheet}

Keep these handy for running and maintaining your instance day to day.

# --- Lifecycle ---
docker logs -f open-webui              # follow the app logs (great for debugging)
docker restart open-webui             # restart the app
docker stats open-webui               # live CPU/RAM usage of the container
docker exec -it open-webui bash       # open a shell inside the container

# --- Update to the latest version ---
docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui && docker rm open-webui
# ...then re-run your original `docker run` command (data survives in the volume)

# --- Back up everything (accounts, chats, knowledge bases, settings) ---
docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/owui-backup.tar.gz /data

# --- Restore from a backup ---
docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar xzf /backup/owui-backup.tar.gz -C /

# --- Check the engine behind it (Ollama) ---
ollama ps                              # what model is loaded, GPU or CPU
ollama list                            # installed models

The two commands worth building a habit around are docker logs -f open-webui (your first stop when anything misbehaves — it usually tells you exactly what is wrong, most often a connection or permission issue) and the backup command before every update. Everything else you will reach for occasionally. If you run the all-in-one image with Ollama bundled, remember the ollama volume holds your models and the open-webui volume holds your data — back up both.

Recommended stacks by budget

Open WebUI is one layer; the full experience depends on what sits under it. Here are three complete, sensible blueprints.

The starter (existing PC, ~$0 extra). Your current computer with an 8–12 GB GPU, Ollama as the engine, qwen3:8b as the model, and Open WebUI in Docker on top. Local RAG with nomic-embed-text. This costs nothing beyond electricity and delivers a private ChatGPT for one or two people. If you have no capable GPU, start on CPU with a 3–4B model or check the best GPU under $500. The home server (~$1,500–2,500). A dedicated always-on box — a mid-tower with a 24 GB RTX 4090 or a 32 GB RTX 5090, or a 64 GB Mac — running Ollama plus Open WebUI, reachable from every device over Tailscale. Run qwen3:32b or deepseek-r1:32b for near-frontier quality, add web search and a local image backend, and serve the whole household. This is the sweet spot for enthusiasts; the Personal AI Home Server guide is the blueprint and the RTX 5090 guide covers the GPU. The team / business (scales with users). A workstation or server GPU running a throughput engine like vLLM behind Open WebUI, with per-user permissions, shared knowledge bases, and an HTTPS reverse proxy or VPN. Size the GPU to concurrent users. This replaces per-seat cloud subscriptions with a one-time capital cost and total data control — the case made in the Enterprise hub and quantified in the Cost Calculator.

Whichever you choose, the beauty is that Open WebUI stays the same — only the engine and hardware underneath scale. Start small, grow when you need to, and never re-learn your interface. Use the Hardware Analyzer to see exactly which models each blueprint can run at what speed.

Where to go next

You now have a private, multi-user, feature-rich AI platform — the same experience as a commercial chat product, running on your own hardware with your data under your control. To round out the stack:

• Pick and tune your engine: the Complete Ollama Bible (scripting/servers) or Complete LM Studio Bible (GUI).
• Pick your model: the Complete Qwen Guide and Complete DeepSeek Guide.
• Pick your hardware: the Complete RTX 5090 Guide and Best GPU Buyer's Guide.
• Make it always-on: the Personal AI Home Server guide.

Open WebUI is the face of local AI. With it in place, your private assistant finally feels like a product — because now it is one.

---

Check which models your machine can run → Hardware Analyzer Browse every open model, always current → Model Library Compare self-hosting costs to cloud subscriptions → Cost Calculator