Open WebUI Docker Update: Backup, Pinning, and Rollback

An open webui docker update is reversible when the new container mounts the existing /app/backend/data volume, reuses the exact WEBUI_SECRET_KEY, and follows a readable backup. Record the current image and mount, stop the container, archive its data, pull a deliberate tag, recreate the container with the same data path, and verify chats, settings, uploads, and login state before sending traffic to it. (Sources: Open WebUI updating; Open WebUI FAQ; Docker volumes)

The container can be replaced without deleting a named Docker volume, but only when the mount is correct. If an upgrade starts a database migration and fails, preserve the volume and use a verified backup on a separate recovery volume before attempting an image downgrade. The data-safety rule is the same regardless of the command style: verify the existing mount before replacing the container. (Sources: Docker volumes; Open WebUI updating)

Use this decision list before touching the instance:

• The data mount must end at /app/backend/data, with the old volume or host directory as its source.
• The secret key must be the existing value, not a newly generated replacement.
• A backup is useful only after its archive can be listed, extracted, and checked.
• A pinned release tag records the image target; :main needs more review.

The safe Open WebUI Docker update order

Open WebUI's Docker update sequence is container replacement: remove the old container, pull the selected image, and recreate it with /app/backend/data mounted. The safe operator version adds proof and recovery checks. (Source: Open WebUI updating)

1. Record the image, mounts, environment source, port, and current tag.
2. Confirm the data source is the expected named volume or bind directory.
3. Preserve WEBUI_SECRET_KEY, stop the container, and create a cold backup.
4. List and extract the archive, then check the SQLite copy when webui.db is present.
5. Pull the deliberate tag, recreate only Open WebUI, and verify the mount, logs, login, chats, settings, and uploads.

Open WebUI documents :main, :dev, version tags, and variants such as vX.Y.Z-cuda and vX.Y.Z-ollama. At the time of this review, the releases page listed v0.11.3 as the latest release, published August 31, 2026. Treat that as a dated review point, not a permanent command value; set WEBUI_TAG to the release you review before pulling. (Sources: Open WebUI updating; Open WebUI releases)

Open WebUI's update documentation states: "Your data (chats, users, settings, uploads) lives in a Docker volume or local database, not inside the container." (Source: Open WebUI updating)

Open WebUI Docker persistent volume: what survives replacement

A Docker container has a writable layer that belongs to it. A named volume survives container removal, while a bind mount maps a host directory into the container. Open WebUI's persistent path is /app/backend/data; its source must be the existing instance storage. (Sources: Docker volumes; Open WebUI FAQ)

Verify the mount while the old container still exists. Replace the example container name if yours differs:

# Linux or macOS shell, read-only inspection
CONTAINER="open-webui" # example container name
docker inspect "$CONTAINER" --format '{{range .Mounts}}{{println .Type .Name .Source "->" .Destination "rw=" .RW}}{{end}}'

The output row with destination /app/backend/data identifies the actual source. For a named volume, copy the Name value and inspect that volume:

# Named-volume scope: replace with the Name printed above
SOURCE_VOLUME="actual-volume-name"
docker volume inspect "$SOURCE_VOLUME"

For a bind mount, use the Source value instead of docker volume inspect:

# Bind-mount scope: replace with the Source printed above
SOURCE_PATH="/actual/host/path"
ls -la "$SOURCE_PATH"

open-webui and actual-volume-name are examples only. A Compose project may prefix a volume key, such as project_open-webui, and a bind deployment has no Docker volume to inspect. Docker's example Linux mountpoint is under /var/lib/docker/volumes/.../_data, but Docker Desktop may keep data inside its VM, so do not guess a host path. (Source: Docker volumes)

If the old container has no data mount, stop the update. A replacement will start with an empty writable layer, even if old data remains inside the old container. Correct any new-volume, spelling, or slash error first. Community reports describe this failure pattern, not a specific release defect. (Sources: Open WebUI FAQ; Reddit operator reports)

Open WebUI Docker version pinning: which strategy fits?

The tag determines how deliberately you accept change. An image tag alone cannot reverse a database migration.

Open WebUI names Diun for notifications, Watchtower for automatic updates, and What's Up Docker for reviewed updates. A pinned tag records intent; staging is the safest place to observe a migration. (Source: Open WebUI updating)

Pre-update checklist

Complete these checks while the current instance is available:

• Current image: save the current docker inspect output and the exact image reference.
• Data mount: confirm its source and /app/backend/data destination.
• Secret key: retrieve the existing WEBUI_SECRET_KEY from its secret store.
• Selected tag: record the next tag and the previous recovery tag.
• Free disk space: leave room for the archive and replacement image.
• Readable archive: list, extract, and inspect webui.db when present.
• Recovery path: choose a fresh volume and port for migration failure.

Run the checks in that order: mount, key, archive, tag, then replacement. That catches the expensive mistake before a removal command. (Source: Open WebUI updating)

Do not rotate the secret key during an image update. Open WebUI uses it for JWT signing and OAuth-session encryption, and rotation invalidates existing sessions. Preserve that existing value as part of the recovery path alongside the database and uploaded files. (Source: Open WebUI FAQ)

Update Open WebUI Docker with Run or Compose

The examples have different scopes. When updating Open WebUI with Docker Compose, preserve existing ports, environment variables, GPU flags, image, secret, and data mount.

Docker Run deployment

Stop the instance and create the archive in the next section. After recording the current image, set WEBUI_TAG to the release tag you reviewed on the official releases page:

# Linux or macOS shell, replace vX.Y.Z and the env-file path deliberately
WEBUI_TAG="vX.Y.Z"
docker pull "ghcr.io/open-webui/open-webui:${WEBUI_TAG}"

Warning: The next command removes the container. It does not remove a named volume, but it removes the container's writable layer. Run it only after mount inspection and backup verification. Never replace it with docker volume rm <production-volume>.

# Recreate with the same source shown by docker inspect and the existing secret file
CONTAINER="open-webui" # replace with the current container name
DATA_VOLUME="actual-volume-name" # replace with the inspected volume name
WEBUI_TAG="vX.Y.Z" # use the same reviewed tag as above
docker rm "$CONTAINER"
docker run -d --name "$CONTAINER" -p 3000:8080 -v "${DATA_VOLUME}:/app/backend/data" --env-file ./open-webui.env "ghcr.io/open-webui/open-webui:${WEBUI_TAG}"

The values above are examples. DATA_VOLUME must be the actual named volume identified from the old container; open-webui is not universal. For a bind mount, replace the -v value with "${DATA_PATH}:/app/backend/data" and set DATA_PATH to the exact old host path. Keep the existing port, environment variables, GPU flags, and secret settings from the old container. (Sources: Open WebUI updating; Open WebUI FAQ)

Docker Compose deployment

Set WEBUI_TAG in the shell or Compose .env file to the release tag you reviewed, then keep the existing Compose volume key and secret reference stable. The volume key below is an example only:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:${WEBUI_TAG}
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data # example key; keep your existing mapping
    environment:
      WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY}

volumes:
  open-webui: # example only; Compose may create project_open-webui

Review the resolved configuration, then update only the service unless a provider needs a restart:

docker compose config
docker compose pull open-webui
docker compose up -d --no-deps open-webui
docker compose ps open-webui

Do not run docker compose down -v as an update shortcut. The -v option removes declared named volumes. After either style, inspect the mount again and check startup logs for migration errors. (Sources: Docker volumes; Open WebUI updating)

Open WebUI Docker backup and restore: verify first

The practical open webui backup and restore path starts with webui.db, uploads/, and vector_db/ in the data directory. Stop the container, identify the exact source from docker inspect, and then write a cold archive. For a named volume, use the source name you inspected:

# Named-volume scope: run while the container is stopped; replace the inspected source name
SOURCE_VOLUME="actual-volume-name"
BACKUP_FILE="openwebui-$(date +%Y%m%d).tar.gz"
docker run --rm \
  --mount "type=volume,src=${SOURCE_VOLUME},dst=/data,readonly" \
  --mount "type=bind,src=${PWD},dst=/backup" \
  alpine tar czf "/backup/${BACKUP_FILE}" -C /data .

For a bind mount, archive the exact Source directory recorded by docker inspect instead:

# Bind-mount scope: run outside the data directory and replace the inspected Source path
SOURCE_PATH="/actual/host/path"
BACKUP_FILE="$PWD/openwebui-$(date +%Y%m%d).tar.gz"
tar czf "$BACKUP_FILE" -C "$SOURCE_PATH" .

Do not substitute a convenient directory. Omitting uploads/ makes the backup incomplete even when SQLite is present. The volume name open-webui is only an example; the SOURCE_VOLUME value must match the running container's actual source. (Source: Open WebUI community backup guide)

Check that the archive is readable before updating:

ARCHIVE="openwebui-YYYYMMDD.tar.gz"
tar -tzf "$ARCHIVE" | sed -n '1,40p'
tar -tzf "$ARCHIVE" | grep -E '(^|/)webui.db$|(^|/)uploads/'
CHECK_DIR="$(mktemp -d)"
tar -xzf "$ARCHIVE" -C "$CHECK_DIR"
sqlite3 "$CHECK_DIR/webui.db" 'PRAGMA quick_check;'

The archive is an instance copy, not only a database dump. That distinction matters when uploaded files or vector data matter to users. (Source: Open WebUI community backup guide)

The first command checks archive structure. The second looks for the database and uploads. Successful extraction proves the archive unpacks, and PRAGMA quick_check should return ok for a readable SQLite copy. A fresh-volume restore with the previous image is the stronger test. (Sources: Open WebUI community backup guide; Open WebUI updating)

Open WebUI Docker rollback after a failure

An image rollback and data restore solve different failures. If the new container fails before changing the schema, the previous image with the same volume may be enough. After a migration, an older image may not understand the changed database. Restore the pre-update archive instead of repeatedly restarting the failed container. (Source: Open WebUI updating)

Use a fresh recovery volume first. It keeps the current volume intact while you check the old image and secret.

Warning: The restore command writes files into the recovery volume. Confirm that the volume is empty or disposable, stop every container using it, and never set RECOVERY_VOLUME to the production volume. Extraction can overwrite current files.

RECOVERY_VOLUME="open-webui-recovery"
PREVIOUS_TAG="vX.Y.Z" # set to the previous reviewed release
docker volume create "$RECOVERY_VOLUME"
docker run --rm \
  --mount "type=volume,src=${RECOVERY_VOLUME},dst=/data" \
  --mount "type=bind,src=${PWD},dst=/backup,readonly" \
  alpine tar xzf /backup/openwebui-YYYYMMDD.tar.gz -C /data
docker run -d --name "$RECOVERY_VOLUME" -p 3001:8080 -v "${RECOVERY_VOLUME}:/app/backend/data" --env-file ./open-webui.env "ghcr.io/open-webui/open-webui:${PREVIOUS_TAG}"

After it starts, check login, a known chat, a setting, and an uploaded file. If those checks pass, plan the cutover. If recovery also fails, keep both volumes and follow Open WebUI's migration guidance rather than improvising Alembic commands against production. (Sources: Open WebUI updating; Open WebUI FAQ)

The release notes say failed upgrades stop at the migration error instead of starting half-updated, including failures after 0.11.0 through 0.11.2. An older image is still not a guaranteed downgrade target. Use the verified backup as the recovery boundary. (Source: Open WebUI releases)

Open WebUI Docker symptoms and fixes

If an update appears to remove data or chats, compare the old and new mount, image, and secret first. The table keeps recovery narrow. (Sources: Open WebUI FAQ; Reddit operator reports)

The last row is narrow. Ollama belongs here only for an endpoint or network problem. A provider outage does not explain missing chats, users, or uploads. (Source: Open WebUI updating)

FAQ

How do I update Open WebUI Docker without losing data?

Record the current image and mount, preserve the existing WEBUI_SECRET_KEY, stop the container, create and verify a cold backup, pull the chosen tag, and recreate the container with the same /app/backend/data volume. Check the mount and a known chat, setting, upload, and login before declaring success. (Source: Open WebUI updating)

Does deleting the Open WebUI Docker container delete chats?

Deleting a container normally leaves a named Docker volume in place, so chats remain when the replacement mounts that same volume. A container without a data mount can lose its writable-layer data, and docker volume rm deletes the volume itself. Inspect the old mount before removal. (Sources: Docker volumes; Open WebUI FAQ)

How do I back up Open WebUI Docker?

Stop the container, archive the volume or the exact bind directory containing /app/backend/data, and include webui.db, uploads/, and any other instance data. Run tar -tzf, extract the archive, and check the extracted SQLite database. A fresh-volume restore is the stronger recovery test. (Source: Open WebUI community backup guide)

Why did Open WebUI log me out after an update?

Open WebUI uses WEBUI_SECRET_KEY to sign login tokens and derive encryption keys for OAuth session data. If the replacement omits or changes that value, existing sessions can become invalid and token decryption can fail. Reuse the old key from the same secret store before rotating anything. (Source: Open WebUI FAQ)

How do I roll back Open WebUI Docker after a migration failure?

Keep the failed data volume, then restore the pre-update archive into a separate volume and start the previous image with the old secret and a different port. An image-only downgrade may fail after a one-way migration. Cut over only after the recovered instance passes data checks. (Source: Open WebUI updating)

Related coverage

Docker volumes define the persistence boundary, while a local model runtime is a separate concern. For adjacent host planning, see how to run a local LLM on 8GB RAM and the LLM VRAM calculator. (Source: Docker volumes)

References

• Docker volumes - https://docs.docker.com/engine/storage/volumes/
• Open WebUI community backup guide - https://docs.openwebui.com/tutorials/maintenance/backups/
• Open WebUI FAQ - https://docs.openwebui.com/faq/
• Open WebUI releases - https://github.com/open-webui/open-webui/releases
• Open WebUI updating - https://docs.openwebui.com/getting-started/updating/
• Reddit operator reports - https://www.reddit.com/r/OpenWebUI/comments/1hoj7g8/how_do_i_safely_update_the_openwebui_docker_container/