Self Hosted ChatGPT: Install Open WebUI v0.11.0 Guide

Here’s the take nobody puts in the title: Open WebUI isn’t a self-hosted ChatGPT. It’s a chat-shaped orchestrator that looks like ChatGPT because that’s the interface people already know. The models, the vector store, the tool servers – those are separate processes. Understand that split and every install error stops being mysterious.

This guide walks through deploying Open WebUI v0.11.0 (released July 27, 2026, rebuilt interface from scratch) via Docker, then wires it to Ollama for local models. Focus is on the parts that actually break – not the happy-path one-liner every other tutorial copies from the README. The docs say one thing; the GitHub issue tracker tells a different story.

What you actually need on the box

The RAM number floating around every tutorial – 16GB minimum – is Ollama’s requirement, not Open WebUI’s. The container itself? Under 1GB RAM. Cloudron operators running it in production confirmed this. Your hardware budget is entirely about which model you load underneath it.

Docker Desktop or Docker Engine is the assumed prerequisite. Everything below runs against ghcr.io/open-webui/open-webui:main from the GitHub Container Registry.

Install Open WebUI v0.11.0 (Docker path)

This is the canonical form from the project’s own docs, assuming Ollama is already running on the same host:

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

-p 3000:8080 maps the container’s internal port to your host’s 3000. The --add-host flag – omit it and you get the classic connection refused loop when trying to reach Ollama on the host. The named volume open-webui is where chat history, users, and settings live.

Pointing at a remote Ollama server? Swap the add-host flag for an env var:

docker run -d -p 3000:8080 
 -e OLLAMA_BASE_URL=https://ollama.example.com 
 -v open-webui:/app/backend/data 
 --name open-webui --restart always 
 ghcr.io/open-webui/open-webui:main

No Docker? pip install open-webui then open-webui serve works, defaulting to port 8080. Fine if you like Python version roulette.

First boot

Open http://localhost:3000. The first account registered becomes the admin – no root password, no .env secret. Whoever signs up first owns the instance. On a public VPS this is a race condition you want to lose only to yourself.

Head to Settings → Admin Settings → Connections. Ollama usually shows up already at http://host.docker.internal:11434. Drop any OpenAI, OpenRouter, Groq, or Mistral key here – Open WebUI treats them as OpenAI-compatible endpoints and mixes everything into the same model dropdown. One interface, multiple backends.

Watch out: Disable public signup immediately (Admin Settings → General → Enable New Sign Ups off). Every tutorial ends here. Every self-hosted instance exposed on the open internet without this toggle gets enumerated by a scanner within a week.

That separation – frontend here, model there, tool servers somewhere else – is actually what makes this interesting as a concept. You’re not installing an AI. You’re installing a router for AI calls, with a chat skin on top. Whether that’s liberating or just more plumbing to maintain depends entirely on how many models you actually plan to run.

Verify it works

docker ps --filter name=open-webui
docker logs open-webui --tail 50
curl -s http://localhost:3000/health
# expected: {"status":true}

If docker logs shows Reqwest errors mentioning transfer.xethub.hf.co – that’s the hf.co problem, covered next. If the health endpoint returns but the browser page is blank, your reverse proxy is probably stripping WebSocket upgrade headers.

The install errors real users actually hit

Lifted from open GitHub issues, not invented failure modes.

• Container hangs on startup, no internet. Turns out the image phones home to Hugging Face on first boot – it fetches sentence-transformers/all-MiniLM-L6-v2 for RAG embeddings. If hf.co is blocked (corporate firewalls, certain regions) or the box is offline, it never becomes healthy. Documented in issue #18914 and discussion #19857. Fix: add -e OFFLINE_MODE=1 to the docker run, or use ghcr.io/open-webui/open-webui:main-slim which skips the embedded model download (per community workarounds).
• Tool server validation fails but curl works. The catch: Open WebUI rewrites the hostname to host.docker.internal in logs, even when you’ve specified an internal Docker network address. Red Failed to connect banner in the UI, curl inside the container succeeds fine. Documented in issue #12313. Workaround: use the container’s IP directly, or expose the tool server on the host and reach it via host.docker.internal.
• 500 Internal Server Error on /health after compose up. Usually a permissions problem on a bind-mounted ./data directory. Switch to a Docker named volume (open-webui:/app/backend/data) instead of a host path.
• Image pull is huge. The :cuda and :ollama tagged images bundle GPU drivers and full Ollama binaries. Use the plain :main or :main-slim tag unless you specifically need bundled CUDA.

Upgrades: read this before you pull latest

The 0.10 release ran a database schema migration. Once you’re past it, you cannot roll back – the v0.11.0 release notes reiterate this, and the Umbrel changelog spells it out plainly. Most upgrade tutorials skip this entirely.

Back up first. That’s not optional:

# 1. Back up the volume
docker run --rm -v open-webui:/data -v $(pwd):/backup 
 alpine tar czf /backup/openwebui-backup-$(date +%F).tar.gz /data

# 2. Pull and restart
docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui && docker rm open-webui
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

To uninstall cleanly: docker stop open-webui && docker rm open-webui && docker volume rm open-webui. That last command wipes users, chats, and settings – there’s no recovery after.

FAQ

Is Open WebUI actually a ChatGPT clone?

No. It’s a frontend that routes chat requests to whatever model backend you configure. The UX borrows from ChatGPT; the architecture doesn’t.

Can I run it without Ollama?

Yes – configure only an OpenAI-compatible endpoint in Admin Settings: an OpenAI key, OpenRouter, Groq, Mistral, or a self-hosted LM Studio server. In that mode you’re using Open WebUI for the chat UI, RAG pipeline, and user management, but prompts still travel to wherever the model lives. So this is a workflow choice, not a privacy guarantee. If privacy is the reason you’re self-hosting, Ollama (or another fully local backend) needs to be in the stack.

Why is my install slow on a beefy VPS?

Model inference speed has nothing to do with Open WebUI. A server running a 13B model purely on CPU will feel unusable – community operators have reported exactly this. Pick a smaller model (a 3B-class model like Llama 3.2 3B is a reasonable smoke-test starting point), add a GPU, or route to a cloud API. The frontend is not the bottleneck; it never was.

Next: pull one small model to smoke-test – docker exec -it ollama ollama pull llama3.2:3b – then send your first prompt through the UI. If the response streams, the stack is wired correctly and you can start adding tool servers, agents, or a knowledge base.