How to Update Open WebUI Safely

Updating Open WebUI safely takes five minutes if you follow three core rules: pin your Docker image to a specific version, back up your data directory before you pull, and verify the backup works before you restart. This guide walks you through Docker Compose and docker run methods, plus how to handle rollbacks when things break.

Before You Update: Three Golden Rules

Safe updates follow three non-negotiable rules: use pinned version tags (v0.11.4, not :latest), back up your data volume before pulling the new image, and test that backup by restoring it to a temporary location. These three steps prevent 90% of update disasters.

The reason is simple. Open WebUI stores everything that matters--your chat history, saved models, API keys, user accounts, and settings--inside a Docker volume mounted at /app/backend/data. If you pull a broken image or hit a migration bug, that data is safe. But only if the volume existed before the container started. Only if you backed it up separately.

Pinning to a specific version tag like ghcr.io/open-webui/open-webui:v0.11.4 gives you control. You choose when to upgrade. You read the release notes first. You can downgrade instantly by pulling the old tag. Compare this to :latest, which changes whenever the maintainers push code to the main branch. You never know what you are getting until the container fails to start.

Testing your backup is the step people skip. Don't. Restore your tar.gz backup to a second folder or container. Confirm the files are there and readable. Verify the permissions are intact. This takes 60 seconds and saves you hours if the upgrade breaks the database.

Understanding Docker Image Tags: :main vs. :latest vs. :vX.Y.Z vs. :dev

Each Docker image tag points to a different version of Open WebUI. Choosing the right tag is the difference between a smooth update and a broken deployment that takes down your AI interface.

:latest - Points to the most recent official release. Updated when the maintainers publish a new version (roughly every 1-2 weeks based on the GitHub activity: 20,087 commits, 157.4K stars, 22.9K forks showing constant development). You do not control the timing. If a critical bug is discovered in the latest release, you are running it immediately on your next container restart. Use this only if you monitor your deployment actively and are prepared to rollback.

:main - Points to the latest code on the main development branch. Updated many times per day as developers push changes. Includes unreleased features and unverified changes. Stability is not guaranteed. Only use this if you are comfortable running unstable code and can afford downtime.

:vX.Y.Z (pinned version, such as :v0.11.4) - A specific immutable release. Frozen forever. You control exactly when you upgrade to it. This is what you should use in production. Before pinning to a new version, check the CHANGELOG on GitHub to see what changed, whether database migrations are required, and whether breaking changes affect your setup.

:dev - Development builds. Actively broken by design during development cycles. Never use this in production or staging.

Open WebUI ships new versions roughly every 1-2 weeks. Each release may include bug fixes, feature additions, and sometimes breaking changes that require you to run database migrations manually. Pinning to a specific version means you control the pace of change and can read release notes before committing to an upgrade.

Step-by-Step: Updating with Docker Compose

Most Open WebUI deployments use docker-compose.yml. This is the simplest and most common upgrade path.

Backup your data volume first. This is non-negotiable. Run:

docker-compose exec open-webui tar -czf /tmp/backup.tar.gz /app/backend/data
docker cp $(docker-compose ps -q open-webui):/tmp/backup.tar.gz./backup-$(date +%Y%m%d).tar.gz

This creates a compressed backup file in your current directory named something like backup-20261101.tar.gz.

Update the image tag in your docker-compose.yml. Change from :main or :latest to a pinned version. Visit the GitHub releases page to pick one. For example:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.11.4
    volumes:
      - open-webui-data:/app/backend/data
    environment:
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}

Pull the new image and restart:

docker-compose pull
docker-compose down
docker-compose up -d

Watch the logs for errors. If the container fails to start, you will see the reason here:
```
docker-compose logs -f open-webui
```
Most errors are database migration timeouts (wait longer) or missing environment variables (check your.env file).
Once logs show the app is ready, open your browser to the address where you deployed Open WebUI (for local testing, this would be port 3000 on your machine). Your data is still there, in the volume named open-webui-data, untouched by the upgrade.

If something breaks during these steps, stop immediately. Do not keep restarting the container. Each failed restart can leave the database in a partially-migrated state. Go to the rollback section instead.

Step-by-Step: Updating with Plain Docker Run

If you deployed Open WebUI with docker run instead of docker-compose, the process is similar but you must manage the volume explicitly. There is no yaml file to edit, so you need to remember all your flags.

Backup your data volume. Assuming your volume is named open-webui-data:
```
docker run --rm -v open-webui-data:/data -v $(pwd):/backup alpine tar -czf /backup/backup-$(date +%Y%m%d).tar.gz /data
```
This creates a tar.gz file in your current directory.

Stop the running container:

docker ps  # find the container ID
docker stop <container-id>

Remove the container (the volume stays intact):
```
docker rm <container-id>
```

Pull the new image:

docker pull ghcr.io/open-webui/open-webui:v0.11.4

Start the container with the same volume mount and configuration. Be careful to include all your original flags:

docker run -d \\
  --name open-webui \\
  --restart always \\
  -v open-webui-data:/app/backend/data \\
  -e WEBUI_SECRET_KEY=your-secret-key \\
  -e OLLAMA_API_BASE_URL=ollama-server:11434 \\
  -p 3000:8080 \\
  ghcr.io/open-webui/open-webui:v0.11.4

Replace ollama-server with the hostname or IP address of your Ollama instance if you are connecting to a separate server.

Verify it started:
```
docker logs open-webui
```
You should see it initializing the database and loading models without errors.

The critical piece is the -v open-webui-data:/app/backend/data mount. This volume path must be identical before and after the update. If you change the volume name or the mount path, Open WebUI will start fresh with an empty database and lose all your data.

Automating Updates Safely with Watchtower

Watchtower is a tool that automatically pulls new Docker images and restarts containers whenever an update is available. It saves you from manually checking for releases every week. But it has a major caveat: the original Watchtower image from containrrr/watchtower is no longer maintained and does not work reliably with Docker 29+. Use the maintained fork at nickfedor/watchtower instead.

If you want automatic updates (and accept that they might break things occasionally):

watchtower:
  image: nickfedor/watchtower:latest
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock
  command: --interval 86400 --cleanup open-webui
  restart: always

This checks for updates once per day (86400 seconds) and automatically restarts Open WebUI if a new image is found. The --cleanup flag removes old images to save disk space. Add this service to your docker-compose.yml and it runs in the background.

But here is the tradeoff: Watchtower does not back up your data. If the new version introduces a breaking database migration or a critical bug, you will go down hard with no recovery path other than restoring from a backup you made separately. Most teams should skip automatic updates and instead:

Set a weekly calendar reminder to check the GitHub CHANGELOG
Test the new version in a staging container first (optional but wise)
Upgrade production after testing
Keep automated backups in place regardless

This takes 20 minutes per week but gives you time to react if a version is broken.

Testing Your Update: Verification Checklist

After you update, confirm that Open WebUI is healthy before you walk away. Run this five-minute checklist:

Check the container is running:
```
docker ps | grep open-webui
```
You should see a healthy container that did not exit.
Check the logs for errors:
```
docker logs open-webui | tail -30
```
You should see startup messages like "Starting webui..." and "Database initialized". Not Python tracebacks.
Test the health endpoint:
```
curl your-webui-address:3000/health
```
This should return a 200 response indicating the app is running. Replace your-webui-address with localhost for local testing or the server IP/hostname for remote deployments.
Log in via the web UI: Open a browser to your Open WebUI instance and log in. Confirm that your chat history, models, and settings are still there.
Verify the data volume mount:
```
docker inspect open-webui | grep -A 5 Mounts
```
Confirm that the mount path /app/backend/data points to your volume (usually open-webui-data or a full host path if you used a bind mount).

If any of these steps fail, stop immediately. See the rollback section below.

What to Do If Something Breaks: Rollback and Recovery

Broken updates happen. Usually it is a database migration that fails, or a configuration incompatibility with your environment. You have two recovery options.

Rollback by image tag (fastest option): If the new version is broken, downgrade by pulling the old image:

For docker-compose:

docker-compose down

# Edit docker-compose.yml and change the image tag back to the old version
docker-compose pull
docker-compose up -d

For docker run:

docker stop open-webui
docker rm open-webui
docker pull ghcr.io/open-webui/open-webui:v0.11.3  # (the version before the broken one)
docker run -d \\
  --name open-webui \\
  --restart always \\
  -v open-webui-data:/app/backend/data \\
  -e WEBUI_SECRET_KEY=your-secret-key \\
  -p 3000:8080 \\
  ghcr.io/open-webui/open-webui:v0.11.3

Docker does not delete your volume when you stop the container. Your data is safe.

Restore from a full backup (if the old version also fails): If the old version also fails to start, or if the volume itself was damaged:


# Remove the damaged volume
docker volume rm open-webui-data

# Create a new volume and restore from your tar backup
docker volume create open-webui-data
docker run --rm -v open-webui-data:/data -v $(pwd):/backup alpine tar -xzf /backup/backup-20261101.tar.gz -C /

# Start the container with the restored data
docker run -d \\
  --name open-webui \\
  --restart always \\
  -v open-webui-data:/app/backend/data \\
  -e WEBUI_SECRET_KEY=your-secret-key \\
  -p 3000:8080 \\
  ghcr.io/open-webui/open-webui:v0.11.3

This restores your entire /app/backend/data directory from the backup. Database, settings, and chat history all come back.

When to ask for help: If the container exits immediately after starting, check the logs. If the logs mention a database migration error or a missing Python module, the version is fundamentally broken. Check the GitHub issues. These problems are usually reported within hours of a broken release, and maintainers fix them quickly. Post on the Open WebUI community forum or check r/OpenWebUI on Reddit to see if others hit the same problem.

Frequently Asked Questions

How do I install Open WebUI using pip?

The pip installation method exists but is not recommended for production. Docker is simpler: each image version includes all dependencies locked and tested together. Pip requires you to manage Python versions, virtual environments, and dependency conflicts yourself. Docker handles all that. If you want pip anyway, the official docs mention it, but Docker is the method with the most community support and easiest updates.

What is the newest version of Open WebUI?

Visit the Open WebUI GitHub releases page to find the latest version. Each release is tagged with a version like v0.11.4. The CHANGELOG describes what changed. The top release is the newest. Before pinning to it, read the changelog for breaking changes, usually noted in caps like "BREAKING: database schema changed".

How do I update Open WebUI using Docker?

This is exactly what this guide covers. The short answer: change the image tag in your docker-compose.yml or docker run command to a new version, back up your volume first, then pull and restart. If you use Watchtower, it does this automatically with the nickfedor/watchtower fork.

What happens to my data when I update?

Your data is stored in a Docker volume mounted at /app/backend/data. The volume persists even when the container stops or is deleted. As long as you do not delete the volume explicitly or change the mount path, your chats, models, and settings survive any update.

Do I need to rebuild the image myself, or can I pull a pre-built one?

You can pull pre-built images from the Open WebUI registry at ghcr.io/open-webui/open-webui. This is the standard approach. You only rebuild if you are modifying the source code, which most users will not do.

Can I update while users are actively using Open WebUI?

It is not recommended. When you run docker-compose down or stop the container, the service goes offline. Active users get disconnected. Schedule updates during maintenance windows, or run a staging instance where you test updates before switching production traffic.

Why does Open WebUI keep asking me to log in after an update?

This usually means the WEBUI_SECRET_KEY environment variable changed or is missing after the update. Your login tokens were signed with the old key and the new container cannot verify them. Check your docker-compose.yml or docker run command and ensure WEBUI_SECRET_KEY is set to the same value before and after the update.

The Bottom Line

Updating Open WebUI is safe if you pin to a specific version, back up your data volume, and test the backup before you update. Most updates take five minutes and have zero downtime if you follow the steps in this guide. Open WebUI maintains a strong release cadence with 20,087 commits showing active development, so staying current with patches and features is worth the small effort.

Self-hosted updates require discipline: you read release notes, decide when to upgrade, and own the rollback if something breaks. If you would rather not manage this yourself, consider checking out Opsily's managed Open WebUI hosting where we handle updates, backups, and monitoring automatically. You focus on using Open WebUI for your AI work, not maintaining the infrastructure.

How to Update Open WebUI Safely: Docker Guide