b3f50da36c
Closes #26662. `start.sh` cd's to its own directory before generating `.webui_secret_key`, so in a container the key lands in `/app/backend` -- an image layer -- rather than on the volume mounted at `/app/backend/data`. Two consequences: 1. The key does not survive a container recreate. Three recreates against a named volume produce three different keys, so every issued JWT stops validating and everyone is signed out. 2. `/app/backend` is not writable when the container runs as a non-root or arbitrary UID -- OpenShift's restricted SCC, `docker run --user`, a read-only rootfs. `set -euo pipefail` turns the failed redirect into an aborted boot: No WEBUI_SECRET_KEY environment variable set, loading from file. Generating new WEBUI_SECRET_KEY... start.sh: line 46: .webui_secret_key: Permission denied The path is now resolved in order: `WEBUI_SECRET_KEY_FILE`, then an existing non-empty `./.webui_secret_key` so installs that already have one keep it, then `DATA_DIR`. Existing keys are preserved. Two smaller behaviour changes ride along: `WEBUI_SECRET_KEY_FILE` may point at a nested path, whose parents are now created, and the `.dockerignore` entry means a custom image that had baked in a stray key stops shipping it -- that deployment generates a fresh one once and signs its users out. Regeneration triggers on missing-or-empty (`! -s`) rather than absent (`! -f`). An empty key is reachable -- an interrupted write leaves one -- and used to be self-correcting only because the file was ephemeral; on a volume it persists and is loaded as an empty string on every later boot, failing at `env.py` with "WEBUI_SECRET_KEY is not set" and pointing the operator at a variable they never set. Deliberately not `! -r`: a key we cannot read may be a good one owned by another UID or group, and `WEBUI_SECRET_KEY` is the default for `OAUTH_CLIENT_INFO_ENCRYPTION_KEY`, `OAUTH_SESSION_TOKEN_ENCRYPTION_KEY` and valve encryption, so replacing it would make data already at rest undecryptable rather than merely signing people out. `-s` needs no read permission, so that case falls through to the `cat` and aborts loudly, as it does today. For the same reason the legacy arm tests `-e`, not `-r`. The write goes to a temp file and is renamed -- only ever when the target is missing or empty, so it cannot land on a key worth keeping -- with a trap so an interrupted boot leaves no stray key material, and a symlink is resolved first so an operator's indirection is written through rather than replaced. Mode is 0640 rather than the inherited umask: the key now lives on a volume that may be remounted under a different arbitrary UID -- a PVC restored into another namespace gets a new one from `sa.scc.uid-range` -- and group 0 is the part OpenShift keeps stable. 0600 would tie the key to a UID and break exactly the recovery this is meant to enable. This does require a writable `DATA_DIR` earlier than before, at the point the key is generated. In practice the app already needs one: with `DATA_DIR` read-only, stock dies creating `cache/audio/speech`, and with every cache subdirectory pre-created it dies in chromadb, since `VECTOR_DB` defaults to `chroma` and persists there. I could not construct a stock boot that survived a read-only `DATA_DIR`, but I have not proved none exists -- a deployment that externalises the database, the storage provider and the vector DB might, and would now fail earlier and more clearly. Verified in-container as `--user 1002720000:0` against stock v0.11.0; the full matrix is in the PR body. Two limits I have not addressed: `DATA_DIR` is read from the environment only, so a value set solely in `backend/.env` is invisible here, and two replicas racing on a shared volume at first boot can still settle on different keys -- the rename makes each write atomic but elects no winner. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .github | ||
| backend | ||
| docs | ||
| scripts | ||
| src | ||
| static | ||
| test/test_files/image_gen | ||
| .dockerignore | ||
| .env.example | ||
| .eslintignore | ||
| .eslintrc.cjs | ||
| .gitattributes | ||
| .gitignore | ||
| .npmrc | ||
| .pre-commit-config.yaml | ||
| .prettierignore | ||
| .prettierrc | ||
| banner.png | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| contribution_stats.py | ||
| CONTRIBUTOR_LICENSE_AGREEMENT | ||
| demo.png | ||
| docker-cleanup.sh | ||
| docker-compose-launcher.sh | ||
| docker-compose.a1111-test.yaml | ||
| docker-compose.amdgpu.yaml | ||
| docker-compose.api.yaml | ||
| docker-compose.data.yaml | ||
| docker-compose.gpu.yaml | ||
| docker-compose.otel.yaml | ||
| docker-compose.playwright.yaml | ||
| docker-compose.yaml | ||
| docker-ollama.sh | ||
| docker-run.sh | ||
| docker-update-models.sh | ||
| Dockerfile | ||
| hatch_build.py | ||
| i18next-parser.config.ts | ||
| LICENSE | ||
| LICENSE_HISTORY | ||
| LICENSE_NOTICE | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| postcss.config.js | ||
| pyproject.toml | ||
| README.md | ||
| svelte.config.js | ||
| tailwind.config.js | ||
| TROUBLESHOOTING.md | ||
| tsconfig.json | ||
| uv.lock | ||
| vite.config.ts | ||
Open WebUI 👋
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform designed to operate entirely offline. It supports various LLM runners like Ollama and OpenAI-compatible APIs, with built-in inference engine for RAG, making it a powerful AI deployment solution.
Passionate about open-source AI? Join our team →
Tip
Looking for an Enterprise Plan? – Speak with Our Sales Team Today!
Get enhanced capabilities, including custom theming and branding, Service Level Agreement (SLA) support, Long-Term Support (LTS) versions, and more!
For more information, be sure to check out our Open WebUI Documentation.
Key Features of Open WebUI ⭐
-
🚀 Effortless Setup: Install seamlessly via pip, uv, Docker, or Kubernetes (kubectl, kustomize, or helm), with
:ollamaand:cudatagged images available for container deployments. -
🤝 Broad Model & API Integration: Connect any OpenAI-compatible API alongside local Ollama models. Point the API URL at LMStudio, GroqCloud, Mistral, OpenRouter, vLLM, and more to mix and match providers freely.
-
🔐 Granular RBAC & User Groups: Administrators define detailed roles, groups, and permissions, giving each user exactly the access they need. Secure by default, with tailored experiences per group.
-
🧩 Plugin Support: Extend Open WebUI with Filters, Actions, Pipes, Tools, and Skills. Connect external services through MCP, MCPO, and OpenAPI tool servers. Build custom integrations, rate limits, approval flows, data connections, and more.
-
🤖 Models & Agents: Wrap any base model with custom instructions, tools, and knowledge to build specialized agents. Supports dynamic variables, per-user/group access control, and community preset imports via Open WebUI Community.
-
📝 Notes: A dedicated workspace for content outside conversations. Draft with a rich editor, use AI to rewrite selected text, and attach notes to any chat for full-context injection.
-
📢 Channels: Real-time shared spaces where your team and AI models collaborate in one timeline. Tag models to draft or critique, with threads, reactions, pins, and access control.
-
🧠 Persistent Memory: The AI remembers facts about you across conversations, carrying context from one chat to the next.
-
✅ Live Workflow & Message Flow: Watch the AI build and work through checklists in real time. Queue messages while the AI is still responding; they send automatically when it's ready.
-
📅 Calendar & AI Scheduling: Built-in personal and shared calendars with month/week/day views, recurring events, color coding, attendees, and reminders. Models manage your schedule conversationally through native function calling.
-
⏱️ Automations: Schedule prompts to run on recurring schedules, with runs surfaced on your calendar and each completed run linking back to the chat it produced.
-
📱 Responsive Design & PWA: Seamless experience across desktop, laptop, and mobile, with a Progressive Web App for native app-like feel and offline access on localhost.
-
✒️🔢 Full Markdown and LaTeX Support: Comprehensive Markdown and LaTeX capabilities for enriched interaction.
-
🎤📹 Hands-Free Voice/Video Call: Integrated voice and video calls with multiple Speech-to-Text providers (Local Whisper, OpenAI, Deepgram, Azure) and Text-to-Speech engines (Azure, ElevenLabs, OpenAI, Transformers, WebAPI).
-
💾 Persistent Artifact Storage: Built-in key-value storage API for artifacts, enabling journals, trackers, leaderboards, and collaborative tools with personal and shared data scopes.
-
📚 Local RAG Integration: Retrieval Augmented Generation backed by 9 vector databases and multiple content-extraction engines (Tika, Docling, Document Intelligence, Mistral OCR, PaddleOCR-vl, external loaders). Supports hybrid search (BM25 + vector) with reranking and full-context mode. Load documents into chat or pull them from your library with the
#command. -
🔍 Web Search for RAG: Search the web through dozens of providers including
SearXNG,Google PSE,Brave Search,Kagi,Mojeek,Tavily,Perplexity,Firecrawl,serpstack,serper,Serply,DuckDuckGo,SearchApi,SerpApi,Bing,Jina,Exa,Sougou,Azure AI Search, andOllama Cloud, injecting results directly into the conversation. -
🌐 Web Browsing Capability: Pull websites into chat with the
#command followed by a URL, or let the model fetch them on its own when needed. -
🎨 Image Generation & Editing: Create and edit images with multiple engines including OpenAI DALL·E, Gemini, ComfyUI (local), and AUTOMATIC1111 (local), supporting both generation and prompt-based editing.
-
⚙️ Multi-Model Conversations: Engage several models at once, harnessing their individual strengths in parallel for the best possible responses.
-
📊 Usage Analytics & Model Evaluation: Admin dashboards track message volume, token consumption, and cost across users and models. Evaluate models with a built-in arena, A/B testing, and ELO-based leaderboards.
-
🗄️ Flexible Database & Storage: Choose SQLite (with optional encryption) or PostgreSQL, and store files locally or on S3, Google Cloud Storage, or Azure Blob Storage.
-
🧬 Advanced Vector Database Support: Pick from 9 vector databases: ChromaDB, PGVector, Qdrant, Milvus, Elasticsearch, OpenSearch, Pinecone, S3Vector, and Oracle 23ai.
-
🪪 Enterprise Authentication & Provisioning: Full LDAP/Active Directory integration, SSO via trusted headers and OAuth providers, and SCIM 2.0 automated provisioning for identity providers like Okta, Azure AD, and Google Workspace.
-
☁️ Cloud-Native File Integration: Native Google Drive and OneDrive/SharePoint file picking for seamless document import from enterprise cloud storage.
-
🔭 Production Observability: Built-in OpenTelemetry support for traces, metrics, and logs, plugging into your existing monitoring stack.
-
⚖️ Horizontal Scalability: Redis-backed session management and WebSocket support for multi-worker, multi-node deployments behind load balancers.
-
🌐🌍 Multilingual Support: Use Open WebUI in your preferred language with i18n support. We're actively seeking contributors to expand language coverage!
-
🌟 Continuous Updates: We're committed to improving Open WebUI with regular updates, fixes, and new features.
-
🛡️ Transparent Security Process: Security reports are triaged, fixed, and published as open advisories through a documented responsible-disclosure process. See our Security Policy.
Want to learn more about Open WebUI's features? Check out our Open WebUI documentation for a comprehensive overview!
The Open WebUI Ecosystem 🌐
Open WebUI is the core, surrounded by companion apps and infrastructure that extend what your AI can do, where it can reach, and how you run it:
-
💻 Open WebUI Computer (open-webui/computer): A standalone, mobile-first computer and coding agent that runs on the machine you own. Files, terminal, and git in a browser tab, reachable from your phone. Connect it into Open WebUI as a model, or reach it from Telegram, WhatsApp, and more.
-
⚡ Open Terminal and Terminals (Enterprise) (open-webui/open-terminal & open-webui/terminals): A self-hosted computing environment that plugs into Open WebUI, giving the AI a place to write code, run it, read output, fix errors, and iterate inside the chat. Terminals gives you per-user isolated containers with separate credentials, resource limits, and network rules. Automatic lifecycle management on Docker or Kubernetes.
-
🔄 oikb (open-webui/oikb): Feed your Knowledge Bases from 45+ sources (GitHub, Confluence, ServiceNow, Salesforce, Jira, Slack, SharePoint, Notion, and more), keeping the tools your team already uses continuously in sync.
-
🖥️ Native Desktop App (open-webui/desktop): Run Open WebUI as a native app on macOS, Windows, and Linux. System-wide Spotlight chat bar with screenshot capture, push-to-talk voice, and optional fully-local inference via a built-in llama.cpp engine.
Want to learn more? Check out our Open WebUI documentation for more details!
We are incredibly grateful for the generous support of our sponsors. Their contributions help us to maintain and improve our project, ensuring we can continue to deliver quality work to our community. Thank you!
How to Install 🚀
Installation via Python pip 🐍
Open WebUI can be installed using pip, the Python package installer. Before proceeding, ensure you're using Python 3.11 to avoid compatibility issues.
-
Install Open WebUI: Open your terminal and run the following command to install Open WebUI:
pip install open-webui -
Running Open WebUI: After installation, you can start Open WebUI by executing:
open-webui serve
This will start the Open WebUI server, which you can access at http://localhost:8080
Quick Start with Docker 🐳
Note
Please note that for certain Docker environments, additional configurations might be needed. If you encounter any connection issues, our detailed guide on Open WebUI Documentation is ready to assist you.
Warning
When using Docker to install Open WebUI, make sure to include the
-v open-webui:/app/backend/datain your Docker command. This step is crucial as it ensures your database is properly mounted and prevents any loss of data.
Tip
If you wish to utilize Open WebUI with Ollama included or CUDA acceleration, we recommend utilizing our official images tagged with either
:cudaor:ollama. To enable CUDA, you must install the Nvidia CUDA container toolkit on your Linux/WSL system.
Installation with Default Configuration
-
If Ollama is on your computer, use this command:
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 -
If Ollama is on a Different Server, use this command:
To connect to Ollama on another server, change the
OLLAMA_BASE_URLto the server's URL:docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main -
To run Open WebUI with Nvidia GPU support, use this command:
docker run -d -p 3000:8080 --gpus all --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda
Installation for OpenAI API Usage Only
-
If you're only using OpenAI API, use this command:
docker run -d -p 3000:8080 -e OPENAI_API_KEY=your_secret_key -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
Installing Open WebUI with Bundled Ollama Support
This installation method uses a single container image that bundles Open WebUI with Ollama, allowing for a streamlined setup via a single command. Choose the appropriate command based on your hardware setup:
-
With GPU Support: Utilize GPU resources by running the following command:
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 -
For CPU Only: If you're not using a GPU, use this command instead:
docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama
Both commands facilitate a built-in, hassle-free installation of both Open WebUI and Ollama, ensuring that you can get everything up and running swiftly.
After installation, you can access Open WebUI at http://localhost:3000. Enjoy! 😄
Other Installation Methods
We offer various installation alternatives, including non-Docker native installation methods, Docker Compose, Kustomize, and Helm. Visit our Open WebUI Documentation or join our Discord community for comprehensive guidance.
Troubleshooting
Encountering connection issues? Our Open WebUI Documentation has got you covered. For further assistance and to join our vibrant community, visit the Open WebUI Discord.
Open WebUI: Server Connection Error
If you're experiencing connection issues, it’s often due to the WebUI docker container not being able to reach the Ollama server at 127.0.0.1:11434 (host.docker.internal:11434) inside the container . Use the --network=host flag in your docker command to resolve this. Note that the port changes from 3000 to 8080, resulting in the link: http://localhost:8080.
Example Docker Command:
docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main
Keeping Your Docker Installation Up-to-Date
Check our Updating Guide available in our Open WebUI Documentation.
Using the Dev Branch 🌙
Warning
The
:devbranch contains the latest unstable features and changes. Use it at your own risk as it may have bugs or incomplete features.
If you want to try out the latest bleeding-edge features and are okay with occasional instability, you can use the :dev tag like this:
docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui --add-host=host.docker.internal:host-gateway --restart always ghcr.io/open-webui/open-webui:dev
Offline Mode
If you are running Open WebUI in an offline environment, you can set the HF_HUB_OFFLINE environment variable to 1 to prevent attempts to download models from the internet.
export HF_HUB_OFFLINE=1
What's Next? 🌟
Discover upcoming features on our roadmap in the Open WebUI Documentation.
License 📜
This project contains code under multiple licenses. The current codebase includes components licensed under the Open WebUI License with an additional requirement to preserve the "Open WebUI" branding, as well as prior contributions under their respective original licenses. For a detailed record of license changes and the applicable terms for each section of the code, please refer to LICENSE_HISTORY. For complete and updated licensing details, please see the LICENSE and LICENSE_HISTORY files.
Support 💬
If you have any questions, suggestions, or need assistance, please open an issue or join our Open WebUI Discord community to connect with us! 🤝
Security 🛡️
If you believe you've found a security vulnerability, or something that shouldn't be disclosed publicly, please reach out confidentially through our responsible disclosure program on GitHub. We accept reports only through GitHub, not through any other platform. Thank you for helping us keep Open WebUI secure!
Star History
Created by Timothy Jaeryang Baek - Let's make Open WebUI even more amazing together! 💪