github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-11 09:33:54 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #8803] When migrating, what to copy? #134994

New Issue
Closed
opened 2026-05-25 01:31:52 -05:00 by GiteaMirror · 10 comments
GiteaMirror commented 2026-05-25 01:31:52 -05:00
Owner
Copy Link

Originally created by @shiraz-shah on GitHub (Jan 23, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/8803

I've installed Open WebUI in a conda environment using pip. So no docker image. It's worked well for months!

After upgrading to a newer version of Open WebUI, using pip upgrade as recommended somewhere, Open WebUI no longer works (internal error 500).

If I make a new conda environment and start from scratch, what files do I need to copy over from the old conda environment in order to preserve users and chat histories?

Currently ~/miniconda3/envs folder has two folders openwebui and openwebui2. I.e. the old environment that no longer works, and the new environment with a fresh installation of Open WebUI.

Inside each of the environment folders we have:

drwxrwxr-x  3 openwebui openwebui 4.0K Oct 31 08:15 x86_64-conda-linux-gnu
drwxrwxr-x  3 openwebui openwebui 4.0K Oct 31 08:15 x86_64-conda_cos7-linux-gnu
drwxrwxr-x  3 openwebui openwebui 4.0K Oct 31 08:15 man
drwxrwxr-x  3 openwebui openwebui 4.0K Oct 31 08:15 ssl
drwxrwxr-x 10 openwebui openwebui 4.0K Oct 31 08:15 share
drwxrwxr-x  9 openwebui openwebui 4.0K Oct 31 08:15 include
drwxrwxr-x  2 openwebui openwebui 4.0K Oct 31 08:15 compiler_compat
drwxrwxr-x 16 openwebui openwebui 4.0K Oct 31 08:15 lib
drwxrwxr-x  2 openwebui openwebui 4.0K Oct 31 08:15 conda-meta
drwxrwxr-x  2 openwebui openwebui 4.0K Oct 31 08:15 etc
drwxrwxr-x  3 openwebui openwebui 4.0K Jan 23 07:55 bin

but I can't figure out where the user data is located.

Originally created by @shiraz-shah on GitHub (Jan 23, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/8803 I've installed Open WebUI in a conda environment using pip. So no docker image. It's worked well for months! After upgrading to a newer version of Open WebUI, using pip upgrade as recommended somewhere, Open WebUI no longer works (internal error 500). If I make a new conda environment and start from scratch, what files do I need to copy over from the old conda environment in order to preserve users and chat histories? Currently `~/miniconda3/envs` folder has two folders `openwebui` and `openwebui2`. I.e. the old environment that no longer works, and the new environment with a fresh installation of Open WebUI. Inside each of the environment folders we have: ``` drwxrwxr-x 3 openwebui openwebui 4.0K Oct 31 08:15 x86_64-conda-linux-gnu drwxrwxr-x 3 openwebui openwebui 4.0K Oct 31 08:15 x86_64-conda_cos7-linux-gnu drwxrwxr-x 3 openwebui openwebui 4.0K Oct 31 08:15 man drwxrwxr-x 3 openwebui openwebui 4.0K Oct 31 08:15 ssl drwxrwxr-x 10 openwebui openwebui 4.0K Oct 31 08:15 share drwxrwxr-x 9 openwebui openwebui 4.0K Oct 31 08:15 include drwxrwxr-x 2 openwebui openwebui 4.0K Oct 31 08:15 compiler_compat drwxrwxr-x 16 openwebui openwebui 4.0K Oct 31 08:15 lib drwxrwxr-x 2 openwebui openwebui 4.0K Oct 31 08:15 conda-meta drwxrwxr-x 2 openwebui openwebui 4.0K Oct 31 08:15 etc drwxrwxr-x 3 openwebui openwebui 4.0K Jan 23 07:55 bin ``` but I can't figure out where the user data is located.
GiteaMirror commented 2026-05-25 01:32:05 -05:00
Author
Owner
Copy Link

@shiraz-shah commented on GitHub (Jan 23, 2025):

If anybody has ideas for the salvaging the old installation, here are the error messages within the original Open WebUI console, after upgrading:

INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK
INFO:     192.168.1.136:51632 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK405 HTTP/1.1" 400 Bad Request
INFO:     192.168.1.136:51633 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK5GB HTTP/1.1" 400 Bad Request
INFO:     192.168.1.136:51634 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK6WX HTTP/1.1" 400 Bad Request
INFO:     192.168.1.136:51635 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK7mg HTTP/1.1" 400 Bad Request
INFO:     192.168.1.136:51635 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK7n4 HTTP/1.1" 400 Bad Request
INFO:     192.168.1.136:51636 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK90v HTTP/1.1" 400 Bad Request
INFO:     192.168.1.136:51637 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIKAH7 HTTP/1.1" 400 Bad Reques

On the web browser, there's either this:
Image
Or 500 internal error

<!-- gh-comment-id:2609185660 --> @shiraz-shah commented on GitHub (Jan 23, 2025): If anybody has ideas for the salvaging the old installation, here are the error messages within the original Open WebUI console, after upgrading: ``` INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:50628 - "GET /_app/version.json HTTP/1.1" 200 OK INFO: 192.168.1.136:51632 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK405 HTTP/1.1" 400 Bad Request INFO: 192.168.1.136:51633 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK5GB HTTP/1.1" 400 Bad Request INFO: 192.168.1.136:51634 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK6WX HTTP/1.1" 400 Bad Request INFO: 192.168.1.136:51635 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK7mg HTTP/1.1" 400 Bad Request INFO: 192.168.1.136:51635 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK7n4 HTTP/1.1" 400 Bad Request INFO: 192.168.1.136:51636 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIK90v HTTP/1.1" 400 Bad Request INFO: 192.168.1.136:51637 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIIKAH7 HTTP/1.1" 400 Bad Reques ``` On the web browser, there's either this: <img width="185" alt="Image" src="https://github.com/user-attachments/assets/ad66e773-17d8-49a7-8ccc-468c843a9ed0" /> Or `500 internal error`
GiteaMirror commented 2026-05-25 01:32:06 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 23, 2025):

Bad Request on websocket - did you configure websockets yet on a reverse proxy (assuming you use one?)

also it should be in the lib folder, then python folder, then open_webui, then data, there you should find database and other stuff

<!-- gh-comment-id:2609347698 --> @Classic298 commented on GitHub (Jan 23, 2025): Bad Request on websocket - did you configure websockets yet on a reverse proxy (assuming you use one?) also it should be in the lib folder, then python folder, then open_webui, then data, there you should find database and other stuff
GiteaMirror commented 2026-05-25 01:32:07 -05:00
Author
Owner
Copy Link

@shiraz-shah commented on GitHub (Jan 23, 2025):

So awesome! Thanks!!

I'm not using reverse proxy. I have sometimes accessed the Open WebUI on this machine remotely through an ssh -L tunnel, but that's it.

OK, so after copying the data, I see I'm having the same error in the new install.

Then after making a third blank install I still see the same error.

Then when opening an anynymous brower tab, it does work!

I guess browser cache has to be completely cleared before a new version of Open WebUI works.

But now, even after getting it to work, it's not seeing my ollama models in the workspace, so I can't configure new models:

Image

But I can still select between existing models in when starting a new chat:

Image

What do you think is wrong?

<!-- gh-comment-id:2609485110 --> @shiraz-shah commented on GitHub (Jan 23, 2025): So awesome! Thanks!! I'm not using reverse proxy. I have sometimes accessed the Open WebUI on this machine remotely through an `ssh -L` tunnel, but that's it. OK, so after copying the data, I see I'm having the same error in the new install. Then after making a third blank install I still see the same error. Then when opening an anynymous brower tab, it does work! I guess browser cache has to be completely cleared before a new version of Open WebUI works. But now, even after getting it to work, it's not seeing my `ollama` models in the workspace, so I can't configure new models: ![Image](https://github.com/user-attachments/assets/bf1bb15e-1121-454f-af20-2189b2bff2d6) But I can still select between existing models in when starting a new chat: ![Image](https://github.com/user-attachments/assets/6148a625-29be-4623-87f0-30aa40f96ec5) What do you think is wrong?
GiteaMirror commented 2026-05-25 01:32:08 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 23, 2025):

The "base"-models have moved to the admin section only and should be visible for you there.

The Models in the workspace section are only for custom models (like Custom GPTs) that are based off of a base model like deepseek-r1 but have special system prompts or special descriptions, a custom picture and just different things whatever you set them to.

This was done quite a while ago. Basemodels: admin section. Custom models: workspace.

Check in admin section if you see your base models there.

<!-- gh-comment-id:2609515553 --> @Classic298 commented on GitHub (Jan 23, 2025): The "base"-models have moved to the admin section only and should be visible for you there. The Models in the workspace section are only for custom models (like Custom GPTs) that are based off of a base model like deepseek-r1 but have special system prompts or special descriptions, a custom picture and just different things whatever you set them to. This was done quite a while ago. Basemodels: admin section. Custom models: workspace. Check in admin section if you see your base models there.
GiteaMirror commented 2026-05-25 01:32:09 -05:00
Author
Owner
Copy Link

@shiraz-shah commented on GitHub (Jan 23, 2025):

So cool, I love this change! It's way more intuitive.

But the browser cache thing is a bummer. I've replicated it over multiple systems.

I guess it makes sense for the browser cache to get glitchy after a major web site update, but I wish there was a smarter solution than asking all the users to reset their browser cache manually. I don't know if cache expiry settings can on Open WebUI assets can be optimised further, somehow.

Anyway, thanks for the help, @Classic298. That was awesome!!

<!-- gh-comment-id:2609549775 --> @shiraz-shah commented on GitHub (Jan 23, 2025): So cool, I love this change! It's way more intuitive. But the browser cache thing is a bummer. I've replicated it over multiple systems. I guess it makes sense for the browser cache to get glitchy after a major web site update, but I wish there was a smarter solution than asking all the users to reset their browser cache manually. I don't know if cache expiry settings can on Open WebUI assets can be optimised further, somehow. Anyway, thanks for the help, @Classic298. That was awesome!!
GiteaMirror commented 2026-05-25 01:32:10 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 23, 2025):

Yes the browser cache is indeed an issue. Users should just do a STRG+SHIFT+R after updates to ensure cache gets deleted. That fixes it all.

I don't know how to fix this though. Perhaps with some reverse proxy settings in nginx, nginx can tell the browser to only keep the cache for x minutes or something? I will do some research into this.

<!-- gh-comment-id:2609565975 --> @Classic298 commented on GitHub (Jan 23, 2025): Yes the browser cache is indeed an issue. Users should just do a STRG+SHIFT+R after updates to ensure cache gets deleted. That fixes it all. I don't know how to fix this though. Perhaps with some reverse proxy settings in nginx, nginx can tell the browser to only keep the cache for x minutes or something? I will do some research into this.
GiteaMirror commented 2026-05-25 01:32:11 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 23, 2025):

@shiraz-shah

If you use a reverse proxy like nginx (which is IMO recommendable to use), you can set a custom cache policy, which the browser adheres to, which ensures the cache of the website is only stored for x hours before being invalidated/deleted by the browser.

I think this might be a solution to this issue and users will not be forced to delete cache manually everytime.

Obviously, choose a long enough time to still take away load from the OpenWebUI service, but at the same time, short enough so if you DO update (e.g. at the end of a work day) so that the next day, the cache is gone again/invalidated and users can use the service normally, because the browser has deleted the cache for you already.

Or you can also choose something like 30 minutes of course.

# Static Assets - Cached for 7 days
location ~* \.(css|jpg|jpeg|png|gif|ico|svg|woff2?|ttf|eot)$ {
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
    try_files $uri =404;
    access_log off;
    log_not_found off;
}

This will cache static files for 7 days (since i dont expect openwebui to change css jpg and other image files etc. that often

and this belongs inside the main location area and will ensure cache gets invalidated after 12hrs

# Add strict cache control headers
expires 12h;
add_header Cache-Control "public, no-cache, must-revalidate, proxy-revalidate, max-age=43200";
add_header Pragma "no-cache";
<!-- gh-comment-id:2610002250 --> @Classic298 commented on GitHub (Jan 23, 2025): @shiraz-shah If you use a reverse proxy like nginx (which is IMO recommendable to use), you can set a custom cache policy, which the browser adheres to, which ensures the cache of the website is only stored for x hours before being invalidated/deleted by the browser. I think this might be a solution to this issue and users will not be forced to delete cache manually everytime. Obviously, choose a long enough time to still take away load from the OpenWebUI service, but at the same time, short enough so if you DO update (e.g. at the end of a work day) so that the next day, the cache is gone again/invalidated and users can use the service normally, because the browser has deleted the cache for you already. Or you can also choose something like 30 minutes of course. ``` # Static Assets - Cached for 7 days location ~* \.(css|jpg|jpeg|png|gif|ico|svg|woff2?|ttf|eot)$ { expires 7d; add_header Cache-Control "public, max-age=604800"; try_files $uri =404; access_log off; log_not_found off; } ``` This will cache static files for 7 days (since i dont expect openwebui to change css jpg and other image files etc. that often and this belongs inside the main location area and will ensure cache gets invalidated after 12hrs ``` # Add strict cache control headers expires 12h; add_header Cache-Control "public, no-cache, must-revalidate, proxy-revalidate, max-age=43200"; add_header Pragma "no-cache"; ```
GiteaMirror commented 2026-05-25 01:32:12 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 23, 2025):

@shiraz-shah please close the issue if your error is solved

thanks!
and happy to help

<!-- gh-comment-id:2610007204 --> @Classic298 commented on GitHub (Jan 23, 2025): @shiraz-shah please close the issue if your error is solved thanks! and happy to help
GiteaMirror commented 2026-05-25 01:32:12 -05:00
Author
Owner
Copy Link

@shiraz-shah commented on GitHub (Jan 23, 2025):

Oops, of course. Done!

<!-- gh-comment-id:2610403275 --> @shiraz-shah commented on GitHub (Jan 23, 2025): Oops, of course. Done!
GiteaMirror commented 2026-05-25 01:32:14 -05:00
Author
Owner
Copy Link

@CallumJHays commented on GitHub (Feb 25, 2025):

Feel it would be worth setting no-cache on files served from the /static directory.
Strangely it looks like fastapi's mount doesn't support this without some middleware or subclassing StaticFiles.

<!-- gh-comment-id:2680387663 --> @CallumJHays commented on GitHub (Feb 25, 2025): Feel it would be worth setting `no-cache` on files served from the `/static` directory. Strangely it looks like fastapi's `mount` doesn't support this without some middleware or subclassing `StaticFiles`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#134994
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?