跳到主要内容

可扩展的企业级部署选项

Open WebUI 的无状态、容器优先的架构意味着,无论您是在虚拟机上将其作为 Python 进程部署、在托管服务中作为容器部署,还是在 Kubernetes 集群中作为 Pod 部署,相同的应用程序运行起来都是完全一致的。不同部署模式之间的唯一区别在于您如何对应用程序进行编排、水平扩展和日常运维,而不是应用程序本身的运行行为。

模型推理是完全独立的

您如何提供大语言模型(LLM)的推理服务,与您如何部署 Open WebUI 是完全解耦的。在任何部署模式下,您都可以自由选择托管 API 服务(如 OpenAI, Anthropic, Azure OpenAI, Google Gemini)或自托管推理引擎(如 Ollama, vLLM)。有关如何接入模型,请参见 模型集成


共享基础设施组件要求

无论您选择哪种部署模式,任何横向扩展的 Open WebUI 部署都需要相同的后端支撑服务。在将 Open WebUI 扩展到单个实例以上之前,请务必先配置好这些共享组件。

基础设施组件为什么需要它可用选项
PostgreSQL多实例部署需要真正的生产级数据库。SQLite 不支持来自多个进程的并发写入。自建托管、Amazon RDS、Azure Database for PostgreSQL、Google Cloud SQL
Redis处理多实例之间的会话(Session)管理、WebSocket 协同和系统配置同步。自建托管、Amazon ElastiCache、Azure Cache for Redis、Google Memorystore
向量数据库默认的 ChromaDB 使用本地 SQLite 作为后端,这对于多进程访问是不安全的。PGVector(与 PostgreSQL 共享)、Milvus、Qdrant,或在 HTTP 服务器模式下运行 ChromaDB
共享存储用户上传的文件必须可供每一个实例并发访问。共享文件系统(NFS, EFS, CephFS)或云对象存储(S3, GCS, Azure Blob)
内容提取服务默认的 pypdf 提取器在持续的高负载下存在内存泄漏问题。将 Apache Tika 或 Docling 作为边车服务运行
Embedding 引擎默认的 SentenceTransformers 模型会为每个 Worker 进程加载约 500 MB 内存。调用 OpenAI Embeddings API,或使用独立的 Ollama 实例运行 Embedding 模型

核心关键配置

这些环境变量在所有实例之间必须保持完全一致:

# 共享密钥 — 所有实例上必须完全相同
WEBUI_SECRET_KEY=your-secret-key-here

# PostgreSQL 数据库连接地址
DATABASE_URL=postgresql://user:password@db-host:5432/openwebui

# 向量数据库配置
VECTOR_DB=pgvector
PGVECTOR_DB_URL=postgresql://user:password@db-host:5432/openwebui

# Redis 服务配置
REDIS_URL=redis://redis-host:6379/0
WEBSOCKET_MANAGER=redis
ENABLE_WEBSOCKET_SUPPORT=true

# 文档内容提取服务
CONTENT_EXTRACTION_ENGINE=tika
TIKA_SERVER_URL=http://tika:9998

# 向量嵌入配置
RAG_EMBEDDING_ENGINE=openai

# 持久化存储 — 二选一:
# 选项 A: 共享文件系统(挂载相同的存储卷到所有实例,无需额外环境变量)
# 选项 B: 对象存储(有关所需的变量配置,参见 https://docs.openwebui.com/reference/env-configuration#cloud-storage)
# STORAGE_PROVIDER=s3

# 工作进程数 — 让编排系统处理横向扩展,此处设为 1 即可
UVICORN_WORKERS=1

# 数据库迁移 — 必须保证仅有“一个”实例在运行数据迁移
ENABLE_DB_MIGRATIONS=false
数据库迁移注意事项

请在除一个实例之外的所有实例上设置 ENABLE_DB_MIGRATIONS=false。在进行版本升级时,请先将实例缩容至单个实例,等待数据迁移顺利完成后,再重新扩容。并发的数据迁移极易导致数据库损坏。

有关完整的步骤化横向扩展演练,请参阅 扩展 Open WebUI 规模。有关完整的环境变量参考,请参阅 环境变量配置参考


选择您的部署模式

Open WebUI 支持三种生产级部署模式。以下每个指南都详细涵盖了该部署模式所特有的系统架构、横向扩展策略和核心注意事项。

自动伸缩虚拟机上的 Python / Pip

在云端自动伸缩组(AWS ASG、Azure VMSS、GCP MIG)中的虚拟机上,将 open-webui serve 部署为由 systemd 管理的进程。最适合拥有成熟的基于虚拟机的基础设施和深厚的 Linux 运维管理技能的团队,或者由于监管合规要求需要直接进行操作系统级控制的场景。

容器服务

在诸如 AWS ECS/Fargate、Azure Container Apps 或 Google Cloud Run 等托管容器平台上运行官方的 Open WebUI 容器镜像。最适合希望获得容器红利(不可变镜像、版本化部署、无需管理 OS),但不想承受 Kubernetes 带来的复杂性的团队。

Kubernetes 与 Helm

在任何主流的 Kubernetes 发行版(EKS、AKS、GKE、OpenShift、Rancher 或自建集群)上,使用官方的 Open WebUI Helm Chart 进行部署。最适合需要声明式基础设施即代码(IaC)、高级自动弹性伸缩和 GitOps 工作流的大规模、关键任务级别的企业级部署。


部署模式对比

比较维度Python / Pip (虚拟机)托管容器服务Kubernetes (Helm)
日常运维复杂度中等 — 涉及操作系统打补丁、Python 环境管理较低 — 平台完全托管容器的运行较高 — 需要资深的 Kubernetes 运维经验
自动弹性伸缩配合健康检查使用云端 ASG/VMSS平台原生支持,仅需极少的配置使用 HPA(水平 Pod 自动伸缩)进行细粒度控制
容器间安全隔离无 — 进程直接运行在操作系统上具备完整的容器级隔离具备完整的容器级 + 命名空间(Namespace)级隔离
平滑滚动升级手动操作(先缩容,升级,再扩容)平台托管的自动化滚动部署声明式的滚动升级,支持一键回滚
基础设施即代码 (IaC)针对虚拟机的 Terraform/Pulumi + 配置管理任务/服务定义(CloudFormation, Bicep, Terraform)Helm Chart + 声明式 GitOps(Argo CD, Flux)
最适合的团队偏好虚拟机化运维、有监管约束的团队希望获得容器便利但不想维护 K8s 的团队大规模、关键任务级别的生产环境部署
团队最低技术栈要求Linux 运维管理、Python容器化基础知识、主流云平台Kubernetes、Helm、云原生架构设计

系统可观测性

无论采用哪种部署模式,生产环境部署都应包含系统监控和可观测性分析。

健康检查

  • /health:基础存活检查。当应用程序正常运行时返回 HTTP 200。建议用作负载均衡器和自动伸缩器的健康检查探针。
  • /api/models:验证应用程序是否可以成功连接到已配置的后端模型。该接口调用需要 API 密钥。

OpenTelemetry

Open WebUI 支持 OpenTelemetry,可用于分布式追踪和 HTTP 指标收集。可通过以下方式启用:

ENABLE_OTEL=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4318
OTEL_SERVICE_NAME=open-webui

这将自动对 FastAPI、SQLAlchemy、Redis 和 HTTP 客户端进行检测分析——为您提供有关请求延迟、数据库查询性能和跨服务调用追踪的完整可见性。

结构化日志

可以启用 JSON 格式的日志,以无缝集成到日志聚合平台(如 Datadog、Loki、CloudWatch、Splunk)中:

LOG_FORMAT=json
GLOBAL_LOG_LEVEL=INFO

有关监控设置的完整详情,请参阅 系统监控OpenTelemetry 文档。


后续步骤


在规划企业级部署时需要帮助? 我们的团队正与全球各地的组织紧密合作,设计并实施生产级的 Open WebUI 环境。

联系企业销售 → sales@openwebui.com

This content is for informational purposes only and does not constitute a warranty, guarantee, or contractual commitment. Open WebUI is provided "as is." See your license for applicable terms.