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
142 changes: 142 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,142 @@
---
products:
- Alauda AI
kind:
- Solution
ProductsVersion:
- 4.x
---
Comment on lines +2 to +8
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.).
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 | 🟡 Minor

Minor wording consistency fixes for US English/style.

Use “OpenAI API-compatible” (or “API-style”) at Line 22, and “afterward” instead of “afterwards” at Line 132 for locale consistency.

Also applies to: 132-132

🧰 Tools
🪛 LanguageTool

[grammar] ~22-~22: Use a hyphen to join words.
Context: ...ocol Compatibility**: Support OpenAI API style backends (such as vLLM, MLServer, ...

(QB_NEW_EN_HYPHEN)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md` at line 22, Update
wording for US English/style in the documentation by replacing “OpenAI API style
backends” with “OpenAI API-compatible backends” (or “API-style”) where the
phrase appears (reference: the sentence beginning with “Protocol
Compatibility”), and change “afterwards” to “afterward” in the later paragraph
that uses that term (reference: the occurrence near the sentence around Line
132).

- **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: {}
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重启,数据就没了。

Copy link
Author

Choose a reason for hiding this comment

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

OCP 用的就是 emptyDir,这里和他一致吧,用户真正部署时,如果自己有 pvc 应该会调整的

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 +62 to +63
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 # REPLACE with actual inference service URL
- 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