Guide · 2026-07-19

How to Self-Host OpenWebUI in Docker — 5-Minute Setup

Last updated 2026-07-19

One Docker command, ~90 seconds, and you have a private ChatGPT-style interface for every local model you run. Here is the exact setup, plus the production hardening the quick guides skip.

By Mohamed Meguedmi · 8 min read

Why Open WebUI Is the Default Local Chat Front-End

Open WebUI has become the de facto interface for people running models on their own hardware, and the reason is boring in the best way: it just connects. It speaks native Ollama, the OpenAI-compatible /v1 spec, and Open Responses providers out of the box, so a single instance can front Ollama on one port, a vLLM server on another, and a remote API key all at once. Per the official Open WebUI documentation, the project's stated goal is "zero to your first AI conversation in under five minutes" — and unlike most marketing promises, that number holds on a warm Docker host.

The value proposition is simple. You get multi-user accounts, per-conversation model switching, RAG document upload, prompt libraries, and a mobile-friendly PWA — all self-hosted, all offline-capable, all yours. No data leaves your network unless you point it at a remote provider. For teams that want a private ChatGPT clone without a SaaS bill or a compliance review, this is the shortest route there is.

If you are still choosing which models to serve behind it, our model catalog and benchmark tables break down throughput and quality by hardware tier. This guide assumes you already have a backend in mind and focuses purely on standing up the interface.

Prerequisites — Before the 5-Minute Clock Starts

The clock only reads five minutes if these are already in place. None of them take long, but a missing Docker daemon is the most common reason a "quick" setup turns into an hour.

Requirement	Minimum	Notes
Docker Engine	24.0+	Docker Desktop on macOS/Windows, or native Engine on Linux.
Free RAM (UI only)	1 GB	Container idles at ~0.5 GB; the model backend needs far more.
Free disk	3 GB	Image is ~3.6 GB compressed on first pull; volume grows with chats/RAG data.
Open port	3000	Remap the host side if 3000 is taken (e.g. 8080:8080).
Inference backend	Optional at install	Ollama, vLLM, or any OpenAI-compatible URL + key. Can be added in the UI later.

Confirm Docker is alive before anything else:

docker --version
docker info

If docker info errors out, start the daemon (or Docker Desktop) first. Everything below assumes it returns cleanly.

The 5-Minute Install

There are two paths. Use the single command to test in 90 seconds; use Compose for anything you intend to keep.

Option A — One-Line Docker Run (fastest test)

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

Flag by flag, because these details are exactly what the throwaway guides gloss over:

• -d runs detached, so the container survives closing your terminal.
• -p 3000:8080 maps host port 3000 to the container's internal 8080. The app always listens on 8080 inside; only the left number is yours to change.
• -v open-webui:/app/backend/data is the line that saves your data. This named volume holds the SQLite database, uploaded files, and every account. Omit it and you start from scratch on every update.
• --restart always brings the container back after a reboot or crash.
• ghcr.io/open-webui/open-webui:main is the stable multi-arch image (amd64 + arm64) from the official GitHub repository.

Wait for the container to report healthy, then open http://localhost:3000. The first account you create becomes the admin — there is no default password, and that first sign-up is a one-time window, so do it immediately.

Option B — Docker Compose (recommended for keeps)

Drop this into docker-compose.yml:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data
    environment:
      - WEBUI_AUTH=True
    restart: always

volumes:
  open-webui:

Then:

docker compose up -d

Compose wins for one reason above all: reproducibility. Your entire configuration lives in a file you can commit to version control, diff, and redeploy identically on another host. When you later pin a specific version instead of :main, it is a one-line change with an audit trail.

Connecting a Model — Ollama vs OpenAI-Compatible

An empty Open WebUI is a chat box with nothing to say. Point it at a backend under Settings → Admin → Connections.

Ollama on the same host. If Ollama runs on your Docker host, the container cannot reach it via localhost — that resolves to the container itself. Use http://host.docker.internal:11434 on macOS and Windows. On Linux, either add --add-host=host.docker.internal:host-gateway to your run command or use the host's LAN IP. This one networking detail is responsible for the majority of "Open WebUI can't see my models" support threads.

OpenAI-compatible endpoints. For vLLM, LM Studio, or a remote provider, add the base URL (ending in /v1) and an API key. Open WebUI auto-discovers the served model list. The Ollama project and most local servers expose this spec, so the same connection form covers nearly every backend you will meet.

Once connected, pick a model from the top-of-chat dropdown and send a message. First token on a warm 7B–8B model at Q4_K_M typically arrives in well under a second on a modern GPU; the UI adds no measurable latency of its own.

Hardware & Resource Footprint

A recurring myth is that Open WebUI is "heavy." It is not — the interface is a thin Python/Svelte app. Your RAM and VRAM budget is dominated entirely by the model you load, not by the front-end. The table below separates the two so you can size a host honestly.

Component	RAM	VRAM	Disk	Role
Open WebUI container (idle)	~0.5 GB	0	3.6 GB image	UI, auth, RAG index, DB
Open WebUI (active, RAG on)	~1–1.5 GB	0	+ volume growth	Embedding + document store
Llama 3.1 8B Q4_K_M backend	~1 GB host	~6 GB	4.9 GB weights	Inference
Qwen3-Coder 32B Q4_K_M backend	~2 GB host	~20 GB	~19 GB weights	Inference

The takeaway: budget for the model, treat the UI as rounding error. A host that can serve a 32B model at Q4_K_M will not notice Open WebUI running alongside it. For quantization sizing across model families, the Hugging Face GGUF documentation is the authoritative reference on how each Q level trades disk and VRAM for quality.

Production Hardening — What the Quick Guides Skip

A 5-minute install is a demo, not a deployment. Four changes turn it into something you can trust on a network.

1. Pin the image version

The :main tag moves. For anything persistent, pin an explicit release (for example ghcr.io/open-webui/open-webui:v0.6.5) so a background pull never ships you a breaking change unannounced. Upgrade deliberately, read the changelog, then bump the tag.

2. Put HTTPS in front of it

Open WebUI serves plain HTTP. Never expose port 3000 to the internet directly. Terminate TLS at a reverse proxy — Caddy is the lowest-effort option because it fetches and renews Let's Encrypt certificates automatically. A three-line Caddyfile (your.domain { reverse_proxy localhost:3000 }) is enough for a valid HTTPS front door.

3. Lock down sign-up

After creating your admin account, set ENABLE_SIGNUP=False so the world cannot register on an exposed instance. Keep WEBUI_AUTH=True at all times outside a throwaway local test.

4. Back up the volume

Everything lives in the named volume. Snapshot it on a schedule:

docker run --rm -v open-webui:/data -v $(pwd):/backup \
  alpine tar czf /backup/openwebui-backup.tar.gz -C /data .

Store that archive off-host. It is the difference between a five-minute restore and rebuilding every account and chat by hand.

Common Pitfalls & Fixes

• Data gone after update: the volume flag was missing. Always include -v open-webui:/app/backend/data.
• Blank model dropdown: the backend URL is unreachable from inside the container. Use host.docker.internal, not localhost, for host-side services.
• Port already in use: another service holds 3000. Remap the host side, e.g. -p 8090:8080.
• Slow first response: that is the model cold-loading into VRAM, not the UI. Subsequent requests are fast once weights are resident.
• Can't create an account: the first sign-up already happened, or WEBUI_AUTH is misconfigured. Reset via the admin panel or a fresh volume.

Integrating BestLLMfor Data

Once your instance is live, you can feed it live model intelligence. The free BestLLMfor public API (licensed CC BY 4.0) exposes our benchmark and hardware-fit data as JSON, and our open-source MCP server lets a model query it as a tool directly inside Open WebUI — so "which local model fits 12 GB of VRAM?" gets answered with current numbers rather than a guess. To estimate the running cost of any configuration before you commit hardware, our cost calculator covers electricity, amortization, and cloud-equivalent pricing.

The Verdict

For getting a private, multi-model chat interface running on your own Docker host, nothing beats Open WebUI on install speed or backend flexibility. Use the one-liner to prove it works in 90 seconds, then move to Compose the moment you decide to keep it — and never skip the volume mount.

Approach	Setup time	Persistence	Best for	Verdict
docker run one-liner	~90 sec	Yes, if volume mounted	First test, demos	Start here
Docker Compose	~3 min	Yes	Anything you keep	Recommended
Compose + Caddy + pinned tag	~10 min	Yes + backups	Team / networked use	Production pick

The install is genuinely a five-minute job. The extra ten minutes of hardening — pinning, HTTPS, sign-up lockdown, and a volume backup — is what separates a demo from a deployment you can rely on. Browse the full guides hub for the model-serving companion setups that pair with this front-end.