Access Your Local Ollama API Remotely with Tailscale Serve (Without Opening Port 11434) — 2026 Guide

Updated: November 3, 2026. Your local Ollama server can be useful from more than the machine running the model: a laptop can host inference while your desktop, phone, or another development machine sends API requests. The unsafe shortcut is to bind Ollama to every network interface and open port 11434. That can turn a convenient local API into an unauthenticated service reachable by devices you never intended to trust.

A safer pattern for personal development is to keep Ollama on loopback and use Tailscale Serve as the HTTPS entry point. Serve proxies requests from your tailnet to a local service; it does not require you to publish Ollama's port on your LAN or expose it to the public internet. This guide builds that setup, tests the native API from a second device, and explains the access-control details that matter.

What you will build

The model host runs Ollama on 127.0.0.1:11434. Tailscale Serve accepts HTTPS requests from devices in your tailnet and forwards them to that loopback address. A remote client calls the host's MagicDNS HTTPS name, for example https://ollama-host.example-tailnet.ts.net/api/chat.

• Ollama: local inference and the native HTTP API.
• Tailscale: encrypted connectivity between devices in your tailnet.
• Tailscale Serve: an HTTPS reverse proxy to the loopback-only Ollama service.
• Client: curl, Python, or an application that can call an HTTP API.

This is for a private tailnet, not a public model-hosting service. Tailscale explicitly distinguishes Serve (tailnet-only) from Funnel (public internet access). Do not substitute Funnel for Serve in this tutorial.

Who this is for

Use this pattern if you have a desktop or home server with enough RAM/VRAM for local models and want to call it from a second computer, a private development environment, or your own scripts while travelling. It is also useful when you want to avoid maintaining a public reverse proxy, DNS record, router port-forward, and TLS certificate just to reach a personal inference server.

Prerequisites

• A machine running a current Ollama installation with at least one model downloaded.
• Tailscale installed and signed in on both the model host and the client device.
• Permission to configure your tailnet's DNS/HTTPS and access-control policy if those settings are not already enabled.
• Terminal access on the model host and a client device for testing.

The examples use Linux/macOS shell syntax. The Tailscale CLI syntax shown is the post-v1.52 form documented by Tailscale; check tailscale serve --help if your installed client differs.

Step 1: Confirm Ollama works locally

On the machine that will host the model, check that Ollama is installed and running:

ollama --version
ollama list
curl -sS http://127.0.0.1:11434/api/tags

The final command should return JSON describing the models available to that Ollama server. If the list is empty, pull a model supported by your hardware. For example:

ollama pull gemma3:4b

Model availability and resource requirements vary. If you already have a model, use its exact name from ollama list in the tests below rather than downloading another one.

Step 2: Keep the Ollama listener on loopback

Ollama's documented default is to bind to 127.0.0.1:11434. That is what we want: only local processes should be able to reach the backend directly. Tailscale Serve will be the remote entry point.

Check the listening address on Linux:

ss -lntp | grep 11434

On macOS, use:

lsof -nP -iTCP:11434 -sTCP:LISTEN

Look for 127.0.0.1:11434 or localhost:11434. If you see 0.0.0.0:11434 or a LAN address, inspect your Ollama service configuration and remove any setting that changed OLLAMA_HOST to a wildcard address. Restart Ollama after correcting it, then repeat the local API test.

Do not set OLLAMA_HOST=0.0.0.0 for this design. That setting is commonly used for direct LAN access, but it defeats the loopback-only boundary we are deliberately keeping.

Step 3: Check your Tailscale connection

On the model host and the client, verify that Tailscale is connected:

tailscale status

Both devices should appear in the same tailnet (or be shared in a way that grants the required access). On the host, note its machine name and full MagicDNS name. MagicDNS lets tailnet devices resolve machine names without manually tracking changing IP addresses.

Step 4: Enable MagicDNS and HTTPS certificates

Tailscale Serve uses an HTTPS URL with a certificate for your tailnet device name. In the Tailscale admin console, open DNS, make sure MagicDNS is enabled, and enable HTTPS certificates if they are not already enabled. The first Serve command can also guide you through unmet requirements.

One privacy detail: Tailscale's HTTPS certificate setup publishes the machine and tailnet DNS names in a public certificate-transparency ledger. The service itself remains restricted by tailnet access controls, but avoid sensitive information in machine names before enabling certificates.

Step 5: Publish Ollama through Tailscale Serve

On the model host, run:

tailscale serve --bg 11434

The --bg flag configures Serve to run in the background and persist across a reboot or Tailscale restart. The command should report a URL available within your tailnet, similar to:

https://ollama-host.example-tailnet.ts.net

Use the exact hostname printed by your command. Do not copy the example hostname literally. The target port is forwarded to the local service; the Ollama process itself can remain bound to loopback.

Inspect the active configuration:

tailscale serve status

Confirm that the HTTPS endpoint proxies to 127.0.0.1:11434. If the CLI asks you to approve HTTPS or another prerequisite, complete the consent flow in the browser and rerun the command.

Step 6: Test the API from another device

Switch to a second device that is signed in to your tailnet. Set a shell variable to the hostname printed by Tailscale (without a trailing slash):

OLLAMA_URL="https://ollama-host.example-tailnet.ts.net"

First, list the models exposed by the host:

curl -sS "$OLLAMA_URL/api/tags"

You should receive the same model inventory you saw on the host. Next, send a small chat request. Replace the model value with an exact name returned by /api/tags:

curl -sS "$OLLAMA_URL/api/chat" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gemma3:4b",
    "messages": [
      {"role": "user", "content": "Reply with the word connected."}
    ],
    "stream": false
  }'

A successful response is a JSON object containing an assistant message. With stream: false, the API returns one JSON response rather than a stream of JSON lines. If you use a different model, update the request accordingly.

Step 7: Call it from Python

Any HTTP client that can reach the tailnet hostname can call the native Ollama API. For a quick Python test, install Requests in a virtual environment:

python -m venv .venv
source .venv/bin/activate
python -m pip install requests

Create remote_ollama.py:

import requests

OLLAMA_URL = "https://ollama-host.example-tailnet.ts.net"
MODEL = "gemma3:4b"  # Replace with a model listed by /api/tags

response = requests.post(
    f"{OLLAMA_URL}/api/chat",
    json={
        "model": MODEL,
        "messages": [
            {"role": "user", "content": "Summarize what a reverse proxy does in two sentences."}
        ],
        "stream": False,
    },
    timeout=180,
)
response.raise_for_status()
print(response.json()["message"]["content"])

Run it from the client device:

python remote_ollama.py

The first request may take longer while the model loads. The timeout is intentionally longer than a typical web request because inference speed depends on the host hardware, model size, context length, and current load.

Step 8: Restrict who can reach the endpoint

Do not assume that a hard-to-guess MagicDNS hostname is authentication. Tailscale Serve applies your tailnet's access-control rules. Review the policy in the admin console and allow only the intended users or tagged devices to reach the model host on the Serve HTTPS port (normally TCP 443). Prefer a narrow grant for a specific developer group or device tag over broad access to every tailnet member.

Also check your current policy rather than assuming it is restrictive. Tailscale documents that a tailnet with no access-control policy uses a default allow-all policy. If your tailnet has multiple people or devices you do not fully control, configure least-privilege access before sharing the endpoint.

Ollama's local API does not require an API key for local requests. Tailscale's identity headers are added by Serve, but Ollama does not automatically turn those headers into application-level user authorization. The practical protection in this simple design is that only devices permitted by your tailnet policy can reach the Serve endpoint, while the backend remains on loopback. If you need per-user quotas, API keys, audit logs, or application roles, put an authenticated gateway in front of Ollama rather than treating tailnet membership as a complete application security system.

Step 9: Understand the boundary: Serve is private, Funnel is public

Use tailscale serve for tailnet-only access. Do not run tailscale funnel for this tutorial: Funnel is designed to make a service reachable from the public internet, including by people who are not in your tailnet. A public URL in front of an Ollama API that has no built-in local API key requirement is a materially different and much riskier deployment.

If you no longer need the share, inspect tailscale serve status and use the matching off command shown in the current CLI reference. Be careful with tailscale serve reset: it clears the device's Serve configuration, which may include other services you have configured.

Troubleshooting

Security and privacy checklist

• Keep Ollama bound to loopback; do not expose port 11434 directly on your LAN or public interface.
• Use tailscale serve, not Funnel, for private tailnet access.
• Restrict TCP 443 to specific users/devices with tailnet grants or ACL policy.
• Do not assume a tailnet hostname is a password or that Ollama validates Tailscale identity headers.
• Keep the host OS, Ollama, and Tailscale updated; remove devices and users that no longer need access.
• Remember that prompts and responses are processed on the model host. Anyone with authorized access may be able to submit prompts and consume its CPU, RAM, GPU, and electricity.
• Do not send secrets or regulated data unless your own policies permit it and you have secured the host, client devices, logs, and backups.

Limitations and trade-offs

This is a convenient private-access pattern, not a multi-tenant inference platform. Tailnet reachability is coarse-grained compared with application-level identity, quotas, per-project model permissions, and request auditing. A single Ollama process also shares the host's compute and memory across callers. If multiple developers need independent credentials, rate limits, routing, or observability, use an authenticated gateway such as LiteLLM and keep its own access controls configured correctly.

The model host must remain powered on, Ollama must be running, and Tailscale must be connected. Tailscale Serve does not move inference to the client and does not remove model hardware requirements. It only provides a private route to the service.

Frequently asked questions

Does this expose port 11434 to the internet?

No. In this design, Ollama remains on loopback and Tailscale Serve provides an HTTPS endpoint reachable within your tailnet. Do not enable Funnel or create a separate public port-forward.

Do both devices need Tailscale?

Yes. The client must be an authorized device in the tailnet (or have an explicitly supported shared-device arrangement with the necessary access).

Do I need to set OLLAMA_HOST=0.0.0.0?

No. That is the opposite of this design. Keep the Ollama backend on its loopback listener and let Serve proxy to it.

Can I use the OpenAI-compatible endpoint?

Ollama documents an OpenAI-compatible local base URL at /v1. Through the same Serve hostname, a compatible client can use https://your-host.ts.net/v1. Check the specific client's API compatibility and remember that this does not add authentication.

Can I use this for a production application?

It can be useful for private development and trusted internal tools, but do not treat this minimal setup as a complete production gateway. Add application authentication, authorization, rate limiting, monitoring, and operational controls where your use case requires them.

Related GyanAangan guides

• Run Ollama in Docker with an NVIDIA GPU — for deploying and operating the model host.
• Build a Local LLM Gateway with LiteLLM — for API keys, routing, and a more controlled application-facing endpoint.
• Ollama Structured Outputs with Pydantic — for validating structured responses from your local model.
• Build a Private Document Q&A Assistant with Ollama and Python — for a local RAG workflow that can use the remotely reachable host.

Primary sources and further reading

• Ollama FAQ (official repository) — default loopback binding and the OLLAMA_HOST environment variable.
• Ollama API introduction — local API base URLs and API usage.
• Ollama API reference — native chat endpoint and request format.
• Tailscale Serve CLI reference — current command syntax, background mode, status, and configuration.
• Tailscale Serve documentation — tailnet-only access, HTTPS, identity headers, and limitations.
• Tailscale Grants — least-privilege network and application access controls.
• Tailscale Funnel documentation — why public exposure is different from private Serve access.
• Tailscale HTTPS certificate setup — MagicDNS, HTTPS enablement, and certificate-transparency considerations.

Verification note: This guide is based on the linked official documentation, checked on November 3, 2026. The commands are documented examples, not a claim that this exact configuration was executed on a live host during article preparation. Verify your installed Tailscale CLI version, tailnet policy, model name, and local Ollama listener before relying on the endpoint.