From Live Chat to Durable Operations
Open WebUI's behavior does not end when a provider returns the last token. A live response may need to reach a browser, update a saved chat, preserve a tool result, schedule another model call, or leave evidence for an operator. This chapter follows that operational lifecycle: which state is durable or shared, how real-time work crosses workers, how automations acquire a future, and what audit, telemetry, analytics, and evaluation can reveal. The practical outcome is a way to judge coordination and observation features without confusing “the screen updated” with “the system durably recorded and governed the work.”
The central distinction is between kinds of state. Open WebUI has relational state for users, chats, messages, models, permissions, knowledge metadata, calendars, and automation records. It has uploaded-object state for files, searchable index state for retrieval, in-process state for some live sessions and tasks, and optional Redis-coordinated state for workers that need to share models, sessions, usage, response streams, or cancellation commands. These stores serve different time horizons. A response can be visible now while some state is still in flight; a saved chat can outlive the worker that produced it; a task can be cancellable across nodes only when the coordination path is present.
What survives a response
The default deployment favors a self-contained path. Open WebUI uses a local SQLite database by default and stores uploaded files locally. The database layer supports asynchronous request work, SQLite WAL and tuning controls, pooling options, and PostgreSQL alternatives; optional encrypted SQLite and cloud database authentication are also represented in the configuration. The storage abstraction can place files in local storage, S3, Google Cloud Storage, or Azure Blob Storage. Docker Compose gives the application data and model runtime persistent volumes rather than treating the container filesystem as the product's durable home.
That separation is important for recovery. A database record can say that a chat exists, who owns it, which model produced a message, or which file belongs to a knowledge base. The file content may live in an object store. The retrieval index may contain the chunks and vectors used to find that content. A workspace that restores only one of these layers can appear healthy while a later request cannot reconstruct its context. The source establishes the available persistence choices, not a universal backup procedure, but the operational implication is direct: durability has to be considered across the records and stores that make a feature work.
The same principle applies to live responses. A browser can receive a stream through Socket.IO or a server-sent-event path while the application tracks the current task and, where configured, saves response-stream content for recovery or continuation. An in-process dictionary is sufficient for a single worker's local state. It is not automatically visible to another worker. Redis-backed dictionaries and a Redis Socket.IO manager provide a shared coordination path for deployments that need cross-worker model, session, usage, or event state.
Redis does not turn every operation into a strongly consistent transaction. It provides a place to coordinate. The runtime uses Redis pub/sub commands so a stop request can reach the worker that owns a task. It uses cleanup locks so multiple workers do not all perform the same maintenance sweep. It reaps sessions that have missed their heartbeat and usage entries that have expired.