Open WebUI 0.11.4 cuts slim image to about 175 MB; RAG deployments require additional services

Open WebUI released version 0.11.4 on September 21, further reducing its slim container image. Maintainers report a size of about 175 MB, roughly 89% smaller than the previous version, primarily by removing local models, related packages, and installation tools. This changes the capabilities available in existing deployments: the chat frontend can still start, but some tasks previously handled inside the container now require additional services. [Release announcement](https://github.com/open-webui/open-webui/releases/tag/v0.11.4)

The official documentation lists PyTorch, Transformers, local Whisper, and document and media processing tools among the removed components. Deployments that need retrieval-augmented generation (RAG) must configure an external embedding service and use PostgreSQL with pgvector, the only vector database client retained in slim. Here, “external” can also mean a self-hosted service on the same private network; it does not necessarily mean sending data to a public cloud. [Image documentation](https://docs.openwebui.com/getting-started/quick-start/)

The timing of errors deserves particular attention. The new version refuses to start if the application database uses an unsupported engine or file storage points to cloud object storage. An incompatible vector retrieval configuration, however, may not fail until the first query. In other words, passing container health checks and having a working chat interface are still insufficient to establish that the knowledge base works. [Configuration validation implementation](https://github.com/open-webui/open-webui/commit/d27aa72ab4a7b5632b4ad49e8467081ad3d7ebb4)

Document input also has clear limits. Text, Markdown, CSV, and similar files can still be read within slim. PDFs, Word documents, and presentations require a suitable document extraction service; otherwise, requests return a 503 response. Related calls also fail if no working embedding service is configured. Engineering teams should therefore validate deployments through actual file uploads, indexing, and query results, rather than testing only login and question answering. [Document and embedding processing changes](https://github.com/open-webui/open-webui/commit/cb942bb94c8dc7941336088fb3392e2398ff56c1)

From a deployment perspective, the smaller image benefits nodes that provide only a chat interface. The resource requirements of a complete RAG system, however, must still include separately deployed embedding, extraction, and speech services. The 89% figure is the officially reported reduction in image size; it cannot be used to infer an equivalent reduction in memory usage or costs for the entire system. Upgrade testing should also include existing database, file storage, and service endpoint configurations so that a fresh, empty environment does not conceal compatibility issues.

There is one further caveat for offline environments: slim’s code interpreter causes the browser to fetch Python packages from a CDN, while the standard image already bundles them. The next steps are to check required features and network reachability, pin the deployment version, and include document, retrieval, and speech workflows in upgrade validation. Teams that depend on full local processing capabilities will need to reassess whether switching to slim is appropriate. [Offline deployment guidance](https://docs.openwebui.com/getting-started/quick-start/)