LAN Discovery

LAN Discovery (Bonjour / _obelo._tcp)

Native clients can find your server without anyone typing an IP address. The server advertises itself over mDNS as _obelo._tcp.

Manual address entry always works. Discovery is a convenience, never the only path — if this page defeats you, type the address into the client and move on.

---

In Docker, this needs --network host

mDNS is link-local multicast, and it does not cross a Docker bridge. A published port (-p 8080:8080) gives you a perfectly reachable server that no client will ever discover.

docker run -d --name obelo --network host \
  -e OBELO_LISTEN_ADDR=:8088 \
  -v "$PWD/data:/data" \
  -v /path/to/your/media:/media:ro \
  obelo

Host networking ignores -p, so set the port with OBELO_LISTEN_ADDR.

---

Read the boot log first

The boot log is the only visible symptom discovery has:

obelo: advertising "Living Room" as nuc.local. on _obelo._tcp port 8088 at 192.168.1.50 (id: …)

It can tell you two things.

The line is missing, replaced by mDNS advertisement unavailable (…)

The server could not work out an address to publish. Tell it:

-e OBELO_ADVERTISE_IP=192.168.1.50      # this host's LAN address; comma-separate several

The line is there but the address is wrong

A 172.17.x.x or other bridge address instead of your LAN address. Same fix — OBELO_ADVERTISE_IP.

The address is right and clients still find nothing

The responder is probably listening on the wrong interface. The kernel picks the "default multicast interface" from the routing table, and on a Docker host that is often docker0 rather than your NIC — so the query never reaches the server. Pin it:

-e OBELO_MDNS_INTERFACE=eth0

---

Verifying from another machine

From a Mac on the same LAN:

dns-sd -B _obelo._tcp local

This does not work against a server running on the same Mac. macOS's own mDNSResponder owns port 5353, and a second responder on that host is invisible to it. That is a same-host artifact, not a server fault — test from a different machine.

---

Things that are not discovery problems

• A client on a different VLAN or subnet. Multicast is link-local by design. Type the address.
• A guest network with client isolation on. Same answer.
• A tailnet client. Devices reaching you over Tailscale use the stable MagicDNS name and never discover anything — that is the point of it.
• The name is wrong. OBELO_SERVER_NAME is purely cosmetic. Renaming the server never invalidates a device token; the token is keyed to the server's id, and the two are separate for exactly this reason.