Skip to main content

Local network access

Self-hosters often want an agent to reach a service on their own network — an SSH host, a self-hosted service, 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​

A tool that's built to reach a service on your network — an SSH host, a self-hosted endpoint, a tool you wrote yourself — 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.

Local AI models​

Pointing the direct engine at a local model (Ollama or an OpenAI-compatible endpoint) follows the same addressing rules — on a Docker install use host.docker.internal or the machine's LAN IP, not localhost.

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​