github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #10283] Zeroconf (mDNS/Bonjour) Support for LAN Discovery #68810

New Issue
Open
opened 2026-05-04 15:18:28 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-04 15:18:28 -05:00
Owner
Copy Link

Originally created by @danemadsen on GitHub (Apr 15, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/10283

It would be helpful if Ollama instances could advertise themselves over Zeroconf (mDNS) on the local network, enabling seamless discovery by other devices and apps (e.g. mobile clients, browser frontends, embedded devices).

This would allow clients to automatically discover Ollama instances without manual IP or port configuration, which is especially useful in LAN setups for distributed AI inference or collaborative environments.

Proposed Service Format:

Service Type: _ollama._tcp.local.
Service Name: <Hostname or InstanceName>
Port: 11434
TXT Records:
  - model=llama3
  - status=ready
  - version=0.1.25

related #751

Originally created by @danemadsen on GitHub (Apr 15, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/10283 It would be helpful if Ollama instances could advertise themselves over Zeroconf (mDNS) on the local network, enabling seamless discovery by other devices and apps (e.g. mobile clients, browser frontends, embedded devices). This would allow clients to automatically discover Ollama instances without manual IP or port configuration, which is especially useful in LAN setups for distributed AI inference or collaborative environments. Proposed Service Format: ```yaml Service Type: _ollama._tcp.local. Service Name: <Hostname or InstanceName> Port: 11434 TXT Records: - model=llama3 - status=ready - version=0.1.25 ``` related #751
GiteaMirror added the feature request label 2026-05-04 15:18:28 -05:00
GiteaMirror commented 2026-05-04 15:19:13 -05:00
Author
Owner
Copy Link

@JamesClarke7283 commented on GitHub (Apr 20, 2025):

I think this should be an opt in. Just because Ollama doesnt have builtin auth yet.

You could have it gated as under serve as a flag or env var like OLLAMA_ADVERTISE etc.

I realise many people dont have ollama exposed to the internet (assuming they set have it listening on its public IPv6 address).

Nether the less, i think this would be a good precaution.

Just to warn about the state of things, i checked shodan some months ago, there was not an insignificant number of exposed ollama servers, probably people have ineffective auth setup(nginx/etc) or raw ollama port forward.

Ollama does have a large attack surface already in many ways, we dont want to make it easier for users to be penetrated.

I just thought i would raise this, another note, for zeroconf/mDNS support it might be equally up to the packaging downstream to handle that.

I know if i wanted i could add 'zeroconf' support to the ollama PKGBUILD.

Just some food for thought.

Thanks,
James Clarke

<!-- gh-comment-id:2817371475 --> @JamesClarke7283 commented on GitHub (Apr 20, 2025): I think this should be an opt in. Just because Ollama doesnt have builtin auth yet. You could have it gated as under `serve` as a flag or env var like `OLLAMA_ADVERTISE` etc. I realise many people dont have ollama exposed to the internet (assuming they set have it listening on its public IPv6 address). Nether the less, i think this would be a good precaution. Just to warn about the state of things, i checked shodan some months ago, there was not an insignificant number of exposed ollama servers, probably people have ineffective auth setup(nginx/etc) or raw ollama port forward. Ollama does have a large attack surface already in many ways, we dont want to make it easier for users to be penetrated. I just thought i would raise this, another note, for zeroconf/mDNS support it might be equally up to the packaging downstream to handle that. I know if i wanted i could add 'zeroconf' support to the ollama PKGBUILD. Just some food for thought. Thanks, James Clarke
GiteaMirror commented 2026-05-04 15:19:14 -05:00
Author
Owner
Copy Link

@rndmcnlly commented on GitHub (Nov 21, 2025):

I like the idea of making ollama discoverable via mDNS, but I think this might be a key moment to setup a broader ecosystem of LLM-service discovery.

Consider https://github.com/jperrello/Saturn Here's whats's different from what's proposed earlier in this thread:

  • More general service name: _saturn._tcp.local.
  • Promises less support/control to people on the LAN (just OpenAI-compatible completions, no create/pull/delete).

Think about how the one tech expert in every household sets up the wifi and makes sure you can use it to connect to the printer. That same person might setup a Saturn bridge that provides LLM services to anyone on the LAN. Those services might be locally provided by an in-house instance of Ollama, or they might just be a simply proxy to a cloud provider with a pre-configured API key. The main idea is that most users don't need to set anything up. Apps just sense LLM access nearby and start using it.

If we go with the _ollama._tcp.local. design, it'll be harder to get get app developers to integrate discovery features because there's only one kind of service they could discover. With something more general, we might have a healthier ecosystem in which Ollama is just one of many thriving LLM services.

<!-- gh-comment-id:3561448581 --> @rndmcnlly commented on GitHub (Nov 21, 2025): I like the idea of making ollama discoverable via mDNS, but I think this might be a key moment to setup a broader ecosystem of LLM-service discovery. Consider https://github.com/jperrello/Saturn Here's whats's different from what's proposed earlier in this thread: - More general service name: `_saturn._tcp.local.` - Promises less support/control to people on the LAN (just OpenAI-compatible completions, no create/pull/delete). Think about how the one tech expert in every household sets up the wifi and makes sure you can use it to connect to the printer. That same person might setup a Saturn bridge that provides LLM services to anyone on the LAN. Those services *might* be locally provided by an in-house instance of Ollama, or they might just be a simply proxy to a cloud provider with a pre-configured API key. The main idea is that most users don't need to set anything up. Apps just *sense* LLM access nearby and start using it. If we go with the `_ollama._tcp.local.` design, it'll be harder to get get app developers to integrate discovery features because there's only one kind of service they could discover. With something more general, we might have a healthier ecosystem in which Ollama is just one of many thriving LLM services.
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 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#68810
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?