Skip to main content

Local network access

Self-hosters often want an agent to reach a service on their own network — a metrics server, a home automation hub, a UniFi controller, an SSH host, a self-hosted file store, a local model. OtoDock makes that possible one service at a time, while keeping the agent unable to scan the rest of your network.

The default: locked down​

Every agent on the server runs in a sandbox whose network is blocked by default for anything internal. It can reach the public internet, but it cannot reach private network addresses — not other hosts on your LAN, not even other machines on the same subnet. This is true for the agent, its local tools, and any command it runs — see The sandbox. (Tools that run as their own Docker containers sit outside the sandbox, with ordinary container networking.)

Granting access to one service​

Several tools are built to reach a homelab service — for monitoring (Prometheus, Uptime Kuma), home automation (Home Assistant), networking (UniFi), file storage (Nextcloud), SSH, and more. When you set one up, it tells OtoDock exactly which address it needs, and you control access with a single toggle:

  1. Install and enable the tool, and assign it to an agent.
  2. Configure its endpoint — the address of your service (for example, your metrics server's URL).
  3. In Admin → MCP Servers, the tool shows an Internal network access toggle (on by default for tools that declare an internal target). Leave it on to allow the agent to reach that one service; turn it off to block it.

OtoDock then opens a precise path to exactly that host — and nothing else on your network stays reachable.

Addressing tips​

How you write the address depends on how you run OtoDock:

Where the service livesNative installDocker Compose install
Same machine as OtoDocklocalhost:PORT or the machine's LAN IPhost.docker.internal or the machine's LAN IP — not localhost (that's the container)
Another machine on your networkthe LAN IP or hostnamethe LAN IP or hostname

A few practical notes:

  • Use an IP, not a .local name. mDNS names like homeassistant.local usually can't be resolved from inside OtoDock — give the device's IP address instead.
  • Static IPs are best for critical setups. OtoDock re-resolves the address on each run, so a changed IP is picked up next time — but a fixed IP avoids surprises.
  • OtoDock must be able to route to the target — it needs to be on that network (or have a VPN/route to it).
  • On a native install, a same-machine service must be listening on localhost or all interfaces (0.0.0.0) — the default for most services; one bound only to its LAN IP won't be reachable. It must listen over IPv4: one listening only on the IPv6 ::1 isn't reachable either.

Local AI models​

Pointing OtoDock at a local model follows the same addressing rules: on a Docker install use host.docker.internal or the machine's LAN IP, not localhost, for example http://192.168.1.20:11434/v1 for Ollama. A Codex agent on a remote machine reaches the server from that machine, so the machine must be able to reach the address too.

Hosted cloud

On the hosted OtoDock cloud there's no internal network to reach, so local-network access and local models aren't available — tools there can only reach public endpoints.

Next steps​