feat: add openweb ui doc #122
Conversation
WalkthroughA new documentation file has been added detailing OpenWebUI deployment procedures and usage instructions. The guide covers deployment overview, basic features, backend integration, Kubernetes deployment workflow with manifest examples, environment variable configuration, verification steps, and initial setup guidance for accessing and configuring OpenWebUI services. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Tip 🧪 Unit Test Generation v2 is now available!We have significantly improved our unit test generation capabilities. To enable: Add this to your reviews:
finishing_touches:
unit_tests:
enabled: trueTry it out by using the Have feedback? Share your thoughts on our Discord thread! Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md`:
- Around line 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.
- Around line 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.
- Around line 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.
- Around line 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.
- 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.
🧹 Nitpick comments (6)
docs/en/solutions/How_to_Deploy_and_use_OpenWebUI.md (6)
12-12: Optional: Improve sentence variety.Three consecutive sentences in the overview begin with "It," which impacts readability slightly.
✍️ Suggested rewording
-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. +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. This interface is used for scenarios such as text generation, multimodal input, and voice input. The platform provides an extensible external tool mechanism to facilitate the integration of retrieval, function calling, and third-party services, and is suitable for deployment in containers locally or in the cloud, supporting persistent data and Ingress-based HTTPS access.
21-21: Optional: Use hyphenated compound modifier."OpenAI API style" should be hyphenated when used as a compound modifier.
-- **Protocol Compatibility**: Support OpenAI API style backends (such as vLLM, MLServer, XInference, TGI, etc.). +- **Protocol Compatibility**: Support OpenAI API-style backends (such as vLLM, MLServer, XInference, TGI, etc.).
87-91: Clarify the difference between internal and external URLs.The explanation mentions "internal cluster address" but could be clearer about when to use internal vs. external URLs. Consider adding an example to illustrate both scenarios.
📝 Suggested enhancement
### 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. + * Example internal URL: `http://inference-service.aml-namespace.svc.cluster.local/v1` * For the address details, refer to: **AML Business View / Inference Service / Inference Service Details / Access Method**. * Value format: `{{Cluster Internal URL}}/v1`.
94-98: Consider adding additional verification steps.The current verification only checks deployment status. Consider adding steps to verify pod health and connectivity to the inference backend.
🔍 Enhanced verification steps
### Verification ```bash kubectl get deployment open-webui -n open-webui-ns -wWait until the deployment status is
1/1 Ready.
+
+Verify the pod is running and check logs:
+bash +# Check pod status +kubectl get pods -n open-webui-ns -l app=open-webui + +# Check pod logs for any errors +kubectl logs -n open-webui-ns -l app=open-webui --tail=50 +</details> --- `100-122`: **Add guidance for production access methods.** The documentation only covers NodePort access, which exposes the service on all nodes and is not recommended for production. Consider adding guidance for production-ready access methods. <details> <summary>🌐 Suggested addition for production access</summary> Add a subsection after the NodePort service: ```markdown ### Alternative: Access via Ingress (Recommended for Production) For production environments, use an Ingress resource with TLS: ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: open-webui-ingress namespace: open-webui-ns annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: ingressClassName: nginx tls: - hosts: - open-webui.example.com secretName: open-webui-tls rules: - host: open-webui.example.com http: paths: - path: / pathType: Prefix backend: service: name: svc-open-webui port: number: 8080Note: Update the Service type to
ClusterIPwhen using Ingress.</details> --- `131-131`: **Optional: Use American English spelling.** "Afterwards" is British English; "afterward" is preferred in American English documentation. ```diff -Fill it in afterwards. Please use the cluster **external** access method. +Fill it in afterward. Please use the cluster **external** access method.
| products: | ||
| - Alauda AI | ||
| kind: | ||
| - Solution | ||
| ProductsVersion: | ||
| - 4.x | ||
| --- |
There was a problem hiding this comment.
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.
| volumes: | ||
| - name: webui-data | ||
| emptyDir: {} |
There was a problem hiding this comment.
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: 5GiThen 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.
| - name: webui-data | ||
| emptyDir: {} | ||
| containers: | ||
| - image: ghcr.io/open-webui/open-webui |
There was a problem hiding this comment.
🧩 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.
| - 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: ENABLE_DIRECT_CONNECTIONS | ||
| value: "true" |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 URLAdditionally, 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.
| - 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.
| spec: | ||
| volumes: | ||
| - name: webui-data | ||
| emptyDir: {} |
There was a problem hiding this comment.
小兔子给的建议是，不要用 emtyDir，应该用pvc，你看下呢。 emtypDir， pod重启，数据就没了。
| - Solution | ||
| ProductsVersion: | ||
| - 4.x | ||
| --- |
There was a problem hiding this comment.
这个metada的格式不对啊，应该是：
---
products:
- Alauda AI
kind:
- Solution
ProductsVersion:
- 4.x
---
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.