[GH-ISSUE #18917] Enterprise SaaS-First Runtime is necessary #18713

New Issue

GiteaMirror · 2026-04-20T00:55:20-05:00

GiteaMirror commented

2026-04-20 00:55:20 -05:00

Originally created by @logan-robbins on GitHub (Nov 4, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18917

Summary
This RFC proposes an “Enterprise Mode” runtime profile for Open WebUI that removes the need to bundle or import heavy local ML/CV runtimes when organizations use managed SaaS providers (OpenAI/Azure/AWS, etc.). The goal is a slimmer image, faster startup, reduced attack surface, and a clearer operational model for enterprise deployments.

Why Enterprise is necessary

Size & performance: Bundled local ML/CV deps (torch/onnx/whisper/sentence-transformers) increase image size and startup time; SaaS-first users don’t need them.
Security & compliance: Fewer native/binary deps reduce CVE exposure and simplify patching.
Reliability: Eager imports can fail even when unused; lazy DI improves boot determinism.
Operational clarity: Clear SaaS-vs-local boundaries, predictable error modes (400/501), simple health checks.

Proposed approach

Typed runtime Settings with enterprise-aware defaults and validation (ENTERPRISE_MODE / local_features_enabled; engines for embeddings, STT/TTS, OCR, Vector DB; optional reranker).
Service DI + providers: thin adapters with lazy imports for OpenAI/Azure/Deepgram (STT/TTS/Embeddings), OCR (Azure Document Intelligence / AWS Textract), and Vector DB (Chroma/pgvector/Pinecone/Qdrant). Local providers gated off in enterprise.
Health endpoint: /api/v1/system/health returns effective engines and vector DB health without heavy imports.
Requirements split + Docker enterprise build path: install only selected vector DB client; slim images.
Admin UX: Enterprise panel shows effective values; OCR read-only with link to Documents to avoid duplicating secrets.

Operational profile

Minimal env:
- ENTERPRISE_MODE=true
- BYPASS_EMBEDDING_AND_RETRIEVAL=true (validate no local ML/CV paths)
- OPENAI_API_KEY set (covers Embeddings/STT/TTS for openai engines)
- Optional: DOCUMENT_INTELLIGENCE_* or AWS Textract keys for OCR
Vector DB: defaults to Chroma; can switch via VECTOR_DB and enterprise vector client build arg.

Backwards compatibility

“Full/local” profile stays intact. Route shapes and responses are preserved.

Acceptance criteria

Enterprise image starts without local ML/CV imports.
/api/v1/system/health returns effective engines + vector DB health.
Admin Enterprise tab shows effective values and links to canonical settings; OCR read-only.
Frontend build is reproducible (pyodide fetch stabilized, Tiptap v3 alignment).

References

ENTERPRISE.md (included in PR) for strategy, defaults, and quickstart.

Originally created by @logan-robbins on GitHub (Nov 4, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18917 Summary This RFC proposes an “Enterprise Mode” runtime profile for Open WebUI that removes the need to bundle or import heavy local ML/CV runtimes when organizations use managed SaaS providers (OpenAI/Azure/AWS, etc.). The goal is a slimmer image, faster startup, reduced attack surface, and a clearer operational model for enterprise deployments. Why Enterprise is necessary - Size & performance: Bundled local ML/CV deps (torch/onnx/whisper/sentence-transformers) increase image size and startup time; SaaS-first users don’t need them. - Security & compliance: Fewer native/binary deps reduce CVE exposure and simplify patching. - Reliability: Eager imports can fail even when unused; lazy DI improves boot determinism. - Operational clarity: Clear SaaS-vs-local boundaries, predictable error modes (400/501), simple health checks. Proposed approach - Typed runtime Settings with enterprise-aware defaults and validation (ENTERPRISE_MODE / local_features_enabled; engines for embeddings, STT/TTS, OCR, Vector DB; optional reranker). - Service DI + providers: thin adapters with lazy imports for OpenAI/Azure/Deepgram (STT/TTS/Embeddings), OCR (Azure Document Intelligence / AWS Textract), and Vector DB (Chroma/pgvector/Pinecone/Qdrant). Local providers gated off in enterprise. - Health endpoint: /api/v1/system/health returns effective engines and vector DB health without heavy imports. - Requirements split + Docker enterprise build path: install only selected vector DB client; slim images. - Admin UX: Enterprise panel shows effective values; OCR read-only with link to Documents to avoid duplicating secrets. Operational profile - Minimal env: - ENTERPRISE_MODE=true - BYPASS_EMBEDDING_AND_RETRIEVAL=true (validate no local ML/CV paths) - OPENAI_API_KEY set (covers Embeddings/STT/TTS for openai engines) - Optional: DOCUMENT_INTELLIGENCE_* or AWS Textract keys for OCR - Vector DB: defaults to Chroma; can switch via VECTOR_DB and enterprise vector client build arg. Backwards compatibility - “Full/local” profile stays intact. Route shapes and responses are preserved. Acceptance criteria - Enterprise image starts without local ML/CV imports. - /api/v1/system/health returns effective engines + vector DB health. - Admin Enterprise tab shows effective values and links to canonical settings; OCR read-only. - Frontend build is reproducible (pyodide fetch stabilized, Tiptap v3 alignment). References - ENTERPRISE.md (included in PR) for strategy, defaults, and quickstart.

GiteaMirror closed this issue

2026-04-20 00:55:20 -05:00

GiteaMirror referenced this issue

2026-04-25 08:07:12 -05:00

[GH-ISSUE #18713] issue: Open WebUI API returns null when using minimax-m2:cloud model despite model being listed #34211

GiteaMirror referenced this issue

2026-05-05 20:52:43 -05:00

[GH-ISSUE #18713] issue: Open WebUI API returns null when using minimax-m2:cloud model despite model being listed #57348

GiteaMirror referenced this issue

2026-05-13 05:36:09 -05:00

[GH-ISSUE #18713] issue: Open WebUI API returns null when using minimax-m2:cloud model despite model being listed #73286

GiteaMirror referenced this issue