Two people in the same flat sharing one local model, three kids reaching the family PC from their laptops, a small studio team running on one workstation: the word “household” is fuzzy but the practical shape is the same. One machine holds the GPU, several devices that are not it want answers, and the model needs a private way to reach them.
Pick the chat front end before you pick the bind address
Most guides to serving locally spend their time on the inference server and treat the chat UI as an afterthought. In a household the front end matters more, because nobody else in the house is going to run curl against localhost:11434. The first decision is which UI people will open in a browser or pin to a phone home screen.
Open WebUI is the most common choice. It is a separate container or Python app that sits in front of Ollama (or an OpenAI-compatible server such as llama.cpp’s server or LM Studio’s server) and gives you accounts, chat history, model pickers and a responsive web UI. The Docker image exposes container port 8080 and is conventionally mapped to host port 3000, so the URL the household opens is host-name:3000 on the LAN. The environment variable reference documents ENABLE_SIGNUP defaulting to True, so unless you flip it off in the admin panel after your own account exists, anyone who can reach the URL can register.
LM Studio bundles its own chat UI for desktop use and exposes a local OpenAI-compatible API when “Serve on Local Network” is toggled on. The UI itself is desktop-only, so LM Studio is the right answer when the household’s “other devices” are laptops that already run the LM Studio app, not phones. For everything else, Open WebUI is the cheaper and more flexible choice.
A third option, mostly for technical users, is to skip the chat UI and point a tool that already speaks the OpenAI API at the inference server directly: Continue, OpenHands, SillyTavern, the API client in your editor. That works, but it asks every member of the household to install and configure a client app, which most people will not do.
| Chat UI | Install | Multi-user | Mobile-friendly | Talks to |
|---|---|---|---|---|
| Open WebUI | Docker or pip install open-webui | Yes (accounts, roles, history) | Yes, responsive web UI | Ollama via OLLAMA_BASE_URL, or any OpenAI-compatible server |
| LM Studio built-in UI | Desktop app | Per-device; no shared accounts | No (desktop only) | LM Studio’s own local server |
| Raw API only | Whatever the client is | No UI layer | Whatever the client is | Direct to inference server |
Bind to the LAN, then stop
Three of the four mainstream inference servers bind to 127.0.0.1 by default. Ollama’s FAQ states that “Ollama binds 127.0.0.1 port 11434 by default”; the llama.cpp server documents --host as defaulting to 127.0.0.1 on port 8080; LM Studio serves on 127.0.0.1 until “Serve on Local Network” is on. So far, so safe.
Exposing any of them to the rest of the LAN is a one-line change, and that is the moment decisions matter. Ollama flips to LAN mode when you set OLLAMA_HOST=0.0.0.0:11434, which the FAQ shows you how to do on macOS (launchctl setenv), Linux (systemctl edit ollama.service) and Windows. llama.cpp’s --host 0.0.0.0 and LM Studio’s “Serve on Local Network” do the same thing on their respective ports. None of them turns on authentication at the same time. The Ollama FAQ explicitly allows cross-origin requests from 127.0.0.1 and 0.0.0.0 by default, so any browser on the same network can hit it without an OLLAMA_ORIGINS change.
The single most common failure is to bind the inference server and then forget about authentication, because none of the four engines has any on its API surface. The right shape is to bind, then put an authenticated front end or an authenticated reverse proxy on top of it. Open WebUI is the front end; the Open WebUI hardening guide names “A VPN (WireGuard, Tailscale)”, “A zero-trust access proxy (Cloudflare Access, Pomerium)” or “A reverse proxy with authentication and IP allowlisting” as the three layers that turn a LAN-bound server into one that is safe to leave running.
An overlay network is the simplest fix
For a household of two to six people the simplest and least error-prone pattern is an overlay network. Every device a household member actually uses - laptop, phone, tablet - joins the same private mesh, and the inference server is reached by its overlay address, not by any address on the LAN. To the home router the overlay traffic looks like ordinary encrypted UDP, and the server’s LAN port stays bound to 127.0.0.1.
Tailscale is the easiest overlay to set up. The install docs walk through creating a tailnet, signing in on each device with the same identity, and ending up with each machine assigned a 100.x.y.z IP. MagicDNS registers a fully qualified name for each node - typically <hostname>.<tailnet>.ts.net - and on tailsnets created after 20 October 2022 it is on by default, so the desktop’s overlay hostname resolves from a phone on the same Wi-Fi or, more usefully, from a phone on cellular when nobody is home. Public email domains land on the Personal plan, which covers up to six users for free, which fits the median household exactly.
WireGuard is the same idea with more setup. The quickstart shows the steps: generate a keypair per peer, define a small [Peer] block per device, listen on UDP 51820 by convention, and use wg-quick for the bring-up. It is faster, smaller and has no central control plane, but every peer has to be added by hand to every other peer’s config. For a household with one server and three or four clients it is a Sunday-afternoon project; Tailscale is a five-minute one.
The practical consequence is that Ollama never needs OLLAMA_HOST=0.0.0.0. It stays bound to 127.0.0.1, Open WebUI stays on its own loopback (the standard Docker -p 3000:8080 is what publishes it on the host), and only the overlay network sees them. The home router never sees a request, the model server’s API has no public surface, and the household can keep using the setup while travelling.
Concurrency decides how many people the server actually serves
The second ceiling is concurrent users. Ollama’s OLLAMA_NUM_PARALLEL defaults to 1, and a second user hitting it while the first is mid-prompt gets queued up to OLLAMA_MAX_QUEUE (default 512) past which the engine returns a 503. Two people can therefore share a household Ollama without problems; three or more will see visible queueing on longer prompts. llama.cpp’s server exposes -np, --parallel for slot count and turns on continuous batching by default, so a single llama.cpp server handles more simultaneous users than a stock Ollama install on the same hardware.
The reasoning is the same in all cases: a local model is not a hosted API, and a single GPU has one decoder. Putting the inference server behind Open WebUI on a Tailscale tailnet does not change that - it just stops you from also having to defend a public port. The choice of which model to run is also a concurrency choice: a smaller model in the 8GB tier can serve two people at near-interactive speeds; a 30B-class model serves one person well and the second person slowly.
Mobile, tablets, and the URL everyone actually opens
For phones and tablets the chat UI is the only thing that matters, and nobody is going to install a local model client on iOS in 2026. Open WebUI’s web UI is the practical answer. Bookmarking http://<server>.ts.net:3000 in mobile Safari or Chrome and adding it to the home screen gives a near-native icon that loads the chat UI full-screen. The catch is iOS’s aggressive tab eviction: a long generation will be killed if the browser backgrounds the tab, and Open WebUI will not resume it. Setting Ollama’s keep_alive parameter keeps the model loaded in VRAM between requests so the next prompt is fast even after the tab is reloaded. llama.cpp’s server keeps the model loaded by default between requests, so the same outcome holds there without an extra knob.
For the household that wants a real app icon there are also third-party iOS and Android wrappers, but those are community projects and the policy on what they do with prompts varies. Treat any wrapper that asks for an Open WebUI URL and a password as “the same risk as the web UI plus the wrapper’s own code” and read the wrapper’s source before pointing it at a chat log.
Bottom line
Pick Open WebUI as the chat front end for everyone in the house who is not already an Ollama or LM Studio power user. Bind Ollama or llama.cpp only as far as the household actually needs - loopback is enough when an overlay is in front - and put a Tailscale tailnet in front of the Open WebUI port so the URL stays a private one. For two to four concurrent users the stock Ollama defaults are fine; for five or more, raise OLLAMA_NUM_PARALLEL or move to llama.cpp’s server. None of the engines has authentication, so the overlay network or the reverse proxy is what carries it.