Use Ollama from Android without turning your model server public.
A mobile client does not run the desktop model on the phone. It sends prompts to the Ollama HTTP server you choose, so network configuration is part of the privacy model.
At a glance
An Ollama mobile client connects an Android app to an Ollama server running on a computer or server. Ollama serves its local API at `http://localhost:11434/api` by default; reaching it from a phone requires binding to a reachable interface and allowing only the intended network path. Phos can use that user-controlled endpoint, but prompts leave the phone and should not be sent to an unauthenticated server exposed to the public internet.
How Phos handles it
Three clear routes
Local model
Not used in this route; the phone is a client rather than the inference host.
Local server
The selected Ollama machine receives prompts and generates responses under the user's control.
Bring your own key
No provider key is required for a local Ollama model; Ollama cloud models or other provider routes have separate policies.
Who this is for
Built for people with real private work to do.
Ollama users who want an Android interface on the same trusted network.
People whose phone cannot run the desired model but whose computer can.
Developers troubleshooting host, port, firewall, or model-name failures.
Privacy-minded users deciding whether LAN, VPN, or tunnel access is appropriate.
Plain comparison
The point is control, not a louder chatbot.
These pages are for people comparing real options. Phos should win when someone wants privacy, local control, no account wall, and an assistant that still feels good to use.
| Feature | Phos | Typical cloud chatbot | Raw local app |
|---|---|---|---|
| Inference hardware | The Ollama host computer. | Provider data center. | Phone for on-device apps. |
| Default endpoint | User enters a reachable Ollama base URL. | Vendor-managed HTTPS URL. | No HTTP server required. |
| Network requirement | Phone must reach the host over LAN, VPN, or secured tunnel. | Internet required. | None after model download. |
| Primary risk | Over-broad bind, firewall exposure, or insecure remote access. | Provider policy and account exposure. | Device compromise and resource limits. |
Understand localhost before changing it
Ollama's official API documentation uses `http://localhost:11434/api` as the default base. On the Ollama computer, localhost means that same computer. On Android, localhost means the phone, so copying the default URL into a mobile client cannot reach the desktop. The server must listen on an address reachable from the phone, and the client must use the computer's LAN address or a protected hostname.
Ollama documents `OLLAMA_HOST` for changing the bind address. Setting it to `0.0.0.0:11434` listens on available interfaces, which improves reachability but expands exposure. Apply a host firewall rule, keep the service off guest or public networks, and prefer a private VPN for remote use. A bind change is not authentication.
Use a least-exposed connection pattern
For a home setup, place both devices on a trusted private network, bind Ollama only as broadly as necessary, and restrict port 11434 to the local subnet or the phone's VPN range. Do not port-forward the raw API from a consumer router. If access must cross the internet, terminate TLS and authentication in a properly configured reverse proxy or use a private mesh VPN that limits membership.
Ollama's FAQ documents proxy and tunnel patterns, but an example showing reachability is not a complete production security design. Review header handling, origin rules, logs, update policy, and credential rotation for the surrounding layer. Phos does not make an open Ollama endpoint safe merely by connecting to it. The server owner remains responsible for access control.
Diagnose the connection in a fixed order
First confirm Ollama answers on the host and that the requested model appears locally. Next test the host's LAN address from another trusted device. Then check that Android and the computer are on networks that can route to each other; guest Wi-Fi commonly isolates clients. Finally inspect the host firewall, endpoint scheme, port, and Phos profile. A model-not-found response proves networking works and shifts attention to the model identifier.
Timeouts usually indicate routing, bind, firewall, or sleeping-host problems. Immediate connection refusal suggests nothing is listening at that address. An HTTP response with an error body points to endpoint path, model name, or request compatibility. Record the exact base URL without publishing private addresses. Avoid disabling the entire firewall as a diagnostic shortcut; create one scoped rule and remove it if the test fails.
Know what remains private
With a local Ollama model, Ollama states that prompts and answers are not sent back to ollama.com. The prompt still crosses the network from phone to host, resides in client and server memory, and may appear in application or proxy logs. If the host uses an Ollama cloud model, that is a different route and Ollama's cloud policy applies. A mobile client should not collapse those cases into one 'local' label.
Protect both ends. Use device locks, update Ollama and the operating systems, limit server listeners, and delete sensitive chat state where stored. If the task fits the phone's local model, on-device inference removes the network hop entirely. If the desktop model is materially better, a secured personal server can be a sensible compromise with a boundary the user controls.
Direct answers
Frequently asked questions
Why does localhost not work from my phone?
On Android, localhost refers to the phone. Use the Ollama computer's reachable private address after configuring Ollama and the firewall for that trusted network.
Should I expose port 11434 to the internet?
Do not directly port-forward an unauthenticated raw endpoint. Use a restricted private VPN or a carefully authenticated TLS reverse proxy if remote access is necessary.
Does Ollama send local prompts to its cloud?
Ollama states that locally run models do not send prompts or data back to ollama.com. Cloud-hosted Ollama models are a separate service boundary.