UCompute engineering notes

What binding a local AI server to 0.0.0.0 exposes, and a sixty-second self-check

Development build, October 2026. The checks below apply to any local model server; the UCompute section is at the end and is clearly marked. UCompute is in development. There is no public release or download yet.

Most local model servers start on the loopback address, so only programs on the same computer can reach them. The trouble starts with the one-line change every “use it from my laptop” tutorial recommends: set the bind address to 0.0.0.0. That line does not mean “my other devices”. It means every network interface this computer has, and anyone who can reach any of them.

What the defaults are, in the tools’ own words

All three are safe by default and all three document how to widen the bind. The risk is not the default; it is the widened bind. Change the address and, unless you also set a key, the server answers anyone who can reach it.

Why this is not hypothetical

On 1 September 2025 Cisco published a Shodan study of internet-reachable Ollama servers: 1,139 exposed instances, 214 of them serving models; by Cisco’s count, 88.89 % of the exposed servers used the OpenAI-compatible route structure (Cisco). Elastic ships a detection rule, “Ollama API Accessed from External Network”, whose suggested mitigation is to set OLLAMA_HOST=127.0.0.1:11434 or apply firewall rules (Elastic). Those counts are internet scans by one method on one date; they say nothing about how many servers are exposed today.

The internet is the visible case. The quieter one is the shared network: a dorm, a co-working space, an office, a hotel or guest Wi-Fi. A server bound to 0.0.0.0 with no key is reachable by everyone on that network, no port forwarding required. A firewall may block it, or may not, depending on the network profile your operating system chose when you joined.

The sixty-second self-check

Run the command for your system and look at the address column next to your server’s port (Ollama 11434, llama-server 9931 or 8080, or whatever your tool documents).

macOS

lsof -nP -iTCP -sTCP:LISTEN | grep -E ':(11434|9931|8080|1234) '

Linux

ss -tlnp | grep -E ':(11434|9931|8080|1234) '

Windows (PowerShell)

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -in 11434,9931,8080,1234 |
  Select-Object LocalAddress, LocalPort, OwningProcess

How to read the address:

You see It means
127.0.0.1 or [::1] Loopback only. Programs on this computer can connect; nothing else can.
0.0.0.0, *, [::] or :: Every interface. Any device that can route to this computer can connect, subject to your firewall.
A specific address such as a 192.168.x.y LAN address That one network. Everyone on it can connect, subject to your firewall.

If you see anything other than loopback and you did not mean to, set the bind back (for Ollama, OLLAMA_HOST=127.0.0.1:11434; for llama-server, drop --host or pass --host 127.0.0.1) and restart the server. To confirm from outside, use a second device you own on the same network and request the model list (for Ollama, curl http://<this-computer's-address>:11434/api/tags). If it answers, so would anyone else’s device on that network. Only test machines you own.

If you do need a second device

Widening the bind is the simplest way to reach a model from another machine, and it is also the one that grants access to the network rather than to a device. If you keep it:

  1. Set an API key where the server supports one (llama-server --api-key; LM Studio’s authentication setting). A shared key is better than none, though it cannot be withdrawn from one device without changing it everywhere.
  2. Bind to the one interface you mean, not 0.0.0.0.
  3. Keep the firewall rule scoped to private networks, and remember that “private” is a label your operating system applied, not a property of the café.
  4. Or put the server behind something that authenticates devices (an SSH tunnel, a VPN or mesh VPN you control) and leave the server itself on loopback.

What UCompute does (development build)

UCompute takes a different route to the second device: pairing instead of a wider bind. Everything below is a development build, October 2026.

None of this makes the self-check above unnecessary: whatever you run, the address column is the fact. No platform is declared supported yet. macOS 26.2 on Apple M2 and Windows 11 on an Intel Core Ultra 7 258V with Arc 140V are experimental; Linux, other GPUs and phones (as clients) are planned.

UCompute runs models through a pinned release of llama.cpp (MIT; b11609 in the October 2026 development builds), downloaded on first use and verified against a pinned SHA-256 hash; UCompute does not write its own inference kernels. UCompute’s code is licensed under Apache-2.0. The source has not been published yet.


Corrections and questions: hello@ucompute.org. Please send anything security-related there rather than posting it publicly. UCompute is in development. There is no public release or download yet.

Follow new notes: Bluesky @ucompute.org or the Atom feed.