Open WebUI

Self-hosted ChatGPT-style web frontend for local LLMs — point it at Ollama, llama.cpp's HTTP server, or any OpenAI-compatible API and get a polished chat surface running on `localhost` (or your private LAN, or your own VPS). Listed at Grade A because Open WebUI is the canonical end-user UI atop the local-LLM stack we already grade A (Ollama, llama.cpp). MIT-licensed, no telemetry, no third-party JS, no account anywhere in the install or use flow, and the entire client+server runs on hardware you own. For non-developers who want OpenAI / Claude UX without an OpenAI / Claude account or any third party seeing their prompts, this is the answer.

What it is. Open WebUI is a Svelte+Python web application (self-host via Docker, pip, or source) that renders a familiar threaded-chat interface over any OpenAI-compatible LLM backend. Out of the box it auto-discovers Ollama on `localhost:11434` and shows every model you have pulled. You can also point it at a remote OpenAI / Anthropic / Mistral / Together / OpenRouter endpoint via API key (Bring Your Own Key / BYOK pattern), or stack multiple backends in the same UI and pick per-conversation.

Where Ollama is the engine + CLI, Open WebUI is the user-facing interface — the part your non-developer family member, journalist colleague, or operations team actually touches. Threaded conversation history, model switching mid-conversation, system prompts, file uploads (with local RAG via `chromadb`), image input (vision models), code execution sandbox, multiple users + role permissions, conversation export, share-link generation, and a dozen-or-so settings the typical user actually configures.

Background. Started in 2023 by Timothy Jaeryang Baek as "Ollama WebUI" — initially purely a frontend for the Ollama server. Renamed to Open WebUI in March 2024 when scope expanded beyond Ollama to include any OpenAI-compatible endpoint and Open WebUI's own pipelines (custom-Python extension layer for RAG, agents, and tool use). 60k+ GitHub stars, ~400 contributors, active weekly releases.

The project is MIT-licensed with the codebase at `github.com/open-webui/open-webui`. Open WebUI Inc. (a US C-corp) provides commercial support + an Enterprise tier (SSO, audit logs, multi-tenancy) — but the open-source build covers ~95% of use cases and is feature-complete enough that most self-hosters never need the enterprise version.

What you trust.

• No account, no signup, no SaaS layer. You install Open WebUI as software on your hardware. There is no "Open WebUI account" — when you first launch, you create a local admin user (username + password) which lives in your own SQLite / Postgres database. Optional: turn signup off entirely after the first admin so no one else can register.
• No third-party network calls during use. Once Open WebUI is running and pointed at a local backend (Ollama / llama-server), generation runs entirely locally; the frontend talks only to your configured backend. No analytics, no CDN-dependent assets, no telemetry to Open WebUI's servers.
• MIT-licensed open source. Codebase at `github.com/open-webui/open-webui` is fully auditable. Build from source if you don't trust the published Docker images.
• Multi-backend support. Ollama (native), llama.cpp's `llama-server`, vLLM, LM Studio, any OpenAI-compatible endpoint. Each backend is configured separately and can be enabled/disabled per-user. No vendor lock to a single LLM source.
• Local RAG via `chromadb`. File upload + retrieval happens on the same machine — your documents stay on disk, embeddings are generated by a local embedding model (e.g. `nomic-embed-text` via Ollama), and search is local vector lookup. No third-party RAG-as-a-service path.
• Image generation, voice, tool use all opt-in via Pipelines (separate Python container you self-host) or built-in integrations. Each integration documents what hits the network and why.
• OAuth + LDAP available for the enterprise case (Active Directory shop deploying internally), but disabled by default — you can run the whole thing username+password+local-DB.

Operational specs.

• Install — easiest path: `docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main`. Web UI at `http://localhost:3000`. Alternative: `pip install open-webui && open-webui serve`.
• Hardware — minimal for the UI itself (the heavy lifting is the backend LLM, not Open WebUI). ~512 MB RAM, ~1 GB disk for the app + a few users' conversation history. Scales to multi-user shared deployments on a small VPS (4 GB RAM, 2 vCPU comfortable).
• Backends supported — Ollama (native auto-discovery), llama.cpp `llama-server`, vLLM, LM Studio, OpenAI, Anthropic Claude, Google Gemini, Mistral, Together, OpenRouter, any OpenAI-API-compatible endpoint.
• Pipelines — Open WebUI's extension layer for custom Python integrations (RAG, agents, function calling, custom auth). Runs as a separate Docker container that Open WebUI talks to over the network. Adds ~256 MB RAM + dependencies.
• Database — SQLite by default (single-file, lives in the Docker volume), Postgres / MariaDB optional for multi-user deployments. Migrations handled by Open WebUI on startup.
• Auth — local username+password (default), OAuth (GitHub / Google / Microsoft / generic OIDC), LDAP / Active Directory. Anonymous chat possible if `WEBUI_AUTH=False` (single-tenant trust-the-LAN deployments).
• Conversation export — JSON, Markdown, or shareable link (with privacy gate). Imports from ChatGPT export, Anthropic export, LibreChat export.
• Update path — `docker pull ghcr.io/open-webui/open-webui:main && docker restart open-webui`. Migrations automatic; rare breaking changes flagged in release notes.

Operator philosophy. Timothy Baek's framing in conference talks and the project README is "self-hosted means self-hosted — no compromise on the local-first promise." Open WebUI deliberately doesn't ship a hosted-SaaS option (unlike most "self-hostable" tools that prioritize their hosted tier and treat self-host as a degraded variant). The Enterprise tier is for organisations that need SSO and audit; the open-source build IS the canonical product for individuals + small teams. The MIT-licensed Pipelines mechanism keeps Open WebUI's plugin model permissive — no plugin marketplace requiring approval, no AGPL viral surface, you write Python and drop it in.

Grade rationale. Grade A reflects: strongest privacy posture available for a hosted chat UI (everything runs on your hardware, no third-party network calls during use, no account anywhere), open-source under permissive MIT licence (forkable + auditable), named-operator accountability without operator dependency (Timothy Baek + Open WebUI Inc. publicly identified, but the runtime keeps working if either disappears — switching to LibreChat or building a custom Svelte UI from scratch is a weekend project for an experienced developer), broad backend support (every consumer LLM API + every local engine), multi-user + role-based access for shared-deployment cases, kycnot.me-class no-account posture (literally no account because there's no operator to register with), active maintenance (weekly releases, ~400 contributors), and no major incident in `r/selfhosted` / `r/LocalLLaMA` / GitHub issues in the last 12 months. Last verified 2026-05-27.

Useful when:

• You want a ChatGPT-quality UI for your local Ollama / llama.cpp install and don't want to use ChatGPT.
• You want a shared chat surface for your team / family that uses a single LLM backend you control.
• You're a journalist / researcher / activist whose prompts cannot be seen by any third party — local Ollama + Open WebUI is the canonical answer.
• You're deploying LLM access for a small organisation on an internal VPN — multi-user + OAuth + audit support it.
• You want to BYOK an OpenAI / Anthropic / Mistral key without giving those vendors a vendor-supplied chat surface (slight gain — the upstream still sees the prompt, but you control the client + history + export).
• You're building a custom RAG pipeline and want a polished chat UI on top of a Python backend you wrote yourself (Pipelines extension layer).

Caveats:

• You self-host, you self-operate. Open WebUI doesn't run itself — you set up Docker, you configure the backend, you keep updates current, you back up the database. For non-technical users, this is real work.
• The privacy guarantee is yours to enforce. Open WebUI talks to whatever backend you point it at. Pointing it at OpenAI gives OpenAI your prompts — Open WebUI itself stays neutral; it's the backend that determines who sees your data.
• Pipelines runs separate containers — if you use the extension layer, you have a second service to maintain + monitor. The default install (no Pipelines) is single-container and effortless to deploy.
• Initial setup has a learning curve. The Docker run command above works but doesn't optimise for production. For shared deployments, you want a reverse proxy (Caddy / Traefik), HTTPS, backups, log rotation, auth-tightening. Documented in the wiki but not click-through.
• No mobile app — Open WebUI is responsive in mobile browsers but there's no native iOS / Android client. The PWA mode works decently as a substitute.
• Some integrations require additional services: image generation needs ComfyUI / AUTOMATIC1111, voice needs Whisper.cpp or a TTS engine, RAG needs an embedding model. Each is a separate self-host step. Documented but not automatic.
• Update breakage rare but possible. Weekly releases occasionally introduce schema migrations that require care for users running customised databases. Pin a release tag and re-test before bumping on production deployments.
• Enterprise features (SSO with arbitrary IdPs, advanced audit, multi-tenancy) are paid. Most individuals + small teams never need these, but if you're deploying for a 100-person engineering org, the Enterprise tier exists.