Open WebUI Self-Hosted AI Workspace and Chat Platform

Deploy 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 unless-stopped ghcr.io/open-webui/open-webui:VERSION

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine tar czf /backup/open-webui-data.tgz -C /data .

Key environment variables

OpenSourcesAI verdict

Open WebUI is one of the strongest ways to turn local or self-hosted model endpoints into a usable internal AI workspace. It is far more than an Ollama skin: the platform adds accounts, permissions, shared resources, retrieval, tools, model routing, and organization features. That added capability also creates an application and security boundary that must be operated deliberately. A Docker container running on a public port is not automatically a production-ready private AI service.

Best for

Individuals, homelabs, developer teams, schools, and organizations that already have local or hosted model endpoints and want a self-hosted browser workspace with conversations, shared models, knowledge bases, tools, permissions, and provider flexibility.

Why use it

Use Open WebUI when the model runtime is working but the people using it need a coherent product layer. It can connect one interface to Ollama, vLLM, LiteLLM, llama-server, cloud providers, and other compatible endpoints; organize models and prompts; support multiple users; and add retrieval or tools without requiring every user to operate a terminal. Its value is the workspace and governance layer, not faster inference—the connected backend still determines model quality, latency, context limits, and GPU utilization.

What Open WebUI does in the stack

Open WebUI sits above inference runtimes and model APIs. Ollama, vLLM, llama.cpp, SGLang, LiteLLM, or a cloud provider performs the actual inference; Open WebUI supplies the browser experience, user accounts, conversations, resource sharing, retrieval workflows, and administrative controls.

This separation is useful because one workspace can expose several backends without forcing users to understand each runtime. It also means a slow, undersized, misconfigured, or unreliable backend will still feel slow or unreliable through Open WebUI. Installing the interface does not pool VRAM, improve a weak model, or replace capacity planning.

For a personal workstation, Open WebUI can be a convenient local front end. For a team, it becomes an application service with persistent data, secrets, identity, permissions, backups, upgrades, and network exposure that need explicit ownership.

Authentication, roles, groups, and resource access

Open WebUI supports multi-user operation with Admin, User, and Pending system roles. Administrators can set default permissions, organize users into groups, and grant access to resources such as models, knowledge bases, tools, and skills. Resource access is private by default and can be shared with users, groups, or broader audiences.

The permission model is additive: group membership adds capabilities to a user’s baseline role. This is flexible, but it makes group design important because a user’s effective permissions are the union of grants. Administrators should review default permissions before inviting users rather than relying on interface labels alone.

Open WebUI permissions govern actions inside the workspace. They do not replace least-privilege credentials at the connected provider. A general user should not receive a LiteLLM master key, cloud-management credential, or unrestricted backend token merely because the Open WebUI role looks constrained.

Knowledge, documents, and RAG expectations

Knowledge collections can turn uploaded material into reusable retrieval context. Focused retrieval searches indexed chunks and injects selected passages, while full-context approaches place more of the source directly into the model context. The correct mode depends on document size, model context, accuracy requirements, and whether the task needs broad synthesis or precise retrieval.

RAG quality depends on extraction, chunking, embeddings, vector storage, retrieval settings, reranking, source quality, and the model’s ability to use evidence. A successful upload is not proof that answers are complete or grounded. Teams should build a small question set with known answers and inspect citations, omissions, and permission boundaries.

Uploaded documents, extracted text, embeddings, conversations, and generated answers become part of the application’s data estate. Backup, deletion, retention, and access policies should cover these artifacts rather than focusing only on the original files.

Tools, extensions, and code-execution risk

Open WebUI tools and extensions can call APIs, search the web, transform content, or execute Python inside the application process. That power can turn the workspace into an agent platform, but it also expands the trust boundary from prompts and model endpoints to third-party code and external services.

Administrators should treat community tools, pipelines, functions, skills, and MCP-connected capabilities as software dependencies. Review the source, permissions, network access, secret handling, maintenance status, and expected outputs before making an extension available to users.

Model-generated tool arguments and retrieved web content are untrusted inputs. Approval gates, scoped credentials, allowlists, logging, and sandboxing remain necessary when a tool can write data, run commands, send messages, or affect production systems.

Deployment, persistence, backups, and upgrades

Docker is the normal deployment path because it isolates dependencies and makes persistent storage explicit. The application data volume must survive container replacement. Production deployments should pin a tested image version or digest rather than following the moving main tag automatically.

Backups should include the application database, uploaded files, knowledge data, configuration, secrets, and any external database or vector-store state required to restore the same workspace. A container image is replaceable; the persistent volume is not.

Before upgrades, read release notes, take a restorable backup, test migrations on a non-production copy, and verify authentication, model connections, knowledge retrieval, tools, and user permissions. Teams scaling beyond one process may need an external database, shared storage, Redis, and a load-balancing design rather than simply increasing container replicas.

License and branding status

Open WebUI is self-hostable and its source is available, but current releases are not accurately described by a single BSD-3-Clause label. Code through version 0.6.5 remains under BSD-3-Clause, while version 0.6.6 and later introduced the Open WebUI License with a branding-preservation clause and defined rebranding exceptions, including provisions for smaller internal deployments.

Organizations redistributing, embedding, white-labeling, or materially rebranding current Open WebUI releases should review the official license and license notice rather than relying on an old directory badge. Internal use and commercial redistribution are different legal and operational questions.

How Open WebUI compares with alternatives

AnythingLLM is often a stronger fit when document workspaces and guided knowledge workflows are the center of the product. LibreChat is a strong option for a multi-provider assistant interface with a different configuration and data stack. LobeChat emphasizes a polished modern interface and plugin ecosystem.

Ollama, llama.cpp, and vLLM are inference runtimes rather than substitutes for the full workspace. LiteLLM is a gateway and policy layer, not a chat product. A common architecture is Open WebUI for users, LiteLLM for provider routing and keys, and a runtime such as vLLM or Ollama behind the gateway.

Key features

• Multi-provider chat workspace for Ollama, OpenAI-compatible endpoints, OpenAI Responses-compatible services, and configurable external model providers.
• Multi-user authentication with Admin, User, and Pending roles, groups, granular permissions, and per-resource access controls for models, knowledge, tools, and skills.
• Knowledge and RAG workflows with document ingestion, focused retrieval or full-context modes, configurable extraction and vector storage, citations, and shared collections.
• Workspace resources including model presets, prompts, skills, tools, functions, and access-controlled sharing across users and groups.
• Extensibility through Python tools, web search, MCP-related integrations, pipelines, and external APIs—with meaningful code-execution and supply-chain risk.
• Self-hosted deployment through Docker or Python packaging, with support for persistent storage, external databases, Redis-backed scale-out patterns, SSO, LDAP, OIDC, and SCIM in applicable configurations.

Common AI use cases

• Provide a ChatGPT-style interface for local Ollama models on a workstation or LAN server.
• Give a team one browser workspace across local models, self-hosted inference servers, and approved cloud providers.
• Create shared model presets, prompts, skills, and knowledge collections with controlled access.
• Build a private document-assistant workflow with uploaded files, retrieval, and citations.
• Expose internal tools or approved external APIs through a governed assistant interface.
• Add SSO, groups, and resource permissions to an internal AI workspace.

Business use cases

• Internal AI assistant portal for engineering, operations, support, research, or knowledge work.
• Private model-evaluation workspace before a team commits to one provider or runtime.
• Shared front end for an organization-operated model gateway such as LiteLLM.
• Self-hosted knowledge and document assistant for material that should remain inside approved infrastructure.
• Controlled pilot environment for tools and agent workflows before building a custom product.

How AI builders can use it

• Validate the model endpoint independently before adding Open WebUI so runtime and interface failures can be separated.
• Deploy with persistent storage, a fixed secret key, authentication enabled, and localhost or private-network exposure first.
• Create one non-admin test user and verify default permissions before onboarding a group.
• Add one knowledge collection and evaluate retrieval with known-answer questions before importing a large document library.
• Review and approve tools individually; do not install community extensions in bulk.
• Document backup, restore, upgrade, provider-key, and incident-response ownership before broader rollout.

Who should use it

• Self-hosters who already have Ollama or another compatible model endpoint.
• Teams that need a shared browser workspace instead of terminal-only model access.
• Organizations willing to operate authentication, persistent data, permissions, backups, and upgrades.
• Builders who want provider flexibility without building a custom chat application immediately.
• Teams experimenting with knowledge, web search, tools, and shared AI resources in a controlled environment.

Who should not use it

• Users who only need a simple single-user desktop chat application.
• Teams expecting the interface to solve model quality, GPU capacity, or inference scaling automatically.
• Organizations unwilling to manage application data, authentication, secrets, backups, and security updates.
• Public internet deployments without a reverse proxy, TLS, access controls, rate limits, and monitoring.
• Teams that need a fully permissive white-label license without reviewing current branding terms.

Evaluation checklist

• Which inference backends and provider credentials will the workspace expose?
• Will the deployment be personal, LAN-only, private-cloud, or internet-accessible?
• Which users, groups, and resources should be available by default?
• Where will conversations, uploads, extracted text, embeddings, and knowledge data be stored?
• Which database, vector store, Redis, and shared-storage components are required at the intended scale?
• How will backups be tested and how quickly can the workspace be restored?
• Which tools, web-search providers, and external APIs are trusted?
• Does the current Open WebUI license permit the intended branding, redistribution, and commercial use?
• What functional and permission tests must pass before every upgrade?

Security and admin notes

• Keep authentication enabled for every shared deployment and use a strong, persistent application secret.
• Do not expose the container port directly to the public internet; use TLS, a reverse proxy, firewall controls, rate limits, and monitoring.
• Use provider credentials scoped for inference rather than backend administration or cloud account management.
• Review group grants and default permissions because permissions accumulate across roles and groups.
• Treat tools, functions, pipelines, skills, and third-party extensions as executable dependencies.
• Back up and protect the database, uploads, knowledge data, and secrets; deleting a container is not a data-erasure strategy.
• Pin tested image versions and verify migrations, permissions, integrations, and retrieval after upgrades.

Pricing notes

Open WebUI can be self-hosted without per-seat SaaS fees, but operating cost includes compute, storage, databases, backups, identity integration, monitoring, upgrades, and administration. Current licensing also includes branding provisions that should be reviewed for white-label or larger commercial deployments.

Tradeoffs

Open WebUI delivers an unusually complete self-hosted workspace, but completeness increases the operational and security surface. Retrieval requires evaluation, extensions require code review, multi-user deployments require permission design, and scale-out requires more than one Docker command. The platform is an excellent product layer over a well-run model stack and a poor substitute for operating that stack responsibly.

Recommended workflow

• Start on a private network with one validated model endpoint and persistent storage.
• Configure authentication, a non-admin test account, and conservative default permissions.
• Test conversations, uploads, retrieval, citations, and deletion behavior with non-sensitive sample data.
• Add users and shared resources gradually, then review effective permissions.
• Introduce tools only after source, credentials, and failure behavior are reviewed.
• Create and test a backup-and-restore procedure before the instance becomes important.
• Pin releases and validate upgrades in a staging copy.

Pros

• Polished self-hosted browser experience across local and hosted model backends.
• Strong multi-user, group, permission, and resource-sharing capabilities.
• Integrated knowledge, retrieval, prompts, tools, and workspace resources.
• Works with Ollama and a broad range of OpenAI-compatible services.
• Can grow from a personal setup into an internal team platform.

Cons

• Operational complexity rises quickly beyond a personal instance.
• Community extensions and in-process tools create meaningful execution risk.
• RAG quality is not automatic and requires evaluation and maintenance.
• Current licensing includes branding restrictions that older BSD-only descriptions miss.
• The interface does not improve weak models or undersized inference infrastructure.

Alternatives

• AnythingLLM may be better when document workspaces and guided RAG are the primary use case.
• LibreChat may be better for teams prioritizing a broad multi-provider assistant interface with its own deployment model.
• LobeChat may be better when interface polish and a web-oriented plugin ecosystem are the leading priorities.
• Ollama may be better for a single technical user who only needs a direct local client.
• llama.cpp may be better for a single technical user working close to the runtime.

FAQ