Shared writing workspaces · Updated October 31, 2026
Open WebUI logo

Open WebUI review: who can read your draft?

Public entry checkedv0.12.5 docs reviewedNo installed-app test

Open WebUI is a good fit for private drafting when you control the server and understand its model connections. A separate account on somebody else’s installation does not create that same privacy boundary. It is a workspace for a model you choose, rather than an adult-specialist model with predictable content behavior.

This October 31, 2026 revision combines two public browser checks with current documentation and the October 29 v0.12.5 release. We did not install the software, generate text or test a server’s privacy controls.

The community’s Try button asked for an existing instance

On the official Models directory, we clicked a featured model’s Try in Open WebUI button. It opened an Open in Open WebUI dialog asking for an Open WebUI URL, with http://localhost:3000 as its example.

We left the field empty and did not click Get. That particular entry was an instance handoff, not an anonymous hosted conversation. Check that you already have a working instance before treating a catalogue entry as a ready-to-use writing tool.

A local model and a private server solve different problems

The official FAQ says external model connections send prompts and responses to the selected provider. Running the browser interface yourself does not make an external model local.

For a shared writing installation, ask two separate questions:

Who operates the instance?
Account permissions control ordinary-user access; they do not isolate drafts from the people controlling the server, database and backups.
Who processes this request?
Check the selected model's provider and any enabled tools. A familiar chat interface does not establish which services receive the text.

The project’s chat privacy guidance explicitly treats administrators as able to read chats. If a server operator must not see a draft, choose infrastructure you control before importing it. Temporary Chat does not remove the server and selected model from processing the current conversation; tools can also store data separately.

v0.12.5 makes administrator visibility easier to inspect

The v0.12.5 release notes describe a new Sessions tab in Admin Analytics. When ENABLE_ADMIN_CHAT_ACCESS is enabled, it can show saved replies and tool calls alongside session information. This is a documented capability, not something we tested on a running server.

The configuration reference lists that flag as True by default. It is read at startup; it is not one of the saved ConfigVar settings that can override a later environment change.

Disabling the flag limits the application’s administrator chat-access features. It does not encrypt drafts against someone with database, host or backup access. Ask a shared host about that operational access, rather than accepting a screenshot of a disabled switch as proof of isolation.

There is a related naming trap: the documented OFFLINE_MODE controls update checks and automatic downloads. It is not a network block for external model APIs, search or tools. We did not trace network traffic or verify an offline deployment.

The homepage Docker snippet is not a preservation plan

In our second browser check, selecting Docker on the official homepage displayed docker run ghcr.io/open-webui/open-webui:main. That visible snippet contained no port or data-volume arguments. We did not execute it.

Use the full deployment instructions before creating drafts you need to keep. The Docker persistence explanation distinguishes the disposable container from its mounted data. In the documented Docker setup, persistent application data belongs at /app/backend/data; removing a container without an appropriate persistent mount can lose its contents.

The updating guide also matters before upgrading an existing writing workspace: a new image can migrate its database, and switching back to an older image does not undo that migration. Keep the pre-update data backup with its matching application version.

Proposed check before replacing a container
  1. Record the running version and actual data mount. Do not infer them from a command copied from a homepage.
  2. Back up the data and required deployment configuration using a method appropriate to your database and storage. A chat export is useful portability, not a substitute for the whole installation.
  3. Verify a restore in a separate disposable environment before changing the working copy. Check one harmless saved draft and any uploaded reference it needs.

We have not performed this recovery check. The project's community-contributed backup guide explains storage and database-specific limitations.

Choose the instance before moving your writing

If you want a shared browser workspace and can maintain its storage and model connections, Open WebUI is worth a small, nonsensitive trial. Its self-hosted route replaces a bundled subscription with your own hardware or hosting, model-provider costs and maintenance work.

For a single-writer desktop setup, compare Jan. For a character-focused frontend with a separately chosen backend, compare SillyTavern. Neither comparison establishes better output or stronger privacy without checking the actual configuration.

Next step: identify the server operator and model destination, then create one harmless draft on your chosen instance and verify how you will preserve it. Move private work only after those answers fit your needs.

Read Open WebUI's privacy explanation ↗How we review tools →