Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
141 changes: 141 additions & 0 deletions docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,141 @@
products:
- Alauda AI
kind:
- Solution
ProductsVersion:
- 4.x
---
Comment on lines +1 to +7
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Fix YAML front matter structure.

The YAML front matter has structural issues with indentation and key-value pairing. Lines 2-5 appear malformed.

📝 Proposed fix for YAML structure
 products:
-- Alauda AI
-  kind:
+  - Alauda AI
+kind:
 - Solution
-  ProductsVersion:
+productsVersion:
 - 4.x
 ---
🤖 Prompt for AI Agents
In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md` around lines 1 - 7, The
YAML front matter is malformed (incorrect indentation and list structure for
keys like products, kind, and ProductsVersion); fix it by converting the block
into valid YAML mapping: ensure "products:" maps to a list containing "Alauda
AI", "kind:" is a scalar with value "Solution", and "ProductsVersion:" is a
scalar with value "4.x" (i.e., replace the current alternating dash lines with
proper key: value and products: - Alauda AI structure) so the front matter
parses correctly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这个metada的格式不对啊,应该是:

---
products:
   - Alauda AI
kind:
   - Solution
ProductsVersion:
   - 4.x
---


# OpenWebUI

## Overview
OpenWebUI is an open-source AI Web interface that supports docking with multiple OpenAI protocol-compatible inference backends (such as vLLM, MLServer, XInference, etc.) through a unified entry point. It is used for scenarios such as text generation, multimodal input, and voice input. It provides an extensible external tool mechanism to facilitate the integration of retrieval, function calling, and third-party services. It is suitable for deployment in containers locally or in the cloud, supporting persistent data and Ingress-based HTTPS access.

## Basic Features
- **Conversation & Text Generation**: Support system prompts, adjustable parameters (temperature, length, etc.), and session management.
- **Multimodal & Voice**: Images/documents as context, voice input/transcription (dependent on backend capabilities).
- **External Tool Extension**: Can call retrieval, databases, HTTP APIs, etc., to build tool-enhanced workflows.
- **Data & Security**: Sessions and configurations can be persisted; can integrate with authentication, rate limiting, logging/monitoring.

## Backend Integration
- **Protocol Compatibility**: Support OpenAI API style backends (such as vLLM, MLServer, XInference, TGI, etc.).
- **Connection Parameters**: Base URL (e.g., `http(s)://{backend}/v1`), API Key, model name, and default inference parameters.
- **Multiple Backends**: configured in the UI, allowing switching between different inference service backends.

## Deployment Scheme
Create the following resources in order. In this case, choose an independent `open-webui-ns` namespace. You can choose an available namespace as needed.

### Namespace
```bash
kubectl create ns open-webui-ns
```

### Create the specific deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: open-webui
name: open-webui
namespace: open-webui-ns
spec:
replicas: 1
selector:
matchLabels:
app: open-webui
template:
metadata:
labels:
app: open-webui
spec:
volumes:
- name: webui-data
emptyDir: {}
Comment on lines +52 to +54
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Critical: emptyDir does not provide persistence.

The deployment uses emptyDir: {} for the webui-data volume, which is ephemeral storage. Data will be lost when the pod restarts, contradicting the "persistent data" claim in the overview (line 12).

💾 Proposed fix using PersistentVolumeClaim

First, create a PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: open-webui-pvc
  namespace: open-webui-ns
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Then update the Deployment:

       volumes:
       - name: webui-data
-        emptyDir: {}
+        persistentVolumeClaim:
+          claimName: open-webui-pvc
🤖 Prompt for AI Agents
In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md` around lines 52 - 54,
Replace the ephemeral emptyDir volume named webui-data with a
PersistentVolumeClaim: create a PVC manifest (e.g., metadata.name:
open-webui-pvc, namespace: open-webui-ns, spec.resources.requests.storage: 5Gi,
accessModes: [ReadWriteOnce]) and update the Deployment's volumes to reference
that claim (use persistentVolumeClaim.claimName: open-webui-pvc for the
webui-data volume) while leaving the existing volumeMounts unchanged; ensure the
PVC is applied to the cluster before deploying the Deployment so the pod can
bind to the persistent storage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

小兔子给的建议是,不要用 emtyDir,应该用pvc,你看下呢。 emtypDir, pod重启,数据就没了。

containers:
- image: ghcr.io/open-webui/open-webui
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

open-webui latest stable container image version ghcr.io

💡 Result:

Latest stable Open WebUI container image on GHCR is v0.7.2 (released 2026-01-10). [1]

Use:

  • ghcr.io/open-webui/open-webui:v0.7.2 [1]

(For production, Open WebUI recommends pinning a specific release tag like this rather than floating tags such as :main.) [2]


Pin the container image to a specific version.

The image ghcr.io/open-webui/open-webui has no tag specified, defaulting to :latest. This can cause unpredictable behavior and version drift in production deployments.

-      - image: ghcr.io/open-webui/open-webui
+      - image: ghcr.io/open-webui/open-webui:v0.7.2
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- image: ghcr.io/open-webui/open-webui
- image: ghcr.io/open-webui/open-webui:v0.7.2
🤖 Prompt for AI Agents
In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md` at line 56, The
deployment example currently uses the unpinned image reference
"ghcr.io/open-webui/open-webui" which defaults to :latest; update the image
declaration in the manifest (the line containing the image reference
"ghcr.io/open-webui/open-webui") to pin a specific version tag or immutable
digest (for example replace with "ghcr.io/open-webui/open-webui:vX.Y.Z" or
"@sha256:<digest>") to ensure reproducible, predictable deployments.

name: open-webui
ports:
- containerPort: 8080
env:
- name: ENABLE_DIRECT_CONNECTIONS
value: "true"
Comment on lines +61 to +62
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Document security implications of enabling direct connections.

Setting ENABLE_DIRECT_CONNECTIONS to "true" allows users to add arbitrary external inference service backends, which may have security implications (data exfiltration, credential exposure, cost implications). Consider adding a security note explaining when this should be enabled and what precautions to take.

📋 Suggested security guidance to add

Add a security considerations section after the deployment or in the environment variables section:

### Security Considerations

**ENABLE_DIRECT_CONNECTIONS**: When set to `true`, users can configure OpenWebUI to connect to external inference services. Consider the following:
- Only enable this in trusted environments or when users are authenticated and authorized
- External connections may expose sensitive data or credentials
- Monitor outbound connections to prevent data exfiltration
- Consider using network policies to restrict egress traffic
- For production environments, consider setting this to `false` and pre-configuring allowed backends
🤖 Prompt for AI Agents
In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md` around lines 61 - 62,
Add a short "Security Considerations" section after the deployment or
environment variables section that documents the risks of setting
ENABLE_DIRECT_CONNECTIONS to "true" and lists practical precautions: only enable
in trusted/authenticated environments, warn about data exfiltration and
credential exposure, advise monitoring outbound connections, suggest
egress/network policies, and recommend keeping it false in production or
pre-configuring allowed backends; reference ENABLE_DIRECT_CONNECTIONS by name in
the text so readers can correlate the guidance with the environment variable.

- name: OPENAI_API_BASE_URL
value: http://example-predictor/v1
Comment on lines +63 to +64
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Clarify that the URL is a placeholder example.

The value http://example-predictor/v1 is a placeholder that must be replaced. Consider adding a comment in the YAML or a warning in the documentation to prevent deploying this as-is.

         - name: OPENAI_API_BASE_URL
-          value: http://example-predictor/v1
+          value: http://example-predictor/v1  # REPLACE with actual inference service URL

Additionally, add a note in the documentation emphasizing this must be replaced with the actual service URL before deployment.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- name: OPENAI_API_BASE_URL
value: http://example-predictor/v1
- name: OPENAI_API_BASE_URL
value: http://example-predictor/v1 # REPLACE with actual inference service URL
🤖 Prompt for AI Agents
In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md` around lines 63 - 64,
The YAML snippet uses a placeholder value for OPENAI_API_BASE_URL
("http://example-predictor/v1") that must not be deployed as-is; update the docs
and the YAML example to mark this value explicitly as a placeholder (e.g., add a
comment inline in the YAML and a warning sentence in the surrounding
documentation) and add a short note telling users to replace OPENAI_API_BASE_URL
with their actual predictor/service URL before deployment; reference the
OPENAI_API_BASE_URL key and the placeholder value so reviewers can locate and
update the example and the descriptive text.

- name: PORT
value: "8080"
volumeMounts:
- name: webui-data
mountPath: /app/backend/data
resources:
requests:
cpu: 1000m
memory: 128Mi
limits:
cpu: 2000m
memory: 1Gi
```

## Important environment values

Relative environment values should be configured.

### ENABLE_DIRECT_CONNECTIONS
* Set to true to enable external connections.
* Purpose: Allows adding additional external inference service backends within OpenWebUI.

### OPENAI_API_BASE_URL
* Specifies the default inference service endpoint.
* If OpenWebUI and the inference service are deployed in the same cluster, use the service’s internal cluster address.
* For the address details, refer to: **AML Business View / Inference Service / Inference Service Details / Access Method**.
* Value format: `{{Cluster Internal URL}}/v1`.


### Verification
```bash
kubectl get deployment open-webui -n open-webui-ns -w
```
Wait until the deployment status is `1/1 Ready`.

## Access OpenWebUI

### 1. View OpenWebUI via NodePort Service
Create the following resource:

```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: open-webui
name: svc-open-webui
namespace: open-webui-ns
spec:
type: NodePort
ports:
- port: 8080
protocol: TCP
targetPort: 8080
selector:
app: open-webui
```
Check the relevant port and node IP to access the page.

### 2. Initial Settings
When accessing OpenWebUI for the first time, you need to register. Choose a strong password for the administrator account.

### 3. Add Inference Service
Go to **Settings -> Connections -> Add Connection**.
Here you will be required to add the inference service address.
You can obtain the cluster external access methods via **AML Business View / Inference Service / Inference Service Details / Access Method**.
Fill it in afterwards. Please use the cluster **external** access method.
In the **Add Connection** popup, fill in:
`{{Cluster External URL}}/v1`

Click the icon on the right to verify connectivity. After success, click save. Return to the chat page to select the existing inference service for use.

### 4. Use Inference Service
Enter the chat page, select the uploaded inference service, and explore more features, such as:
- Voice input
- Multimodal input
- External tools