How to update Open WebUI in Docker

An Open WebUI Docker update replaces the application container while keeping the Docker volume that stores users, chats, settings, uploads, and indexes. The container layer is disposable, so the update should focus on the image tag, the persistent volume, and the secret key used by the existing instance.

Single-container deployments normally run from the official ghcr.io/open-webui/open-webui image with the data volume mounted at /app/backend/data. Pulling the target image is not enough by itself; Docker must recreate the container so the new image is used while the same volume and port mapping are attached.

Keep the same WEBUI_SECRET_KEY when recreating an instance that already has users or integrations. Review release notes and keep a data backup before updates that may run database migrations, because rolling back the image does not automatically roll back the database stored in the volume.

1. List the running Open WebUI container.

   $ docker ps --filter 'name=^/open-webui$'
   CONTAINER ID   IMAGE                                COMMAND           CREATED       STATUS                    PORTS                                       NAMES
   61d3f42c8b10   ghcr.io/open-webui/open-webui:main   "bash start.sh"   3 weeks ago   Up 3 weeks (healthy)      0.0.0.0:3000->8080/tcp, [::]:3000->8080/tcp   open-webui

2. Confirm that the persistent open-webui volume exists before stopping the container.

   $ docker volume ls --filter 'name=^open-webui$'
   DRIVER    VOLUME NAME
   local     open-webui

   If the original deployment uses a bind mount or a different volume name, keep that same storage path in the recreate command instead of switching to a new empty volume.

3. Back up the Open WebUI data volume before replacing the container.

   Use a backup taken before the update for releases that may run database migrations.
   Related: How to back up and restore Open WebUI data

4. Stop the current container.

   $ docker stop open-webui
   open-webui

5. Pull the target Open WebUI image.

   $ docker pull ghcr.io/open-webui/open-webui:main
   main: Pulling from open-webui/open-webui
   Digest: sha256:a26effeb220e132482bf7e0560b3404843e7bc40d23051144e062960df8df6b0
   Status: Image is up to date for ghcr.io/open-webui/open-webui:main
   ghcr.io/open-webui/open-webui:main

   A pinned version tag can replace main when release-note review and repeatable rollback matter.

6. Remove the stopped container object.

   $ docker rm open-webui
   open-webui

   docker rm removes the container definition, not the named volume. Do not run docker volume rm open-webui unless deleting the instance data is intentional.

7. Recreate Open WebUI with the same name, port, volume, and secret-key source.

   $ docker run --detach \
     --name open-webui \
     --publish 3000:8080 \
     --env-file open-webui.env \
     --mount type=volume,source=open-webui,target=/app/backend/data \
     --restart unless-stopped \
     ghcr.io/open-webui/open-webui:main
   <container-id>

   The open-webui.env file should contain the same WEBUI_SECRET_KEY used by the previous container.
   Related: How to set WEBUI_SECRET_KEY in Open WebUI

8. Check the recreated container status.

   $ docker ps --filter 'name=^/open-webui$'
   CONTAINER ID   IMAGE                                COMMAND           CREATED          STATUS                    PORTS                                       NAMES
   2f8c2a4e9b41   ghcr.io/open-webui/open-webui:main   "bash start.sh"   32 seconds ago   Up 30 seconds (healthy)   0.0.0.0:3000->8080/tcp, [::]:3000->8080/tcp   open-webui

   If the status stays at (health: starting), wait briefly and repeat the check. Use docker logs open-webui when the container exits or becomes unhealthy.
   Related: How to view Open WebUI Docker logs

9. Confirm that the persistent open-webui volume still exists after recreation.

   $ docker volume ls --filter 'name=^open-webui$'
   DRIVER    VOLUME NAME
   local     open-webui

10. Request the Open WebUI health endpoint.

    $ curl -fsS http://127.0.0.1:3000/health
    {"status":true}

    Open http://localhost:3000 after the health endpoint returns {"status":true} and sign in with an existing account when the update needs an account-level smoke test.