I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
v0.6.15
Ollama Version (if applicable)
2.37.3
Operating System
Ubuntu 24.04 LTS
Browser (if applicable)
Edge 138.0.3351.65
Confirmation
I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.
Expected Behavior
Provide a valid HTTPs link to a GGUF model would it be private or public should let OpenWebUI download the GGUF model.
A link such as: https://media.domain.tld/ai/models/qwen3.gguf should be considered as a valid URL.
Cherry on top of the cake would be to get an option within the UI to let administrators add new allowed hosts/domains.
Actual Behavior
When the UI input is filled with a link to a custom HTTP endpoint (Object-store/http server) the upload fail with an error:
Invalid file_url. Only URLs from allowed hosts are permitted.
Originally created by @ArKam on GitHub (Jul 5, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15540
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
v0.6.15
### Ollama Version (if applicable)
2.37.3
### Operating System
Ubuntu 24.04 LTS
### Browser (if applicable)
Edge 138.0.3351.65
### Confirmation
- [x] I have read and followed all instructions in `README.md`.
- [x] I am using the latest version of **both** Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [x] I have included the Docker container logs.
- [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.**
- [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
- [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps:
- Start with the initial platform/version/OS and dependencies used,
- Specify exact install/launch/configure commands,
- List URLs visited, user input (incl. example values/emails/passwords if needed),
- Describe all options and toggles enabled or changed,
- Include any files or environmental changes,
- Identify the expected and actual result at each stage,
- Ensure any reasonably skilled user can follow and hit the same issue.
### Expected Behavior
Provide a valid HTTPs link to a GGUF model would it be private or public should let OpenWebUI download the GGUF model.
A link such as: https://media.domain.tld/ai/models/qwen3.gguf should be considered as a valid URL.
Cherry on top of the cake would be to get an option within the UI to let administrators add new allowed hosts/domains.
### Actual Behavior
When the UI input is filled with a link to a custom HTTP endpoint (Object-store/http server) the upload fail with an error:
```
Invalid file_url. Only URLs from allowed hosts are permitted.
```
This is due to the hardcoded allowed_hosts list:
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/routers/ollama.py#L1690
### Steps to Reproduce
1. Go to the admin panel.
2. Click on the "settings" tab.
3. Select the "models" left menu option.
4. Click on the top right "Manage models" icon.
5. Click on "show" at the bottom "experimental" row.
6. Click on "File mode" at the "Upload GGUF Model" row to switch to "URL Mode".
7. Input an url to your own private HTTP endpoint such as "https://media.domain.tld/ai/models/qwen3.gguf"
8. Click on the "upload" icon.
### Logs & Screenshots
<img width="1911" height="820" alt="Image" src="https://github.com/user-attachments/assets/5c00a6dc-db43-45d8-8119-fb77d4c73204" />
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-05-20 22:39:46 -05:00
GGUF is a popular format, uploading models from URLs is the best way to upload models with offline deployment.
<!-- gh-comment-id:3047785480 -->
@ArKam commented on GitHub (Jul 8, 2025):
Sure but could we at least get a reason?
GGUF is a popular format, uploading models from URLs is the best way to upload models with offline deployment.
In my opinion, yes, upload gguf (and better can upload/convert other types) from any place, could be a good thing, but, in addition to the fact that using any unverified model is a risk (which many users are unaware of), it requires a lot of work to do it right and prevent it from being a constant source of problems, you have to check compatibility, integrity, authorizations, syntax, etc.
it increases the code, and although one of the OpenWebUI principles is its local use, the use of this function is not "generally" used.
it can be done with a function or a tool.
it seems that right now there are other actions that are more necessary for programmers.
<!-- gh-comment-id:3048014071 -->
@rgaricano commented on GitHub (Jul 8, 2025):
In my opinion, yes, upload gguf (and better can upload/convert other types) from any place, could be a good thing, but, in addition to the fact that using any unverified model is a risk (which many users are unaware of), it requires a lot of work to do it right and prevent it from being a constant source of problems, you have to check compatibility, integrity, authorizations, syntax, etc.
If we stick to the simplest approach, like what is currently being done, this can be done directly in the terminal or script, or through an MCP server,
e.g., simple ollama servers (the `create` command would need to be added):
https://github.com/hyzhak/ollama-mcp-server
https://github.com/rawveg/ollama-mcp
Other points are that:
- it increases the code, and although one of the OpenWebUI principles is its local use, the use of this function is not "generally" used.
- it can be done with a function or a tool.
- it seems that right now there are other actions that are more necessary for programmers.
You're right, althrough, the core reason for OpenWEBUI to exist out of the obvious conversational interface, is also to ease models management.
I ended up by just mounting the model from ollama directly, but my end game would have been to load models from our S3 endpoint instead of having to send them to the ollama instance and load them manually or through another intermediary tool.
I mean, an alternative could be to patch ollama for it to be able to support third party OCI registry but then it only fix the issue for one backend type and not all those already supported.
Anyway, that is a real discussion with impacts as you highlighted.
<!-- gh-comment-id:3049582920 -->
@ArKam commented on GitHub (Jul 8, 2025):
You're right, althrough, the core reason for OpenWEBUI to exist out of the obvious conversational interface, is also to ease models management.
I ended up by just mounting the model from ollama directly, but my end game would have been to load models from our S3 endpoint instead of having to send them to the ollama instance and load them manually or through another intermediary tool.
I mean, an alternative could be to patch ollama for it to be able to support third party OCI registry but then it only fix the issue for one backend type and not all those already supported.
Anyway, that is a real discussion with impacts as you highlighted.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ArKam on GitHub (Jul 5, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15540
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.15
Ollama Version (if applicable)
2.37.3
Operating System
Ubuntu 24.04 LTS
Browser (if applicable)
Edge 138.0.3351.65
Confirmation
README.md.Expected Behavior
Provide a valid HTTPs link to a GGUF model would it be private or public should let OpenWebUI download the GGUF model.
A link such as: https://media.domain.tld/ai/models/qwen3.gguf should be considered as a valid URL.
Cherry on top of the cake would be to get an option within the UI to let administrators add new allowed hosts/domains.
Actual Behavior
When the UI input is filled with a link to a custom HTTP endpoint (Object-store/http server) the upload fail with an error:
This is due to the hardcoded allowed_hosts list:
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/routers/ollama.py#L1690
Steps to Reproduce
Logs & Screenshots
Additional Information
No response
@tjbck commented on GitHub (Jul 6, 2025):
Experimental feature and won't be updated.
@ArKam commented on GitHub (Jul 8, 2025):
Sure but could we at least get a reason?
GGUF is a popular format, uploading models from URLs is the best way to upload models with offline deployment.
@rgaricano commented on GitHub (Jul 8, 2025):
In my opinion, yes, upload gguf (and better can upload/convert other types) from any place, could be a good thing, but, in addition to the fact that using any unverified model is a risk (which many users are unaware of), it requires a lot of work to do it right and prevent it from being a constant source of problems, you have to check compatibility, integrity, authorizations, syntax, etc.
If we stick to the simplest approach, like what is currently being done, this can be done directly in the terminal or script, or through an MCP server,
e.g., simple ollama servers (the
createcommand would need to be added):https://github.com/hyzhak/ollama-mcp-server
https://github.com/rawveg/ollama-mcp
Other points are that:
@ArKam commented on GitHub (Jul 8, 2025):
You're right, althrough, the core reason for OpenWEBUI to exist out of the obvious conversational interface, is also to ease models management.
I ended up by just mounting the model from ollama directly, but my end game would have been to load models from our S3 endpoint instead of having to send them to the ollama instance and load them manually or through another intermediary tool.
I mean, an alternative could be to patch ollama for it to be able to support third party OCI registry but then it only fix the issue for one backend type and not all those already supported.
Anyway, that is a real discussion with impacts as you highlighted.