diff --git a/.gitignore b/.gitignore
index 280c6e6ea..72353ddb6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,6 +8,9 @@
.docusaurus
.cache-loader
+# Local banner render scratch (not for commit)
+.scratch_banner
+
# Misc
.DS_Store
.env.local
diff --git a/docs/enterprise/customers/astellas-pharma.mdx b/docs/enterprise/customers/astellas-pharma.mdx
index 31a638891..6becf0219 100644
--- a/docs/enterprise/customers/astellas-pharma.mdx
+++ b/docs/enterprise/customers/astellas-pharma.mdx
@@ -22,8 +22,8 @@ How Astellas Pharma Inc. built a secure, flexible internal AI platform with **Op
- **Industry**: Pharmaceutical
- **Deployment**: Azure AKS (private endpoints)
- **Models**: Azure OpenAI, Gemini, DeepSeek, Perplexity
-- **Time-to-deploy**: ~1 month (April–May 2025)
-- **Adoption**: 30–40% weekly active users sustained over five months
+- **Time-to-deploy**: ~1 month (April to May 2025)
+- **Adoption**: 30 to 40% weekly active users sustained over five months
- **Key Results**: 420+ custom models created, 68% of users report significant efficacy gains, +43 NPS
@@ -60,7 +60,7 @@ Open WebUI was selected for its **flexibility, fine-grained permission controls,
- **Security Controls**: MFA via IdP, RBAC by group, data residency enforced
-> “Open WebUI allowed us to create and share custom AI models securely across the entire company, while giving us the flexibility to leverage the full potential of any cutting-edge model available.” - Generative AI Team Manager, Astellas
+> “Open WebUI allowed us to create and share custom AI models securely across the entire company, while giving us the flexibility to leverage the full potential of any cutting-edge model available.” Generative AI Team Manager, Astellas
## Models & Data Handling
@@ -84,12 +84,12 @@ Training included:
Over the following months:
-- **Weekly active users stabilized at 30–40%** over five months
+- **Weekly active users stabilized at 30 to 40%** over five months
- Users organically created **hundreds of custom models**, sharing them across departments
- **All departments** adopted the platform, including Research, Clinical Development, Medical, Sales, Marketing, Legal, Compliance, Pharmacovigilance, Administration, Communications, and Corporate Strategy
-> “Our efficiency in gathering external scientific information has improved dramatically. Being able to select and switch models depending on the use case makes our research far more effective.” - Research Department User, Astellas
+> “Our efficiency in gathering external scientific information has improved dramatically. Being able to select and switch models depending on the use case makes our research far more effective.” Research Department User, Astellas
## Results: Democratization, Productivity, and Satisfaction
@@ -114,7 +114,7 @@ The platform grew to **3,200+ total users** organically, with an advanced user b
R&D and research teams reported dramatic improvements in gathering and synthesizing scientific information, clinical trial summaries, and multilingual medical documents.
-> “For coding tasks, efficiency has increased more than ten-fold, I can’t imagine working without this tool now.” - Advanced User, Astellas
+> “For coding tasks, efficiency has increased more than ten-fold, I can’t imagine working without this tool now.” Advanced User, Astellas
## Top Use Cases
@@ -146,7 +146,7 @@ R&D and research teams reported dramatic improvements in gathering and synthesiz
:::tip
-**Looking for an [Enterprise Plan](https://docs.openwebui.com/enterprise)?** — **[Speak with Our Sales Team Today!](https://docs.openwebui.com/enterprise)**
+**Looking for an [Enterprise Plan](https://docs.openwebui.com/enterprise)?** **[Speak with Our Sales Team Today!](https://docs.openwebui.com/enterprise)**
Get **enhanced capabilities**, including **custom theming and branding**, **Service Level Agreement (SLA) support**, **Long-Term Support (LTS) versions**, and **more!**
diff --git a/docs/enterprise/customers/public-storage.mdx b/docs/enterprise/customers/public-storage.mdx
index 7f3ffec7e..81344c893 100644
--- a/docs/enterprise/customers/public-storage.mdx
+++ b/docs/enterprise/customers/public-storage.mdx
@@ -17,7 +17,7 @@ How Public Storage used a **champion-driven rollout** to deploy a secure, privat
### At a Glance
-- **Users**: 5,000–10,000 employees
+- **Users**: 5,000 to 10,000 employees
- **Region**: United States (data residency enforced)
- **Industry**: Real Estate
- **Deployment**: GCP (containerized, private networking)
@@ -60,7 +60,7 @@ Open WebUI was selected for its **extensible foundation**: an open architecture
- **Security Controls**: MFA via IdP, RBAC by group, data residency enforced, PII redaction with user-facing interruption, moderation guardrails, audit exports to SIEM, DLP policies, egress restrictions
-> “Our goal wasn’t just to deploy AI, but to scale it responsibly. Open WebUI allows us to crowdsource high-value use cases from the business while maintaining the governance we need.” — CTO, Public Storage
+> “Our goal wasn’t just to deploy AI, but to scale it responsibly. Open WebUI allows us to crowdsource high-value use cases from the business while maintaining the governance we need.” CTO, Public Storage
## Models & Data Handling
@@ -84,7 +84,7 @@ Within the first month:
- Usage continued to grow as teams **shared successful workflows** with peers
- **All corporate functions** were represented, including HR, Marketing, Finance, Legal, Call Center, Operations, Sales/Acquisitions, IT, and Risk Management
-> “We’re seeing real operational time savings from use cases built by the business, not just IT, which has accelerated adoption and delivered practical results.” — VP, Digital Technology, Public Storage
+> “We’re seeing real operational time savings from use cases built by the business, not just IT, which has accelerated adoption and delivered practical results.” VP, Digital Technology, Public Storage
## Results: Productivity, Adoption, and Governance
@@ -132,7 +132,7 @@ The platform empowered every corporate function to discover and share AI-driven
:::tip
-**Looking for an [Enterprise Plan](https://docs.openwebui.com/enterprise)?** — **[Speak with Our Sales Team Today!](https://docs.openwebui.com/enterprise)**
+**Looking for an [Enterprise Plan](https://docs.openwebui.com/enterprise)?** **[Speak with Our Sales Team Today!](https://docs.openwebui.com/enterprise)**
Get **enhanced capabilities**, including **custom theming and branding**, **Service Level Agreement (SLA) support**, **Long-Term Support (LTS) versions**, and **more!**
diff --git a/docs/enterprise/customers/samsung-semiconductor.mdx b/docs/enterprise/customers/samsung-semiconductor.mdx
index bbc23cd61..490364322 100644
--- a/docs/enterprise/customers/samsung-semiconductor.mdx
+++ b/docs/enterprise/customers/samsung-semiconductor.mdx
@@ -17,7 +17,7 @@ How Samsung Semiconductor built a secure, self-hosted AI platform with **Open We
### At a Glance
-- **Users**: 1,000 - 4,999 employees
+- **Users**: 1,000 to 4,999 employees
- **Region**: United States (data residency enforced)
- **Industry**: Semiconductor
- **Deployment**: On-prem Kubernetes cluster
@@ -58,7 +58,7 @@ Open WebUI was selected for its **open architecture, flexibility, and rapid proo
- **Security Controls**: Data residency enforced; internal user access controls
-> “Open WebUI gave us control across security, models, and UX, without vendor lock-in.” — Software Engineering, Samsung Semiconductor, Inc.
+> “Open WebUI gave us control across security, models, and UX, without vendor lock-in.” Software Engineering, Samsung Semiconductor, Inc.
## Adoption & Enablement
@@ -69,7 +69,7 @@ Within 30 days:
- Daily active users stabilized at 5-10% of total employees
- R&D teams reported **significant productivity improvements**
-> “Open WebUI provides users with an environment similar to commercial tools, giving them a sense of familiarity, and at the same time, it has the advantage of improving usability with its simple and intuitive design.” — AI/ML Engineering, Samsung Semiconductor, Inc.
+> “Open WebUI provides users with an environment similar to commercial tools, giving them a sense of familiarity, and at the same time, it has the advantage of improving usability with its simple and intuitive design.” AI/ML Engineering, Samsung Semiconductor, Inc.
## Results: Speed, Adoption, and Control
@@ -109,7 +109,7 @@ Samsung Semiconductor plans to continue expanding its AI infrastructure with Ope
:::tip
-**Looking for an [Enterprise Plan](https://docs.openwebui.com/enterprise)?** — **[Speak with Our Sales Team Today!](https://docs.openwebui.com/enterprise)**
+**Looking for an [Enterprise Plan](https://docs.openwebui.com/enterprise)?** **[Speak with Our Sales Team Today!](https://docs.openwebui.com/enterprise)**
Get **enhanced capabilities**, including **custom theming and branding**, **Service Level Agreement (SLA) support**, **Long-Term Support (LTS) versions**, and **more!**
diff --git a/docs/enterprise/deployment/container-service.md b/docs/enterprise/deployment/container-service.md
index 9ca996f93..94b6e0069 100644
--- a/docs/enterprise/deployment/container-service.md
+++ b/docs/enterprise/deployment/container-service.md
@@ -8,7 +8,7 @@ title: "Container Service"
Run the official `ghcr.io/open-webui/open-webui` image on a managed container platform such as AWS ECS/Fargate, Azure Container Apps, or Google Cloud Run.
:::info Prerequisites
-Before proceeding, ensure you have configured the [shared infrastructure requirements](/enterprise/deployment#shared-infrastructure-requirements) — PostgreSQL, Redis, a vector database, shared storage, and content extraction.
+Before proceeding, ensure you have configured the [shared infrastructure requirements](/enterprise/deployment#shared-infrastructure-requirements): PostgreSQL, Redis, a vector database, shared storage, and content extraction.
:::
## When to Choose This Pattern
@@ -49,7 +49,7 @@ Use **versioned tags** for production stability:
ghcr.io/open-webui/open-webui:v0.x.x
```
-Avoid the `:main` tag in production — it tracks the latest development build and can introduce breaking changes without warning. Check the [Open WebUI releases](https://github.com/open-webui/open-webui/releases) for the latest stable version.
+Avoid the `:main` tag in production. It tracks the latest development build and can introduce breaking changes without warning. Check the [Open WebUI releases](https://github.com/open-webui/open-webui/releases) for the latest stable version.
## Scaling Strategy
@@ -65,7 +65,7 @@ Avoid the `:main` tag in production — it tracks the latest development build a
| **Storage** | Use object storage (S3, GCS, Azure Blob) or a shared filesystem (such as EFS). Container-local storage is ephemeral and not shared across tasks. |
| **Tika sidecar** | Run Tika as a sidecar container in the same task definition, or as a separate service. Sidecar pattern keeps extraction traffic local. |
| **Secrets management** | Use your platform's secrets manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) for `DATABASE_URL`, `REDIS_URL`, and `WEBUI_SECRET_KEY`. |
-| **Updates** | Perform a rolling deployment with a single task first — this task runs migrations (`ENABLE_DB_MIGRATIONS=true`). Once healthy, scale the remaining tasks with `ENABLE_DB_MIGRATIONS=false`. |
+| **Updates** | Perform a rolling deployment with a single task first. This task runs migrations (`ENABLE_DB_MIGRATIONS=true`). Once healthy, scale the remaining tasks with `ENABLE_DB_MIGRATIONS=false`. |
## Anti-Patterns to Avoid
diff --git a/docs/enterprise/deployment/index.md b/docs/enterprise/deployment/index.md
index 365b72965..e492395b4 100644
--- a/docs/enterprise/deployment/index.md
+++ b/docs/enterprise/deployment/index.md
@@ -5,7 +5,7 @@ title: "Deployment Options"
# Scalable Enterprise Deployment Options
-Open WebUI's **stateless, container-first architecture** means the same application runs identically whether you deploy it as a Python process on a VM, a container in a managed service, or a pod in a Kubernetes cluster. The difference between deployment patterns is how you **orchestrate, scale, and operate** the application — not how the application itself behaves.
+Open WebUI's **stateless, container-first architecture** means the same application runs identically whether you deploy it as a Python process on a VM, a container in a managed service, or a pod in a Kubernetes cluster. The difference between deployment patterns is how you **orchestrate, scale, and operate** the application, not how the application itself behaves.
:::tip Model Inference Is Independent
How you serve LLM models is separate from how you deploy Open WebUI. You can use **managed APIs** (OpenAI, Anthropic, Azure OpenAI, Google Gemini) or **self-hosted inference** (Ollama, vLLM) with any deployment pattern. See [Integration](/enterprise/integration) for details on connecting models.
@@ -83,7 +83,7 @@ Deploy `open-webui serve` as a systemd-managed process on virtual machines in a
### [Container Service](./container-service)
-Run the official Open WebUI container image on a managed platform such as AWS ECS/Fargate, Azure Container Apps, or Google Cloud Run. Best for teams wanting container benefits — immutable images, versioned deployments, no OS management — without Kubernetes complexity.
+Run the official Open WebUI container image on a managed platform such as AWS ECS/Fargate, Azure Container Apps, or Google Cloud Run. Best for teams wanting container benefits (immutable images, versioned deployments, no OS management) without Kubernetes complexity.
### [Kubernetes with Helm](./kubernetes-helm)
@@ -95,9 +95,9 @@ Deploy using the official Open WebUI Helm chart on any Kubernetes distribution (
| | **Python / Pip (VMs)** | **Container Service** | **Kubernetes (Helm)** |
| :--- | :--- | :--- | :--- |
-| **Operational complexity** | Moderate — OS patching, Python management | Low — platform-managed containers | Higher — requires K8s expertise |
+| **Operational complexity** | Moderate (OS patching, Python management) | Low (platform-managed containers) | Higher (requires K8s expertise) |
| **Auto-scaling** | Cloud ASG/VMSS with health checks | Platform-native, minimal configuration | HPA with fine-grained control |
-| **Container isolation** | None — process runs directly on OS | Full container isolation | Full container + namespace isolation |
+| **Container isolation** | None (process runs directly on OS) | Full container isolation | Full container + namespace isolation |
| **Rolling updates** | Manual (scale down, update, scale up) | Platform-managed rolling deployments | Declarative rolling updates with rollback |
| **Infrastructure-as-code** | Terraform/Pulumi for VMs + config mgmt | Task/service definitions (CloudFormation, Bicep, Terraform) | Helm charts + GitOps (Argo CD, Flux) |
| **Best suited for** | Teams with VM-centric operations, regulatory constraints | Teams wanting container benefits without K8s complexity | Large-scale, mission-critical deployments |
@@ -111,8 +111,8 @@ Production deployments should include monitoring and observability regardless of
### Health Checks
-- **`/health`** — Basic liveness check. Returns HTTP 200 when the application is running. Use this for load balancer and auto-scaler health checks.
-- **`/api/models`** — Verifies the application can connect to configured model backends. Requires an API key.
+- **`/health`**: Basic liveness check. Returns HTTP 200 when the application is running. Use this for load balancer and auto-scaler health checks.
+- **`/api/models`**: Verifies the application can connect to configured model backends. Requires an API key.
### OpenTelemetry
@@ -124,7 +124,7 @@ OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4318
OTEL_SERVICE_NAME=open-webui
```
-This auto-instruments FastAPI, SQLAlchemy, Redis, and HTTP clients — giving visibility into request latency, database query performance, and cross-service traces.
+This auto-instruments FastAPI, SQLAlchemy, Redis, and HTTP clients, giving visibility into request latency, database query performance, and cross-service traces.
### Structured Logging
@@ -141,11 +141,11 @@ For full monitoring setup details, see [Monitoring](/reference/monitoring) and [
## Next Steps
-- **[Architecture & High Availability](/enterprise/architecture)** — Deeper dive into Open WebUI's stateless design and HA capabilities.
-- **[Security](/enterprise/security)** — Compliance frameworks, SSO/LDAP integration, RBAC, and audit logging.
-- **[Integration](/enterprise/integration)** — Connecting AI models, pipelines, and extending functionality.
-- **[Scaling Open WebUI](/getting-started/advanced-topics/scaling)** — The complete step-by-step technical scaling guide.
-- **[Multi-Replica Troubleshooting](/troubleshooting/multi-replica)** — Solutions for common issues in scaled deployments.
+- **[Architecture & High Availability](/enterprise/architecture)**: Deeper dive into Open WebUI's stateless design and HA capabilities.
+- **[Security](/enterprise/security)**: Compliance frameworks, SSO/LDAP integration, RBAC, and audit logging.
+- **[Integration](/enterprise/integration)**: Connecting AI models, pipelines, and extending functionality.
+- **[Scaling Open WebUI](/getting-started/advanced-topics/scaling)**: The complete step-by-step technical scaling guide.
+- **[Multi-Replica Troubleshooting](/troubleshooting/multi-replica)**: Solutions for common issues in scaled deployments.
---
diff --git a/docs/enterprise/deployment/kubernetes-helm.md b/docs/enterprise/deployment/kubernetes-helm.md
index f5d15dbe2..d4ea0c0ce 100644
--- a/docs/enterprise/deployment/kubernetes-helm.md
+++ b/docs/enterprise/deployment/kubernetes-helm.md
@@ -8,7 +8,7 @@ title: "Kubernetes with Helm"
Deploy using the official Open WebUI Helm chart on any Kubernetes distribution (EKS, AKS, GKE, OpenShift, Rancher, self-managed).
:::info Prerequisites
-Before proceeding, ensure you have configured the [shared infrastructure requirements](/enterprise/deployment#shared-infrastructure-requirements) — PostgreSQL, Redis, a vector database, shared storage, and content extraction.
+Before proceeding, ensure you have configured the [shared infrastructure requirements](/enterprise/deployment#shared-infrastructure-requirements): PostgreSQL, Redis, a vector database, shared storage, and content extraction.
:::
## When to Choose This Pattern
@@ -62,7 +62,7 @@ helm repo update
helm install openwebui open-webui/open-webui -f values.yaml
```
-Your `values.yaml` should override the defaults to point at your shared infrastructure. The chart has dedicated values for many common settings — use these instead of raw environment variables where available:
+Your `values.yaml` should override the defaults to point at your shared infrastructure. The chart has dedicated values for many common settings: use these instead of raw environment variables where available:
```yaml
# Example values.yaml overrides (refer to chart documentation for full schema)
diff --git a/docs/enterprise/deployment/python-pip.md b/docs/enterprise/deployment/python-pip.md
index cbbb34fe9..752de41e2 100644
--- a/docs/enterprise/deployment/python-pip.md
+++ b/docs/enterprise/deployment/python-pip.md
@@ -8,7 +8,7 @@ title: "Python / Pip on VMs"
Deploy `open-webui serve` as a systemd-managed process on virtual machines in a cloud auto-scaling group (AWS ASG, Azure VMSS, GCP MIG).
:::info Prerequisites
-Before proceeding, ensure you have configured the [shared infrastructure requirements](/enterprise/deployment#shared-infrastructure-requirements) — PostgreSQL, Redis, a vector database, shared storage, and content extraction.
+Before proceeding, ensure you have configured the [shared infrastructure requirements](/enterprise/deployment#shared-infrastructure-requirements): PostgreSQL, Redis, a vector database, shared storage, and content extraction.
:::
## When to Choose This Pattern
diff --git a/docs/enterprise/index.mdx b/docs/enterprise/index.mdx
index 14de90082..09a9cc7bc 100644
--- a/docs/enterprise/index.mdx
+++ b/docs/enterprise/index.mdx
@@ -83,7 +83,7 @@ Understand how Open WebUI supports large-scale deployments. Explore multi-node c
Learn how Open WebUI integrates with your existing identity infrastructure, including LDAP, Active Directory, and SSO providers. Ideal for organizations requiring on-premise or air-gapped deployments.
#### [🚀 Deployment Options](./deployment)
-Choose the right deployment pattern for your organization — from Python on auto-scaling VMs to managed container services to Kubernetes with Helm.
+Choose the right deployment pattern for your organization, from Python on auto-scaling VMs to managed container services to Kubernetes with Helm.
#### [🔗 Integration](./integration)
Connect proprietary, third-party, or local AI models. Extend functionality with plugins, pipelines, and custom workflows that fit your existing infrastructure.
diff --git a/docs/faq.mdx b/docs/faq.mdx
index 58ea25841..82b7e1c5d 100644
--- a/docs/faq.mdx
+++ b/docs/faq.mdx
@@ -9,14 +9,14 @@ title: "❓ FAQ"
**A:** Community support for Open WebUI is provided by **volunteers** who generously contribute their time and expertise. Because of this, responses are best-effort and may not always be immediate or personalized. For organizations that need dedicated, guaranteed support, check out our **[Enterprise offerings](https://docs.openwebui.com/enterprise)**.
**To get the best help:**
-1. **Search first.** Check these docs, [Discord](https://discord.gg/5rJgQTnV4s), [Reddit](https://www.reddit.com/r/OpenWebUI/), [GitHub Discussions](https://github.com/open-webui/open-webui/discussions), and [Issues](https://github.com/open-webui/open-webui/issues) — your question may already be answered.
+1. **Search first.** Check these docs, [Discord](https://discord.gg/5rJgQTnV4s), [Reddit](https://www.reddit.com/r/OpenWebUI/), [GitHub Discussions](https://github.com/open-webui/open-webui/discussions), and [Issues](https://github.com/open-webui/open-webui/issues). Your question may already be answered.
2. **Try the Discord bot.** In our [Discord server](https://discord.gg/5rJgQTnV4s)'s **#questions** channel, we have an experimental bot that has access to all issues, all discussions, and the entire documentation. Simply ping the bot with your question in the same message, wait a few seconds, and it will answer you. As our documentation improves, so does the bot.
3. **Provide details.** When asking for help, include: your Open WebUI version, deployment method (Docker/pip), model provider and model name, relevant settings (screenshots of the Admin Panel section are ideal), and steps to reproduce the issue.
-4. **Be kind.** Contributors volunteer their limited time — respectful, well-prepared questions go a long way. Please review our **[Code of Conduct](https://github.com/open-webui/open-webui/blob/main/CODE_OF_CONDUCT.md)** before participating.
+4. **Be kind.** Contributors volunteer their limited time, so respectful, well-prepared questions go a long way. Please review our **[Code of Conduct](https://github.com/open-webui/open-webui/blob/main/CODE_OF_CONDUCT.md)** before participating.
**Where to ask:**
-- 🤖 **Quick Answers**: [Discord #questions channel](https://discord.gg/5rJgQTnV4s) — try the bot first, it can answer most Open WebUI questions
-- 🐛 **Bugs**: [GitHub Issues](https://github.com/open-webui/open-webui/issues) — please use the issue template and include all requested information (Open WebUI version, browser, deployment method, expected vs. actual behavior, and logs). Clear steps to reproduce the issue along with relevant settings are essential — reproducibility is key to getting bugs resolved quickly. Reports missing key details may be closed or converted to discussions.
+- 🤖 **Quick Answers**: [Discord #questions channel](https://discord.gg/5rJgQTnV4s). Try the bot first, it can answer most Open WebUI questions
+- 🐛 **Bugs**: [GitHub Issues](https://github.com/open-webui/open-webui/issues). Please use the issue template and include all requested information (Open WebUI version, browser, deployment method, expected vs. actual behavior, and logs). Clear steps to reproduce the issue along with relevant settings are essential, and reproducibility is key to getting bugs resolved quickly. Reports missing key details may be closed or converted to discussions.
- 💬 **Questions & Help**: [Discord](https://discord.gg/5rJgQTnV4s) (most active community), [Reddit](https://www.reddit.com/r/OpenWebUI/), or [GitHub Discussions](https://github.com/open-webui/open-webui/discussions)
- 💡 **Feature Requests**: [GitHub Discussions](https://github.com/open-webui/open-webui/discussions/new/choose)
@@ -44,11 +44,11 @@ For more details on enterprise solutions and branding customizations, [click her
### Q: I get "The prompt is too long" / "context length exceeded" after a while in a chat. How do I fix it?
-**A:** This error comes from the **model provider**, not from Open WebUI — the provider counts the tokens of everything you sent (system prompt + the *entire* chat history + attached files + tool calls + your new message) and rejects the request once it exceeds the model's context window. The "prompt" the model sees is the whole conversation, not just your latest message.
+**A:** This error comes from the **model provider**, not from Open WebUI. The provider counts the tokens of everything you sent (system prompt + the *entire* chat history + attached files + tool calls + your new message) and rejects the request once it exceeds the model's context window. The "prompt" the model sees is the whole conversation, not just your latest message.
Open WebUI intentionally does **not** ship a built-in context trimmer. Every model has a different tokenizer and a different context window, and every deployment wants a different truncation policy (by tokens, by turns, by message count, file-attachments-first, summarize-and-replace, per-model budgets, and so on). There is no single policy that is correct for every user, so we expose the hook instead of choosing one for you.
-Context management is done with [filter Functions](/features/extensibility/plugin/functions/filter): `inlet()` receives the full `body["messages"]` on every request and can modify it freely (drop old turns, enforce a turn limit, summarize, trim attachments, etc.). Many community-maintained context filters are already available one-click on [openwebui.com](https://openwebui.com/) — browse, install, and tune the valves. If none fits, copy the closest one into **Admin Panel → Functions** and edit it.
+Context management is done with [filter Functions](/features/extensibility/plugin/functions/filter): `inlet()` receives the full `body["messages"]` on every request and can modify it freely (drop old turns, enforce a turn limit, summarize, trim attachments, etc.). Many community-maintained context filters are already available one-click on [openwebui.com](https://openwebui.com/): browse, install, and tune the valves. If none fits, copy the closest one into **Admin Panel → Functions** and edit it.
For the full write-up with examples, see [Context Window / Prompt Too Long](/troubleshooting/context-window).
@@ -56,9 +56,9 @@ For the full write-up with examples, see [Context Window / Prompt Too Long](/tro
**A:** **Yes.** Open WebUI is a self-hosted, **internet-independent AI platform** designed to work in **air-gapped networks**, **remote deployments**, and any environment where cloud-based systems are impractical or impossible. Whether you need to **run an LLM without internet**, deploy a **private AI with no cloud dependency**, or operate a **local AI chatbot offline**, Open WebUI supports all of these out of the box. It runs entirely on local hardware and does not make external calls by default.
-This **Earth-independent architecture** is well suited as an **AI interface for space exploration** — spacecraft, the ISS, lunar bases, Mars habitats, and deep-space missions — where communication delays or total network isolation make cloud AI unworkable. Whether you need **self-hosted AI for remote locations** or need to **run AI in a disconnected environment**, Open WebUI's **offline-first design** keeps models, tools, and data local and predictable even under extreme latency or complete disconnection.
+This **Earth-independent architecture** is well suited as an **AI interface for space exploration** (spacecraft, the ISS, lunar bases, Mars habitats, and deep-space missions) where communication delays or total network isolation make cloud AI unworkable. Whether you need **self-hosted AI for remote locations** or need to **run AI in a disconnected environment**, Open WebUI's **offline-first design** keeps models, tools, and data local and predictable even under extreme latency or complete disconnection.
-The same principles apply to harsh terrestrial settings: submarines, polar research stations, underground facilities, **air-gapped networks**, disaster zones, field operations, and mobile command environments. Open WebUI serves as an **offline AI interface** for defense, research, and critical infrastructure where internet access is unavailable, unreliable, or prohibited. If your system can boot and power itself, Open WebUI is designed to run — no network required.
+The same principles apply to harsh terrestrial settings: submarines, polar research stations, underground facilities, **air-gapped networks**, disaster zones, field operations, and mobile command environments. Open WebUI serves as an **offline AI interface** for defense, research, and critical infrastructure where internet access is unavailable, unreliable, or prohibited. If your system can boot and power itself, Open WebUI is designed to run, no network required.
### Q: Why am I asked to sign up? Where are my data being sent to?
@@ -204,7 +204,7 @@ For complete workflow examples, see the **[API Endpoints documentation](/referen
### Q: I asked the model what it is and it gave the wrong answer. Is Open WebUI routing to the wrong model?
-**A:** No—**LLMs do not reliably know their own identity.** When you ask a model "What model are you?" or "Are you GPT-4?", the response is not a system diagnostic. It's simply the model generating text based on patterns in its training data.
+**A:** No. **LLMs do not reliably know their own identity.** When you ask a model "What model are you?" or "Are you GPT-4?", the response is not a system diagnostic. It's simply the model generating text based on patterns in its training data.
Models frequently:
- Claim to be a different model (e.g., a Llama model claiming to be ChatGPT)
@@ -223,9 +223,9 @@ Asking the model itself is **not** a valid way to diagnose routing issues. If yo
**A:** Because the provider **injects a system prompt** that explicitly tells the model what it is. When you use ChatGPT, OpenAI's interface includes a hidden system message like "You are ChatGPT, a large language model trained by OpenAI..." before your conversation begins.
-The model isn't "aware" of itself—it's simply been instructed to claim a specific identity. You can do the same thing in Open WebUI by adding a system prompt to your model configuration (e.g., "You are Llama 3.3 70B..."). The model will then confidently repeat whatever identity you've told it to claim.
+The model isn't "aware" of itself; it's simply been instructed to claim a specific identity. You can do the same thing in Open WebUI by adding a system prompt to your model configuration (e.g., "You are Llama 3.3 70B..."). The model will then confidently repeat whatever identity you've told it to claim.
-This is also why the same model accessed through different interfaces might give different answers about its identity—it depends entirely on what system prompt (if any) was provided.
+This is also why the same model accessed through different interfaces might give different answers about its identity; it depends entirely on what system prompt (if any) was provided.
### Q: Why am I seeing multiple API requests when I only send one message? Why is my token usage higher than expected?
@@ -256,14 +256,14 @@ For more optimization tips, see the **[Performance Tips Guide](troubleshooting/p
### Q: Why doesn't Open WebUI natively support [Provider X]'s proprietary API?
-**A:** Open WebUI is highly modular with a plugin system including tools, functions, and most notably **[pipes](/features/extensibility/plugin/functions/pipe)**. These modular pipes allow you to add support for virtually any provider you want—you can build your own or choose from the many [community-built](https://openwebui.com/) and usually well-maintained ones already available.
+**A:** Open WebUI is highly modular with a plugin system including tools, functions, and most notably **[pipes](/features/extensibility/plugin/functions/pipe)**. These modular pipes allow you to add support for virtually any provider you want: you can build your own or choose from the many [community-built](https://openwebui.com/) and usually well-maintained ones already available.
That said, Open WebUI's core is built around **universal protocols**, not specific providers. Our stance is to support standard, widely-adopted APIs like the **OpenAI Chat Completions protocol**.
This protocol-centric design ensures that Open WebUI remains backend-agnostic and compatible with dozens of providers simultaneously. We avoid implementing proprietary, provider-specific APIs in the core to prevent unsustainable architectural bloat and to maintain a truly open ecosystem.
:::note Experimental: Open Responses
-As new standards emerge that gain broad adoption, we may add experimental support. Connections can now optionally be configured to use **[Open Responses](https://www.openresponses.org/)**—an open specification for multi-provider interoperability with consistent streaming events and tool use patterns.
+As new standards emerge that gain broad adoption, we may add experimental support. Connections can now optionally be configured to use **[Open Responses](https://www.openresponses.org/)**, an open specification for multi-provider interoperability with consistent streaming events and tool use patterns.
:::
We understand this request comes up frequently, especially for major providers. Here's why we've made this deliberate architectural decision:
@@ -275,7 +275,7 @@ Supporting one proprietary API sets a precedent. Once that precedent exists, eve
#### 2. Maintenance is the Real Burden
Adding integration code is the easy part. **Maintaining it forever** is where the real cost lies:
-- Each provider updates their API independently—when a provider changes something, we must update and test immediately
+- Each provider updates their API independently. When a provider changes something, we must update and test immediately
- Changes in one integration can break compatibility with others
- Every integration requires ongoing testing across multiple scenarios
- Bug reports flood in for each provider whenever they make changes
@@ -317,7 +317,7 @@ The assumption that bundling the frontend with the backend is unscalable comes f
### Q: Is Open WebUI scalable for large organizations or enterprise deployments?
-**A:** Yes, **Open WebUI is architected for scalability and production readiness.** With the right infrastructure, it supports deployments at significant scale—**including organizations with tens of thousands of users**—across universities, multinational enterprises, and government agencies worldwide. See the [Scaling Guide](/getting-started/advanced-topics/scaling) for the infrastructure requirements at each stage.
+**A:** Yes, **Open WebUI is architected for scalability and production readiness.** With the right infrastructure, it supports deployments at significant scale (**including organizations with tens of thousands of users**) across universities, multinational enterprises, and government agencies worldwide. See the [Scaling Guide](/getting-started/advanced-topics/scaling) for the infrastructure requirements at each stage.
Open WebUI’s stateless, container-first architecture means you’re not limited to a single server. Through horizontal scaling, flexible storage backends, externalized authentication and database support, and full container orchestration compatibility (for example, Kubernetes or Docker Swarm), you can build robust, high-availability clusters to meet even the most demanding enterprise requirements.
@@ -337,17 +337,17 @@ If you’re planning a high-availability, enterprise-grade deployment, we recomm
👉 [The SRE's Guide to High Availability Open WebUI Deployment Architecture](http://taylorwilsdon.medium.com/the-sres-guide-to-high-availability-open-webui-deployment-architecture-2ee42654eced)
*(This provides a strong technical overview and best practices for large-scale Open WebUI architecture.)*
-Open WebUI is designed from day one to not just handle, but thrive at scale—serving large organizations, universities, and enterprises worldwide.
+Open WebUI is designed from day one to not just handle, but thrive at scale, serving large organizations, universities, and enterprises worldwide.
### Q: How often is Open WebUI updated? (Release Schedule)
-**A:** We aim to ship **major releases weekly**, with **bug fixes and minor updates delivered as needed**. However, this is not a rigid schedule—some weeks may see multiple releases, while others might have none at all.
+**A:** We aim to ship **major releases weekly**, with **bug fixes and minor updates delivered as needed**. However, this is not a rigid schedule. Some weeks may see multiple releases, while others might have none at all.
To stay informed, you can follow release notes and announcements on our [GitHub Releases page](https://github.com/open-webui/open-webui/releases).
### Q: Where do I report non-compliant Open WebUI deployments that violate the license?
-If you encounter an Open WebUI deployment that appears to violate the Open WebUI license—such as removed branding where it is not permitted, misleading white-labeling, commercial misuse, or any form of unauthorized redistribution—you can confidentially report it to our compliance team.
+If you encounter an Open WebUI deployment that appears to violate the Open WebUI license (such as removed branding where it is not permitted, misleading white-labeling, commercial misuse, or any form of unauthorized redistribution) you can confidentially report it to our compliance team.
📩 **Email:** **[reports@openwebui.com](mailto:reports@openwebui.com)**
Please include any relevant details (screenshots, URLs, description of usage, etc.) so we can investigate appropriately.
diff --git a/docs/features/administration/_category_.json b/docs/features/administration/_category_.json
index 34268e388..fe419a9e4 100644
--- a/docs/features/administration/_category_.json
+++ b/docs/features/administration/_category_.json
@@ -1,6 +1,6 @@
{
"label": "🔧 Administration",
- "position": 10,
+ "position": 46,
"collapsible": true,
"collapsed": true
}
diff --git a/docs/features/administration/banners.md b/docs/features/administration/banners.md
index caad5e381..206e0af3c 100644
--- a/docs/features/administration/banners.md
+++ b/docs/features/administration/banners.md
@@ -113,7 +113,7 @@ If users dismissed a banner and you want them to see an updated message, change
## Supported content formatting (HTML only)
-Banner `title` and `content` support a subset of **HTML only** — Markdown syntax is not rendered. Unsupported tags may render as plain text or break the layout.
+Banner `title` and `content` support a subset of **HTML only**: Markdown syntax is not rendered. Unsupported tags may render as plain text or break the layout.
### Text formatting
@@ -239,7 +239,7 @@ renders more predictably than heavily formatted HTML with many line breaks.
The following are not supported in banners and may render as plain text or break the layout:
-- Headings (`
`–``)
+- Headings (`` to ``)
- Lists (``, ``)
- Tables
- Blockquotes
diff --git a/docs/features/administration/evaluation/index.mdx b/docs/features/administration/evaluation/index.mdx
index f8d8866b7..1a6056ec1 100644
--- a/docs/features/administration/evaluation/index.mdx
+++ b/docs/features/administration/evaluation/index.mdx
@@ -5,7 +5,7 @@ title: "Evaluation"
## Why Should I Evaluate Models?
-Meet **Alex**, a machine learning engineer at a mid-sized company. Alex knows there are numerous AI models out there—GPTs, LLaMA, and many more—but which one works best for the job at hand? They all sound impressive on paper, but Alex can’t just rely on public leaderboards. These models perform differently depending on the context, and some models may have been trained on the evaluation dataset (sneaky!). Plus, the way these models write can sometimes feel … off.
+Meet **Alex**, a machine learning engineer at a mid-sized company. Alex knows there are numerous AI models out there (GPTs, LLaMA, and many more) but which one works best for the job at hand? They all sound impressive on paper, but Alex can’t just rely on public leaderboards. These models perform differently depending on the context, and some models may have been trained on the evaluation dataset (sneaky!). Plus, the way these models write can sometimes feel … off.
That's where Open WebUI comes in. It gives Alex and their team an easy way to evaluate models based on their actual needs. No convoluted math. No heavy lifting. Just thumbs up or thumbs down while interacting with the models.
@@ -28,7 +28,7 @@ That's where Open WebUI comes in. It gives Alex and their team an easy way to ev
### The Solution: Personalized Evaluation with Open WebUI
-Open WebUI has a built-in evaluation feature that lets you and your team discover the model best suited for your particular needs—all while interacting with the models.
+Open WebUI has a built-in evaluation feature that lets you and your team discover the model best suited for your particular needs, all while interacting with the models.
How does it work? Simple!
@@ -45,7 +45,7 @@ Open WebUI provides two straightforward approaches for evaluating AI models.
### **1. Arena Model**
-The **Arena Model** randomly selects from a pool of available models, making sure the evaluation is fair and unbiased. This helps in removing a potential flaw in manual comparison: **ecological validity** – ensuring you don’t knowingly or unknowingly favor one model.
+The **Arena Model** randomly selects from a pool of available models, making sure the evaluation is fair and unbiased. This helps in removing a potential flaw in manual comparison: **ecological validity**, ensuring you don’t knowingly or unknowingly favor one model.
How to use it:
- Select a model from the Arena Model selector.
@@ -66,7 +66,7 @@ Need more depth? You can even replicate a [**Chatbot Arena**](https://lmarena.ai
### **2. Normal Interaction**
-No need to switch to “arena mode” if you don't want to. You can use Open WebUI normally and rate the AI model responses as you would in everyday operations. Just thumbs up/down the model responses, whenever you feel like it. However, **if you want your feedback to be used for ranking on the leaderboard**, you'll need to **swap out the model and interact with a different one**. This ensures there's a **sibling response** to compare it with – only comparisons between two different models will influence rankings.
+No need to switch to “arena mode” if you don't want to. You can use Open WebUI normally and rate the AI model responses as you would in everyday operations. Just thumbs up/down the model responses, whenever you feel like it. However, **if you want your feedback to be used for ranking on the leaderboard**, you'll need to **swap out the model and interact with a different one**. This ensures there's a **sibling response** to compare it with. Only comparisons between two different models will influence rankings.
For instance, this is how you can rate during a normal interaction:
@@ -113,7 +113,7 @@ Here’s an example of how re-ranking looks:
### Side Note: Chat Snapshots for Model Fine-Tuning
-Whenever you rate a model’s response, Open WebUI *captures a snapshot of that chat*. These snapshots can eventually be used to **fine-tune your own models**—so your evaluations feed into the continuous improvement of the AI.
+Whenever you rate a model’s response, Open WebUI *captures a snapshot of that chat*. These snapshots can eventually be used to **fine-tune your own models**, so your evaluations feed into the continuous improvement of the AI.
*(Stay tuned for more updates on this feature, it's actively being developed!)*
diff --git a/docs/features/administration/index.mdx b/docs/features/administration/index.mdx
index e3d6f4f89..df6a67fe7 100644
--- a/docs/features/administration/index.mdx
+++ b/docs/features/administration/index.mdx
@@ -3,8 +3,20 @@ sidebar_position: 0
title: "Administration"
---
+import ThemedImage from '@theme/ThemedImage';
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
# 🔧 Administration
+
+
**Monitor usage, evaluate model quality, and communicate with your users, all from the Admin Panel.**
Open WebUI gives administrators a full operational toolkit. Track which models your team uses and how much they cost. Run blind evaluations to find the best model for your workload. Push announcements to every user with customizable banners. Wire up webhooks to get notified when users sign up or when long-running tasks finish.
diff --git a/docs/features/authentication-access/_category_.json b/docs/features/authentication-access/_category_.json
index 7122348e1..2394a86a1 100644
--- a/docs/features/authentication-access/_category_.json
+++ b/docs/features/authentication-access/_category_.json
@@ -1,6 +1,6 @@
{
"label": "🔐 Authentication & Access",
- "position": 9,
+ "position": 45,
"collapsible": true,
"collapsed": true
}
diff --git a/docs/features/authentication-access/auth/sso/index.mdx b/docs/features/authentication-access/auth/sso/index.mdx
index 2e7261992..79dec7b3f 100644
--- a/docs/features/authentication-access/auth/sso/index.mdx
+++ b/docs/features/authentication-access/auth/sso/index.mdx
@@ -28,18 +28,18 @@ You cannot have Microsoft **and** Google as OIDC providers simultaneously.
| Environment Variable | Default | Description |
|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------|
-| `WEBUI_URL` | — | **Required.** Your public WebUI address, e.g., `http://localhost:8080`. |
+| `WEBUI_URL` | *(none)* | **Required.** Your public WebUI address, e.g., `http://localhost:8080`. |
| `ENABLE_OAUTH_PERSISTENT_CONFIG` | `false` | Load OAuth settings from the database (when persistent config is on). Default `false` keeps environment variables authoritative for OAuth; set `true` to manage OAuth in the Admin Panel. |
| `ENABLE_OAUTH_SIGNUP` | `false` | Allows account creation upon OAuth login (separate from `ENABLE_SIGNUP`). |
| `OAUTH_AUTO_REDIRECT` | `false` | Send unauthenticated users at `/auth` straight to the provider login, skipping the "Continue with SSO" screen. Requires exactly one provider, `ENABLE_LOGIN_FORM=false` and no LDAP; visit `/auth?form=true` for the local login form. |
| `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` | `false` | Merge OAuth logins based on matching email (caution: can be insecure if provider doesn't verify emails). |
| `OAUTH_UPDATE_PICTURE_ON_LOGIN` | `false` | Update user profile pictures from OAuth provider with each login. |
| `OAUTH_PICTURE_CLAIM` | `picture` | Field in the claim containing the profile picture. Set to empty string to disable picture updates (users receive default icon).|
-| `ENABLE_PROFILE_IMAGE_URL_FORWARDING` | `true` | When `true`, the backend issues a `302` redirect from `/api/v1/users/{id}/profile/image` to whatever external URL the IdP wrote into `profile_image_url`. Each browser then loads the avatar directly from that origin — leaking client IP, User-Agent, and Referer headers. Set to `false` to suppress the redirect; the IdP-supplied URL is still stored, but Open WebUI serves the bundled default image instead. **Recommendation:** disable unless your IdP returns avatars as `data:` URIs (which Open WebUI persists locally and is unaffected) or you accept the leak in exchange for showing IdP-hosted avatars. See [`ENABLE_PROFILE_IMAGE_URL_FORWARDING`](/reference/env-configuration#enable_profile_image_url_forwarding) for full semantics. |
+| `ENABLE_PROFILE_IMAGE_URL_FORWARDING` | `true` | When `true`, the backend issues a `302` redirect from `/api/v1/users/{id}/profile/image` to whatever external URL the IdP wrote into `profile_image_url`. Each browser then loads the avatar directly from that origin, leaking client IP, User-Agent, and Referer headers. Set to `false` to suppress the redirect; the IdP-supplied URL is still stored, but Open WebUI serves the bundled default image instead. **Recommendation:** disable unless your IdP returns avatars as `data:` URIs (which Open WebUI persists locally and is unaffected) or you accept the leak in exchange for showing IdP-hosted avatars. See [`ENABLE_PROFILE_IMAGE_URL_FORWARDING`](/reference/env-configuration#enable_profile_image_url_forwarding) for full semantics. |
| `WEBUI_AUTH_SIGNOUT_REDIRECT_URL` | *empty* | Redirect users to this URL after signout. E.g., `https://your-company.com/logout-success` |
-| `WEBUI_SECRET_KEY` | *empty* | MUST be set - especially in clustered environments. Otherwise session issues and weird OAuth issues will occur |
+| `WEBUI_SECRET_KEY` | *empty* | MUST be set, especially in clustered environments. Otherwise session issues and weird OAuth issues will occur |
| `OAUTH_SESSION_TOKEN_ENCRYPTION_KEY` | `WEBUI_SECRET_KEY` | A secret key for encrypting OAuth tokens stored on the server. Must be shared across all instances in a cluster. |
-| `OAUTH_CLIENT_INFO_ENCRYPTION_KEY` | `WEBUI_SECRET_KEY` | A secret key for encrypting OAuth client information stored on the server - used for OAuth 2.1 authentication for MCP servers. |
+| `OAUTH_CLIENT_INFO_ENCRYPTION_KEY` | `WEBUI_SECRET_KEY` | A secret key for encrypting OAuth client information stored on the server, used for OAuth 2.1 authentication for MCP servers. |
| `ENABLE_OAUTH_ID_TOKEN_COOKIE` | `true` | For backward compatibility. Controls if the legacy `oauth_id_token` cookie is set. Recommended to set to `false`. |
| `ENABLE_OAUTH_TOKEN_EXCHANGE` | `false` | Enables the token exchange endpoint for external apps to exchange OAuth tokens for Open WebUI JWTs. |
| `ENABLE_OAUTH_BACKCHANNEL_LOGOUT` | `false` | Enables OIDC Back-Channel Logout endpoint (`POST /oauth/backchannel-logout`) for IdP-initiated logout. Requires Redis for JWT revocation. |
@@ -113,13 +113,13 @@ The allowed redirect URI should include `/oauth/google/callback`.
The following environment variables are required:
-1. `GOOGLE_CLIENT_ID` - Google OAuth client ID
-1. `GOOGLE_CLIENT_SECRET` - Google OAuth client secret
-1. `OPENID_PROVIDER_URL` - Must be set for logout to work properly. (Usually to `https://accounts.google.com/.well-known/openid-configuration`)
+1. `GOOGLE_CLIENT_ID`: Google OAuth client ID
+1. `GOOGLE_CLIENT_SECRET`: Google OAuth client secret
+1. `OPENID_PROVIDER_URL`: Must be set for logout to work properly. (Usually to `https://accounts.google.com/.well-known/openid-configuration`)
Optional Google-specific setting:
-1. `GOOGLE_OAUTH_AUTHORIZE_PARAMS` - JSON object for extra Google `/authorize` params (for example `prompt`, `login_hint`, `hd`).
+1. `GOOGLE_OAUTH_AUTHORIZE_PARAMS`: JSON object for extra Google `/authorize` params (for example `prompt`, `login_hint`, `hd`).
```bash
GOOGLE_OAUTH_AUTHORIZE_PARAMS={"prompt":"consent","login_hint":"user@example.com","hd":"example.com"}
@@ -134,15 +134,15 @@ Support for Microsoft OAuth is currently limited to a single tenant, that is a s
The following environment variables are required:
-1. `MICROSOFT_CLIENT_ID` - Microsoft OAuth client ID
-1. `MICROSOFT_CLIENT_SECRET` - Microsoft OAuth client secret
-1. `MICROSOFT_CLIENT_TENANT_ID` - Microsoft tenant ID - use `9188040d-6c67-4c5b-b112-36a304b66dad` for personal accounts
-1. `MICROSOFT_REDIRECT_URI` - The redirect URI configured in your Microsoft OAuth application. This must be set to `/oauth/microsoft/callback`.
-1. `OPENID_PROVIDER_URL` - Must be set for logout to work properly.
+1. `MICROSOFT_CLIENT_ID`: Microsoft OAuth client ID
+1. `MICROSOFT_CLIENT_SECRET`: Microsoft OAuth client secret
+1. `MICROSOFT_CLIENT_TENANT_ID`: Microsoft tenant ID, use `9188040d-6c67-4c5b-b112-36a304b66dad` for personal accounts
+1. `MICROSOFT_REDIRECT_URI`: The redirect URI configured in your Microsoft OAuth application. This must be set to `/oauth/microsoft/callback`.
+1. `OPENID_PROVIDER_URL`: Must be set for logout to work properly.
#### Token Refresh (`offline_access`)
-By default, Microsoft's identity platform only returns an `access_token`, which expires after approximately 1 hour. To enable automatic token refresh — preventing users from needing to re-authenticate — add the `offline_access` scope:
+By default, Microsoft's identity platform only returns an `access_token`, which expires after approximately 1 hour. To enable automatic token refresh (preventing users from needing to re-authenticate) add the `offline_access` scope:
```
MICROSOFT_OAUTH_SCOPE=openid email profile offline_access
@@ -175,7 +175,7 @@ No additional configuration is required in Microsoft Entra ID. The `offline_acce
:::tip Role Mapping with Microsoft Entra ID
-If you use Entra ID **app roles** to control who gets `admin` vs `user` access in Open WebUI, you also need to configure [OAuth Role Management](#oauth-role-management) below. In particular, make sure you set `OAUTH_ALLOWED_ROLES` and `OAUTH_ADMIN_ROLES` in addition to `ENABLE_OAUTH_ROLE_MANAGEMENT=true` — otherwise all users will be created with the default role regardless of their Entra ID assignment.
+If you use Entra ID **app roles** to control who gets `admin` vs `user` access in Open WebUI, you also need to configure [OAuth Role Management](#oauth-role-management) below. In particular, make sure you set `OAUTH_ALLOWED_ROLES` and `OAUTH_ADMIN_ROLES` in addition to `ENABLE_OAUTH_ROLE_MANAGEMENT=true`. Otherwise all users will be created with the default role regardless of their Entra ID assignment.
:::
@@ -186,8 +186,8 @@ The allowed redirect URI should include `/oauth/github/callback`.
The following environment variables are required:
-1. `GITHUB_CLIENT_ID` - GitHub OAuth App Client ID
-1. `GITHUB_CLIENT_SECRET` - GitHub OAuth App Client Secret
+1. `GITHUB_CLIENT_ID`: GitHub OAuth App Client ID
+1. `GITHUB_CLIENT_SECRET`: GitHub OAuth App Client Secret
### OIDC
@@ -198,20 +198,20 @@ The allowed redirect URI should include `/oauth/oidc/callback`.
The following environment variables are used:
-1. `OAUTH_CLIENT_ID` - OIDC client ID
-1. `OAUTH_CLIENT_SECRET` - OIDC client secret
-1. `OPENID_PROVIDER_URL` - **Required.** OIDC well known URL, for example `https://accounts.google.com/.well-known/openid-configuration`
-1. `OAUTH_PROVIDER_NAME` - Name of the provider to show on the UI, defaults to SSO
-1. `OAUTH_SCOPES` - Scopes to request. Defaults to `openid email profile`
-1. `OPENID_REDIRECT_URI` - The redirect URI configured in your OIDC application. This must be set to `/oauth/oidc/callback`.
-1. `OAUTH_AUDIENCE` - Optional `audience` value that will be passed to the oauth provider's authorization endpoint as an additional query parameter.
+1. `OAUTH_CLIENT_ID`: OIDC client ID
+1. `OAUTH_CLIENT_SECRET`: OIDC client secret
+1. `OPENID_PROVIDER_URL`: **Required.** OIDC well known URL, for example `https://accounts.google.com/.well-known/openid-configuration`
+1. `OAUTH_PROVIDER_NAME`: Name of the provider to show on the UI, defaults to SSO
+1. `OAUTH_SCOPES`: Scopes to request. Defaults to `openid email profile`
+1. `OPENID_REDIRECT_URI`: The redirect URI configured in your OIDC application. This must be set to `/oauth/oidc/callback`.
+1. `OAUTH_AUDIENCE`: Optional `audience` value that will be passed to the oauth provider's authorization endpoint as an additional query parameter.
:::warning
**Common OIDC Mistakes:**
- Using non-existent environment variables like `OIDC_CONFIG` or `WEBUI_OIDC_CLIENT_ID`
- Forgetting to set `OPENID_PROVIDER_URL` (this is mandatory for OIDC)
-- Using incorrect redirect URI format - must be exactly `/oauth/oidc/callback`
+- Using incorrect redirect URI format, must be exactly `/oauth/oidc/callback`
:::
@@ -224,10 +224,10 @@ Any OAuth provider that can be configured to return roles in the access token ca
To use this feature set `ENABLE_OAUTH_ROLE_MANAGEMENT` to `true`.
You can configure the following environment variables to match the roles returned by the OAuth provider:
-1. `OAUTH_ROLES_CLAIM` - The claim that contains the roles. Defaults to `roles`. Can also be nested, for example `user.roles`.
-1. `OAUTH_ALLOWED_ROLES` - A comma-separated list of roles that are allowed to log in (receive open webui role `user`). Use `*` as a wildcard to allow any role.
-1. `OAUTH_ADMIN_ROLES` - A comma-separated list of roles that are allowed to log in as an admin (receive open webui role `admin`).
-1. `OAUTH_ROLES_SEPARATOR` - Allows specifying an alternative separator for the `OAUTH_*_ROLES` variables. If the claim is a string and it contains the separator, it will be also split by that separator.
+1. `OAUTH_ROLES_CLAIM`: The claim that contains the roles. Defaults to `roles`. Can also be nested, for example `user.roles`.
+1. `OAUTH_ALLOWED_ROLES`: A comma-separated list of roles that are allowed to log in (receive open webui role `user`). Use `*` as a wildcard to allow any role.
+1. `OAUTH_ADMIN_ROLES`: A comma-separated list of roles that are allowed to log in as an admin (receive open webui role `admin`).
+1. `OAUTH_ROLES_SEPARATOR`: Allows specifying an alternative separator for the `OAUTH_*_ROLES` variables. If the claim is a string and it contains the separator, it will be also split by that separator.
:::info
@@ -242,9 +242,9 @@ To enable this synchronization, set `ENABLE_OAUTH_GROUP_MANAGEMENT` to `true`.
You can configure the following environment variables:
-1. `OAUTH_GROUP_CLAIM` - The claim in the ID/access token containing the user's group memberships. Defaults to `groups`. Can also be nested, for example `user.memberOf`. Required if `ENABLE_OAUTH_GROUP_MANAGEMENT` is true.
-1. `ENABLE_OAUTH_GROUP_CREATION` - If `true` (and `ENABLE_OAUTH_GROUP_MANAGEMENT` is also `true`), Open WebUI will perform **Just-in-Time (JIT) group creation**. This means it will automatically create groups during OAuth login if they are present in the user's OAuth claims but do not yet exist in the system. Defaults to `false`. If `false`, only memberships in *existing* Open WebUI groups will be managed.
-1. `OAUTH_GROUP_DEFAULT_SHARE` - Controls the default sharing permission for groups created via JIT group creation. Defaults to `true` (share with anyone). Set to `members` to restrict sharing to group members only, or `false` to disable sharing entirely. Only applies when `ENABLE_OAUTH_GROUP_CREATION` is enabled.
+1. `OAUTH_GROUP_CLAIM`: The claim in the ID/access token containing the user's group memberships. Defaults to `groups`. Can also be nested, for example `user.memberOf`. Required if `ENABLE_OAUTH_GROUP_MANAGEMENT` is true.
+1. `ENABLE_OAUTH_GROUP_CREATION`: If `true` (and `ENABLE_OAUTH_GROUP_MANAGEMENT` is also `true`), Open WebUI will perform **Just-in-Time (JIT) group creation**. This means it will automatically create groups during OAuth login if they are present in the user's OAuth claims but do not yet exist in the system. Defaults to `false`. If `false`, only memberships in *existing* Open WebUI groups will be managed.
+1. `OAUTH_GROUP_DEFAULT_SHARE`: Controls the default sharing permission for groups created via JIT group creation. Defaults to `true` (share with anyone). Set to `members` to restrict sharing to group members only, or `false` to disable sharing entirely. Only applies when `ENABLE_OAUTH_GROUP_CREATION` is enabled.
:::warning
@@ -316,7 +316,7 @@ You can use the `WEBUI_AUTH_TRUSTED_ROLE_HEADER` environment variable to control
:::warning
-When configured, this header allows clients to set admin-level access via an HTTP header. You **must** ensure that only your trusted reverse proxy or identity provider can set this header. Allowing untrusted clients to reach Open WebUI directly would let anyone escalate to admin. This is the same security model as the other trusted headers — see the warning at the top of this section.
+When configured, this header allows clients to set admin-level access via an HTTP header. You **must** ensure that only your trusted reverse proxy or identity provider can set this header. Allowing untrusted clients to reach Open WebUI directly would let anyone escalate to admin. This is the same security model as the other trusted headers; see the warning at the top of this section.
:::
diff --git a/docs/features/authentication-access/index.mdx b/docs/features/authentication-access/index.mdx
index 6b3483b60..1879ca2d6 100644
--- a/docs/features/authentication-access/index.mdx
+++ b/docs/features/authentication-access/index.mdx
@@ -3,8 +3,20 @@ sidebar_position: 0
title: "Authentication & Access"
---
+import ThemedImage from '@theme/ThemedImage';
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
# 🔐 Authentication & Access
+
+
**Control who gets in, what they can do, and how your instance integrates with your identity stack.**
Open WebUI is multi-user from day one. Whether you're running a personal instance or managing thousands of seats across an organization, you have full control over authentication, authorization, and programmatic access. Connect your identity provider, define granular permissions, and automate user lifecycle management, all without touching a line of code.
diff --git a/docs/features/authentication-access/rbac/groups.md b/docs/features/authentication-access/rbac/groups.md
index e6db919e6..31cf2b0e1 100644
--- a/docs/features/authentication-access/rbac/groups.md
+++ b/docs/features/authentication-access/rbac/groups.md
@@ -77,8 +77,8 @@ Beyond visibility, knowledge access is also scoped by model configuration. When
At a deeper level, resource access is managed through normalized **access grants** stored in the database. Each grant specifies:
* **Resource**: The type and ID of the resource (e.g., a specific model or knowledge base).
-* **Principal**: Who receives access — either a **group** or an **individual user**.
-* **Permission**: The level of access — `read` or `write`.
+* **Principal**: Who receives access, either a **group** or an **individual user**.
+* **Permission**: The level of access, `read` or `write`.
For example, granting the "Marketing" group read access and a specific editor user write access to a model would create two separate grant entries. Public access is represented by a user grant with a wildcard (`*`) principal.
@@ -87,15 +87,15 @@ For example, granting the "Marketing" group read access and a specific editor us
### Previewing Access (Audit)
-When access grants span many groups and resources, it's easy to lose track of who can see what. Open WebUI ships an admin-only **Preview Access** view that resolves every access grant for a specific user or group and lists the result in one place — no need to crawl through individual resource pages.
+When access grants span many groups and resources, it's easy to lose track of who can see what. Open WebUI ships an admin-only **Preview Access** view that resolves every access grant for a specific user or group and lists the result in one place, no need to crawl through individual resource pages.
-**For a user** — In **Admin Panel > Users**, hover over a non-admin user row and click the eye-style **Preview Access** button. The modal shows every model, knowledge base, and tool the user can read, aggregated across all of their group memberships and any direct user grants.
+**For a user**: In **Admin Panel > Users**, hover over a non-admin user row and click the eye-style **Preview Access** button. The modal shows every model, knowledge base, and tool the user can read, aggregated across all of their group memberships and any direct user grants.
-**For a group** — In **Admin Panel > Users > Groups**, open the group editor and use the **Preview Group Access** panel. The output is the same shape (models, knowledge, tools), scoped to just that group's grants.
+**For a group**: In **Admin Panel > Users > Groups**, open the group editor and use the **Preview Group Access** panel. The output is the same shape (models, knowledge, tools), scoped to just that group's grants.
-Both views are admin-only and read-only — they reflect what the access-grant table currently says without modifying it. Use them after a permission change to confirm the result matches intent, or as part of a periodic RBAC audit.
+Both views are admin-only and read-only: they reflect what the access-grant table currently says without modifying it. Use them after a permission change to confirm the result matches intent, or as part of a periodic RBAC audit.
Programmatic equivalents:
-- `GET /api/v1/users/{user_id}/preview` — user view (admin auth required)
-- `GET /api/v1/groups/id/{id}/preview` — group view (admin auth required)
+- `GET /api/v1/users/{user_id}/preview`: user view (admin auth required)
+- `GET /api/v1/groups/id/{id}/preview`: group view (admin auth required)
diff --git a/docs/features/authentication-access/rbac/index.mdx b/docs/features/authentication-access/rbac/index.mdx
index 52c0c6b1f..aab091014 100644
--- a/docs/features/authentication-access/rbac/index.mdx
+++ b/docs/features/authentication-access/rbac/index.mdx
@@ -35,4 +35,4 @@ Avoid configuring management/master keys for general user traffic unless your de
* [🔐 **Groups**](./groups.md)
* Learn how to structure teams and projects.
* **Strategy**: Distinguish between "Permission Groups" (for rights) and "Sharing Groups" (for access).
- * Manage Access Control Lists (ACLs) for private Models and Knowledge — share with groups or individual users.
+ * Manage Access Control Lists (ACLs) for private Models and Knowledge: share with groups or individual users.
diff --git a/docs/features/authentication-access/rbac/permissions.md b/docs/features/authentication-access/rbac/permissions.md
index 6c9f07820..e3ba2c34b 100644
--- a/docs/features/authentication-access/rbac/permissions.md
+++ b/docs/features/authentication-access/rbac/permissions.md
@@ -77,8 +77,9 @@ Controls what users can share with the community or make public.
| **Public Skills** | *(Requires Share Skills)* Ability to make skills public. |
| **Share Notes** | **(Parent)** Ability to share Notes. |
| **Public Notes** | *(Requires Share Notes)* Ability to make Notes public. |
+| **Folders Sharing** | Ability to share a chat folder (and the chats inside it) with specific users or groups, with read or write access. Subfolders inherit the share, and folders cannot be shared publicly. Admins are always exempt. |
| **Chats Public Sharing** | *(Requires Share Chat)* Ability to make a chat share link reachable by anyone (including unauthenticated visitors). When disabled, users can still share chats with specific users or groups via the access-control selector, but the "Public" option is hidden for non-admins. Admins are always exempt. |
-| **Calendars Public Sharing** | *(Requires Features > Calendar)* Ability to make a calendar publicly readable or writable by every user with the Calendar feature. When disabled, wildcard access grants are stripped from calendar create/update payloads — owners can still share with specific users or groups. Admins are always exempt. |
+| **Calendars Public Sharing** | *(Requires Features > Calendar)* Ability to make a calendar publicly readable or writable by every user with the Calendar feature. When disabled, wildcard access grants are stripped from calendar create/update payloads; owners can still share with specific users or groups. Admins are always exempt. |
### 3. Chat Permissions
Controls the features available to the user inside the chat interface.
@@ -98,6 +99,7 @@ Controls the features available to the user inside the chat interface.
| **Rate Response** | Ability to thumbs up/down responses. |
| **Share Chat** | Ability to generate a share link for a chat. |
| **Export Chat** | Ability to export chat history. |
+| **Allow Chat Import** | Ability to import chats (upload a previously exported chat back into Open WebUI). |
| **Speech-to-Text (STT)**| Ability to use voice input. |
| **Text-to-Speech (TTS)**| Ability to use voice output. |
| **Audio Call** | Ability to use the real-time audio call feature. |
@@ -121,6 +123,7 @@ Controls access to broad platform capabilities.
| **Memories** | Access to the Memories feature for persistent user context. |
| **Automations** | Ability for non-admin users to access the Automations page and create, edit, run, pause, or delete their own scheduled automations. |
| **Calendar** | Access to the Calendar feature for creating calendars, managing events, and viewing shared calendars. |
+| **User Webhooks** | Ability for users to set their own personal webhook URL (under **Settings > Account**) for notifications. Disabled by default. |
:::info Automations Permission Scope
diff --git a/docs/features/calendar/index.md b/docs/features/calendar/index.md
index bd9d0bbe3..680ba7a21 100644
--- a/docs/features/calendar/index.md
+++ b/docs/features/calendar/index.md
@@ -3,8 +3,20 @@ sidebar_position: 2
title: "Calendar"
---
+import ThemedImage from '@theme/ThemedImage';
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
# 📅 Calendar
+
+
**Schedule, track, and manage events, with AI that can plan for you.**
Calendar is a built-in scheduling feature that gives every user a personal calendar. Create events, set recurring schedules, share calendars with teammates, and let AI models autonomously create and manage events through natural conversation.
@@ -196,7 +208,7 @@ Calendars support the same access grant system used by knowledge bases, models,
Only the calendar **owner** (or an admin) can manage access grants and delete the calendar itself.
:::info Public sharing is permission-gated
-Wildcard access grants (calendar readable or writable by every user with the Calendar feature) are gated by the **Calendars Public Sharing** permission. When disabled for a non-admin owner, public principals are silently stripped from the access grant list on calendar create/update — per-user and per-group grants remain unaffected. Admins always retain the ability to share publicly. Configurable per-group in **Admin Panel → Users → Groups → Permissions** or via [`USER_PERMISSIONS_CALENDAR_ALLOW_PUBLIC_SHARING`](/reference/env-configuration#user_permissions_calendar_allow_public_sharing).
+Wildcard access grants (calendar readable or writable by every user with the Calendar feature) are gated by the **Calendars Public Sharing** permission. When disabled for a non-admin owner, public principals are silently stripped from the access grant list on calendar create/update; per-user and per-group grants remain unaffected. Admins always retain the ability to share publicly. Configurable per-group in **Admin Panel → Users → Groups → Permissions** or via [`USER_PERMISSIONS_CALENDAR_ALLOW_PUBLIC_SHARING`](/reference/env-configuration#user_permissions_calendar_allow_public_sharing).
:::
---
diff --git a/docs/features/channels/index.md b/docs/features/channels/index.md
index 08c75e004..d20b04dbf 100644
--- a/docs/features/channels/index.md
+++ b/docs/features/channels/index.md
@@ -3,8 +3,20 @@ sidebar_position: 1000
title: "Channels"
---
+import ThemedImage from '@theme/ThemedImage';
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
# 💬 Channels
+
+
**Where your team and AI think together, in real time.**
Channels are persistent, shared spaces where humans and AI models participate in the same conversation. Unlike standard chats, which are personal and isolated, Channels let multiple users and multiple models interact in a single timeline. Every exchange, whether human or AI, becomes shared context that the whole team can build on.
@@ -83,10 +95,10 @@ Mentioning a model in a channel runs through the same chat-completion pipeline a
| **Knowledge (RAG)** | Knowledge bases attached to the model are queried and injected |
| **Attached documents** | Images **and** non-image files (PDF, DOCX, etc.) uploaded in the thread are forwarded into the model's context |
-In other words, a channel-summoned model is a fully-equipped agent — not a one-shot completion.
+In other words, a channel-summoned model is a fully-equipped agent, not a one-shot completion.
:::note Document attachments in channels (v0.9.6+)
-Before v0.9.6, tagging a model in a channel only forwarded **images** from the thread — uploaded PDFs, DOCX, and other non-image documents were ignored, so summarization and document-comparison prompts silently had nothing to work with. As of v0.9.6 these files are forwarded the same way they are in a direct chat, so document workflows behave identically in channels.
+Before v0.9.6, tagging a model in a channel only forwarded **images** from the thread. Uploaded PDFs, DOCX, and other non-image documents were ignored, so summarization and document-comparison prompts silently had nothing to work with. As of v0.9.6 these files are forwarded the same way they are in a direct chat, so document workflows behave identically in channels.
:::
### Tagging people and linking channels
diff --git a/docs/features/chat-conversations/audio/_category_.json b/docs/features/chat-conversations/audio/_category_.json
index 28ec5e6b0..286bd2c05 100644
--- a/docs/features/chat-conversations/audio/_category_.json
+++ b/docs/features/chat-conversations/audio/_category_.json
@@ -1,8 +1,4 @@
{
"label": "Speech-to-Text & Text-to-Speech",
- "position": 500,
- "link": {
- "type": "generated-index",
- "slug": "/features/chat-conversations/audio"
- }
+ "position": 500
}
diff --git a/docs/features/chat-conversations/audio/index.mdx b/docs/features/chat-conversations/audio/index.mdx
new file mode 100644
index 000000000..7aa721b07
--- /dev/null
+++ b/docs/features/chat-conversations/audio/index.mdx
@@ -0,0 +1,24 @@
+---
+title: "Speech-to-Text & Text-to-Speech"
+sidebar_position: 0
+slug: /features/chat-conversations/audio
+---
+
+import ThemedImage from '@theme/ThemedImage';
+import useBaseUrl from '@docusaurus/useBaseUrl';
+import DocCardList from '@theme/DocCardList';
+
+# 🎙️ Audio
+
+
+
+Talk to Open WebUI and have it talk back. Dictate with speech-to-text and hear responses with text-to-speech, across a range of engines and voices.
+
+
diff --git a/docs/features/chat-conversations/audio/speech-to-text/env-variables.md b/docs/features/chat-conversations/audio/speech-to-text/env-variables.md
index 398fc6fa2..7abd80b44 100644
--- a/docs/features/chat-conversations/audio/speech-to-text/env-variables.md
+++ b/docs/features/chat-conversations/audio/speech-to-text/env-variables.md
@@ -38,10 +38,10 @@ Most of these settings can also be configured in the **Admin Panel → Settings
| `WHISPER_VAD_FILTER` | Enable Voice Activity Detection filter | `false` |
:::info WHISPER_COMPUTE_TYPE Options
-- `int8` — CPU default, fastest but may not work on older GPUs
-- `float16` — **Recommended for CUDA/GPU**
-- `int8_float16` — Hybrid mode (int8 weights, float16 computation)
-- `float32` — Maximum compatibility, slowest
+- `int8`: CPU default, fastest but may not work on older GPUs
+- `float16`: **Recommended for CUDA/GPU**
+- `int8_float16`: Hybrid mode (int8 weights, float16 computation)
+- `float32`: Maximum compatibility, slowest
If using the `:cuda` Docker image with an older GPU, set `WHISPER_COMPUTE_TYPE=float16` to avoid errors.
:::
diff --git a/docs/features/chat-conversations/audio/speech-to-text/stt-config.md b/docs/features/chat-conversations/audio/speech-to-text/stt-config.md
index 9d2134714..81d80c594 100644
--- a/docs/features/chat-conversations/audio/speech-to-text/stt-config.md
+++ b/docs/features/chat-conversations/audio/speech-to-text/stt-config.md
@@ -18,8 +18,8 @@ The following speech-to-text providers are supported:
| Local Whisper (default) | ❌ | Built-in, see [Environment Variables](/features/chat-conversations/audio/speech-to-text/env-variables) |
| OpenAI (Whisper API) | ✅ | [OpenAI STT Guide](/features/chat-conversations/audio/speech-to-text/openai-stt-integration) |
| Mistral (Voxtral) | ✅ | [Mistral Voxtral Guide](/features/chat-conversations/audio/speech-to-text/mistral-voxtral-integration) |
-| Deepgram | ✅ | — |
-| Azure | ✅ | — |
+| Deepgram | ✅ | N/A |
+| Azure | ✅ | N/A |
**Web API** provides STT via the browser's built-in speech recognition (no API key needed, configured in user settings).
@@ -78,8 +78,8 @@ Once your recording has begun you can:
If you see an error like `Error transcribing chunk: Requested int8 compute type, but the target device or backend do not support efficient int8 computation`, this usually means your GPU doesn't support the requested `int8` compute operations.
**Solutions:**
-- **Upgrade to the latest version** — persistent configuration for compute type has been improved in recent updates to resolve known issues with CUDA compatibility.
-- **Switch to the standard Docker image** instead of the `:cuda` image — older GPUs (Maxwell architecture, ~2014-2016) may not be supported by modern CUDA accelerated libraries.
+- **Upgrade to the latest version:** persistent configuration for compute type has been improved in recent updates to resolve known issues with CUDA compatibility.
+- **Switch to the standard Docker image** instead of the `:cuda` image. Older GPUs (Maxwell architecture, ~2014-2016) may not be supported by modern CUDA accelerated libraries.
- **Change the compute type** using the `WHISPER_COMPUTE_TYPE` environment variable:
```yaml
environment:
@@ -92,15 +92,15 @@ For smaller models like Whisper, CPU mode often provides comparable performance
#### Microphone Not Working
-1. **Check browser permissions** — ensure your browser has microphone access
-2. **Use HTTPS** — some browsers require secure connections for microphone access
-3. **Try another browser** — Chrome typically has the best support for web audio APIs
+1. **Check browser permissions:** ensure your browser has microphone access
+2. **Use HTTPS:** some browsers require secure connections for microphone access
+3. **Try another browser:** Chrome typically has the best support for web audio APIs
#### Poor Recognition Accuracy
- **Set the language explicitly** using `WHISPER_LANGUAGE=en` (uses ISO 639-1 codes)
-- **Toggles multilingual support** — Use `WHISPER_MULTILINGUAL=true` if you need to support languages other than English. When disabled (default), only the English-only variant of the model is used for better performance in English tasks.
-- **Use a larger Whisper model** — options: `tiny`, `base`, `small`, `medium`, `large`
+- **Toggles multilingual support:** use `WHISPER_MULTILINGUAL=true` if you need to support languages other than English. When disabled (default), only the English-only variant of the model is used for better performance in English tasks.
+- **Use a larger Whisper model:** options: `tiny`, `base`, `small`, `medium`, `large`
- Larger models are more accurate but slower
For more detailed troubleshooting, see the [Audio Troubleshooting Guide](/troubleshooting/audio).
diff --git a/docs/features/chat-conversations/audio/text-to-speech/Kokoro-FastAPI-integration.md b/docs/features/chat-conversations/audio/text-to-speech/Kokoro-FastAPI-integration.md
index 2331cd6eb..48f4819ef 100644
--- a/docs/features/chat-conversations/audio/text-to-speech/Kokoro-FastAPI-integration.md
+++ b/docs/features/chat-conversations/audio/text-to-speech/Kokoro-FastAPI-integration.md
@@ -164,15 +164,15 @@ If the GPU version isn't using your GPU:
If Open WebUI can't reach Kokoro, this is usually a Docker networking issue. Choose the method that matches your setup:
-**Option 1 — Docker Desktop (Windows/Mac):**
+**Option 1, Docker Desktop (Windows/Mac):**
Use `host.docker.internal` instead of `localhost`:http://host.docker.internal:8880/v1
-**Option 2 — Docker Compose (same network):**
+**Option 2, Docker Compose (same network):**
Use the service name directly:http://kokoro-fastapi-gpu:8880/v1
-**Option 3 — Docker Network (recommended for Linux):**
+**Option 3, Docker Network (recommended for Linux):**
If `host.docker.internal` doesn't work, create a shared Docker network:
diff --git a/docs/features/chat-conversations/audio/text-to-speech/chatterbox-tts-api-integration.md b/docs/features/chat-conversations/audio/text-to-speech/chatterbox-tts-api-integration.md
index f59646852..c789fedc6 100644
--- a/docs/features/chat-conversations/audio/text-to-speech/chatterbox-tts-api-integration.md
+++ b/docs/features/chat-conversations/audio/text-to-speech/chatterbox-tts-api-integration.md
@@ -1,9 +1,9 @@
---
sidebar_position: 3
-title: "Chatterbox TTS — Voice Cloning"
+title: "Chatterbox TTS: Voice Cloning"
---
-# Chatterbox TTS — Voice Cloning
+# Chatterbox TTS: Voice Cloning
:::warning
@@ -19,7 +19,7 @@ This tutorial is a community contribution and is not supported by the Open WebUI
## Key Features
-- Zero-shot voice cloning — only ~10 seconds of any voice sample needed
+- Zero-shot voice cloning: only ~10 seconds of any voice sample needed
- [Outperforms ElevenLabs](https://podonos.com/resembleai/chatterbox)
- Watermarked outputs for responsible voice cloning
- 0.5B Llama backbone
@@ -32,7 +32,7 @@ This tutorial is a community contribution and is not supported by the Open WebUI
- Memory: 4GB minimum, 8GB+ recommended
- GPU: CUDA (Nvidia), Apple M-series (MPS)
-- CPU: Works but slower — GPU recommended for production
+- CPU: Works but slower, GPU recommended for production
:::info
@@ -44,7 +44,7 @@ Chatterbox can use a good deal of memory and has hardware requirements that migh
### 🐍 Using Python
-#### Option A: Using uv (Recommended - Faster & Better Dependencies)
+#### Option A: Using uv (Recommended, Faster & Better Dependencies)
```bash
@@ -250,7 +250,7 @@ If you experience memory issues, consider using a lighter alternative like [Open
If Open WebUI can't connect to Chatterbox:
-- **Docker Desktop:** Use `http://host.docker.internal:4123/v1`
+- **Docker Desktop:** Use `http://host.docker.internal:4123/v1`
- **Docker Compose:** Use `http://chatterbox-tts-api:4123/v1`
- **Linux:** Use your host machine's IP address
diff --git a/docs/features/chat-conversations/chat-features/chatshare.md b/docs/features/chat-conversations/chat-features/chatshare.md
index 8add6b87f..92f98af3c 100644
--- a/docs/features/chat-conversations/chat-features/chatshare.md
+++ b/docs/features/chat-conversations/chat-features/chatshare.md
@@ -30,7 +30,7 @@ To share a chat:
:::info Sharing scope is controlled by RBAC
-After generating a share link, the modal shows an **Access Control** selector for who can open it. The **Public** option (anyone with the link, including unauthenticated visitors) is gated by the **Chats Public Sharing** permission — when disabled, non-admin users only see options to grant access to specific users or groups. Admins always retain access to all options. See [RBAC Permissions](/features/authentication-access/rbac/permissions) and [`USER_PERMISSIONS_CHAT_ALLOW_PUBLIC_SHARING`](/reference/env-configuration#user_permissions_chat_allow_public_sharing) for configuration.
+After generating a share link, the modal shows an **Access Control** selector for who can open it. The **Public** option (anyone with the link, including unauthenticated visitors) is gated by the **Chats Public Sharing** permission. When disabled, non-admin users only see options to grant access to specific users or groups. Admins always retain access to all options. See [RBAC Permissions](/features/authentication-access/rbac/permissions) and [`USER_PERMISSIONS_CHAT_ALLOW_PUBLIC_SHARING`](/reference/env-configuration#user_permissions_chat_allow_public_sharing) for configuration.
:::
diff --git a/docs/features/chat-conversations/chat-features/code-execution/artifacts.md b/docs/features/chat-conversations/chat-features/code-execution/artifacts.md
index 5d2bcd2fb..187a8e268 100644
--- a/docs/features/chat-conversations/chat-features/code-execution/artifacts.md
+++ b/docs/features/chat-conversations/chat-features/code-execution/artifacts.md
@@ -32,6 +32,22 @@ When Open WebUI creates an Artifact, you'll see the content displayed in a dedic
- **Updates**: Open WebUI may update an existing Artifact based on your messages. The Artifact window will display the latest content.
- **Actions**: Access additional actions for the Artifact, such as copying the content or opening the artifact in full screen, located in the lower right corner of the Artifact.
+## Securing artifact previews with a CSP
+
+Artifact previews render inside a sandboxed `srcdoc` iframe. For tighter control over what that generated HTML can do (outbound network calls, scripts, styles), inject a dedicated Content Security Policy into the preview with the [`IFRAME_CSP`](/reference/env-configuration#iframe_csp) environment variable, separate from the main app's `CONTENT_SECURITY_POLICY`.
+
+It is empty by default (the iframe `sandbox` already provides baseline isolation) and applies to **every** `srcdoc` iframe in the UI: Artifacts, code/HTML previews, file previews and citation modals. When set, Open WebUI prepends a `` tag to the iframe document, and per the CSP spec the first policy wins, so it overrides any CSP the generated HTML already declares. A reasonable starting point:
+
+```bash
+IFRAME_CSP=default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; connect-src 'none'
+```
+
+That keeps inline scripts and styles working (most artifacts need them) while blocking `fetch` / `XMLHttpRequest` / `WebSocket`, so an artifact cannot quietly call out to the network.
+
+:::tip Start permissive, then tighten
+An overly strict policy can make a preview appear blank, since many artifacts rely on inline `
```
-:::warning Requires `allowSameOrigin` — otherwise `window.args` is silently `undefined`
+:::warning Requires `allowSameOrigin`, otherwise `window.args` is silently `undefined`
The args are injected from the parent page via `iframe.contentWindow.args = ...`, which the browser blocks under same-origin policy unless the iframe sandbox carries `allow-same-origin`. That is gated by the per-user **Settings → Interface → "iframe Sandbox Allow Same Origin"** toggle, which is **off by default**. If `window.args` comes back undefined and you have not changed this setting, that is the cause: turn it on and reload. See [allowSameOrigin](#allowsameorigin) above for the security trade-off.
:::
:::note Where `window.args` is set, and where it is not
-- ✅ **Tool method returning `HTMLResponse` or `(HTMLResponse, context)` tuple** — rendered inline at the "View Result from..." tool call indicator. `window.args` is injected (subject to the `allowSameOrigin` requirement above).
-- ❌ **`__event_emitter__({"type": "embeds", "data": {"embeds": [...]}})`** — rendered through the chat-controls Embeds panel, which does not wire `args` at all. `window.args` will always be undefined here, regardless of sandbox settings. This is by design: the embeds-event path has no tool call attached, so there are no args to inject.
-- ❌ **Action embeds** — triggered by the user, not the model, so there are no model-supplied args to inject.
+- ✅ **Tool method returning `HTMLResponse` or `(HTMLResponse, context)` tuple**: rendered inline at the "View Result from..." tool call indicator. `window.args` is injected (subject to the `allowSameOrigin` requirement above).
+- ❌ **`__event_emitter__({"type": "embeds", "data": {"embeds": [...]}})`**: rendered through the chat-controls Embeds panel, which does not wire `args` at all. `window.args` will always be undefined here, regardless of sandbox settings. This is by design: the embeds-event path has no tool call attached, so there are no args to inject.
+- ❌ **Action embeds**: triggered by the user, not the model, so there are no model-supplied args to inject.
If you need to pass dynamic data into an embed rendered via either of the ❌ paths, use the [Payload Requests](#payload-requests) pattern above instead.
:::
### Auto-Injected Libraries
-When `allowSameOrigin` is enabled, the iframe component auto-detects usage of certain libraries in your HTML and injects them automatically — no CDN `