github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-15 20:54:54 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #3574] API way for Ollama to serve a UI #48718

New Issue
Open
opened 2026-04-28 09:08:01 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-28 09:08:01 -05:00
Owner
Copy Link

Originally created by @drazdra on GitHub (Apr 10, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/3574

What are you trying to do?

A huge problem with usability right now is that we can not let users enjoy browser based UIs from the box. There is the CORS protection that can not be removed and it blocks browser UIs opened from a local file. The CORS can not be removed (set to *), as then malicious websites could potentially exploit the local Ollama, as the opened page of a bad website could just access local Ollama service.

To work-around this, right now we have to recommend installing a reverse proxy which is an overkill for simple users, especially windows ones who just want to have fun and the term "web-server" is associated with something complicated, huge and providing everyone access to your computer.

We can recommend them to set Origin to a certain web-site where our UI is hosted, but then users do not feel safe as they believe or feel the web-page is remote and it can "eavesdrop" their chats. Also, it means they can't open UI locally, they need internet to chat, which goes against the whole idea of a local service.

How should we solve this?

A very easy and logical solution would be to add to existing API a function to serve an "index.html" file. We can add a special optional env header with a path to that single file. Then Ollama could just send its content on the request of "http:/127.0.0.1:11434/index.html"

And that's basically it. The CORS protection would be kept and it's very simple to implement. For default installations nothing would change at all but for people wanting to try some browser based UI it would be enough to set the env variable or some "--index=" option at start.

Serving folders could theoretically be better but it's already much harder in terms of various security issues and to be honest not really needed as the web page can load other resources it needs from remote web-sites, like github.io or whatever.

What is the impact of not solving this?

A lot of simple users are forced to either drop CORS protection or just drop the idea of trying Ollama. As most people are using windows, it's not hard to see how installation of reverse proxy prevents Ollama to gain much wider popularity.

Anything else?

No response

Originally created by @drazdra on GitHub (Apr 10, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/3574 ### What are you trying to do? A huge problem with usability right now is that we can not let users enjoy browser based UIs from the box. There is the CORS protection that can not be removed and it blocks browser UIs opened from a local file. The CORS can not be removed (set to *), as then malicious websites could potentially exploit the local Ollama, as the opened page of a bad website could just access local Ollama service. To work-around this, right now we have to recommend installing a reverse proxy which is an overkill for simple users, especially windows ones who just want to have fun and the term "web-server" is associated with something complicated, huge and providing everyone access to your computer. We can recommend them to set Origin to a certain web-site where our UI is hosted, but then users do not feel safe as they *believe* or *feel* the web-page is remote and it can "eavesdrop" their chats. Also, it means they can't open UI locally, they need internet to chat, which goes against the whole idea of a local service. ### How should we solve this? A very easy and logical solution would be to add to existing API a function to serve an "index.html" file. We can add a special optional env header with a path to that single file. Then Ollama could just send its content on the request of "http:/127.0.0.1:11434/index.html" And that's basically it. The CORS protection would be kept and it's very simple to implement. For default installations nothing would change at all but for people wanting to try some browser based UI it would be enough to set the env variable or some "--index=" option at start. Serving folders could theoretically be better but it's already much harder in terms of various security issues and to be honest not really needed as the web page can load other resources it needs from remote web-sites, like github.io or whatever. ### What is the impact of not solving this? A lot of simple users are forced to either drop CORS protection or just drop the idea of trying Ollama. As most people are using windows, it's not hard to see how installation of reverse proxy prevents Ollama to gain much wider popularity. ### Anything else? _No response_
GiteaMirror added the feature requestapi labels 2026-04-28 09:08:01 -05:00
GiteaMirror commented 2026-04-28 09:08:02 -05:00
Author
Owner
Copy Link

@drazdra commented on GitHub (Apr 10, 2024):

p.s. security wise we might also limit this file to a predefined folder, so ppl won't be able to make Ollama print any file that the process can get access to.

<!-- gh-comment-id:2047396644 --> @drazdra commented on GitHub (Apr 10, 2024): p.s. security wise we might also limit this file to a predefined folder, so ppl won't be able to make Ollama print any file that the process can get access to.
GiteaMirror commented 2026-04-28 09:08:03 -05:00
Author
Owner
Copy Link

@dahjson commented on GitHub (Apr 14, 2024):

I think we could improve the user experience by including some user configuration settings directly within the Ollama app for connecting to websites or Chrome extensions.

https://github.com/ollama/ollama/issues/3598

<!-- gh-comment-id:2054133219 --> @dahjson commented on GitHub (Apr 14, 2024): I think we could improve the user experience by including some user configuration settings directly within the Ollama app for connecting to websites or Chrome extensions. https://github.com/ollama/ollama/issues/3598
GiteaMirror commented 2026-04-28 09:08:03 -05:00
Author
Owner
Copy Link

@drazdra commented on GitHub (Apr 14, 2024):

ideal solution in both security and flexibility: a folder predefined in ollama that can be served through ollama via certain api call, like basic "get /". then UI writers could just write an instruction "Put my ui in that folder and open ollama and that's it".

<!-- gh-comment-id:2054144776 --> @drazdra commented on GitHub (Apr 14, 2024): ideal solution in both security and flexibility: a folder predefined in ollama that can be served through ollama via certain api call, like basic "get /". then UI writers could just write an instruction "Put my ui in that folder and open ollama and that's it".
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label api feature request
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/ollama#48718
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?