Access Open WebUI Outside Your Home Network Using Tailscale

How to Access Open WebUI Outside Your Home Network Using Tailscale

by

Got Open WebUI running great on my home server, then immediately ran into the obvious wall — it only worked on my home Wi-Fi. First instinct was port forwarding, which I then learned is basically dead for a lot of people now thanks to Carrier Grade NAT. Tailscale ended up being the actual fix, and it’s a lot less painful to set up than I expected going in.

Quick Answer

  • Install Tailscale on your Open WebUI server and on whatever device you want to access it from (phone, laptop, doesn’t matter)
  • Sign into both with the same Tailscale account so they join the same private network (your “tailnet”)
  • Find your server’s Tailscale IP (something like 100.x.x.x) using tailscale ip
  • On your remote device, open http://<tailnet-ip>:8080 (or whatever port Open WebUI is running on) — same login screen as your home network, just reachable from anywhere
  • For a proper domain name and valid HTTPS instead of typing an IP and port, set up Tailscale Serve, which is a few extra steps but worth doing eventually

That covers getting in from outside your house. So let’s get into why this actually works better than the old port-forwarding approach, and where people tend to get stuck.

Why Tailscale Instead of Port Forwarding

Port forwarding used to be the standard advice for this kind of thing, and it just doesn’t hold up the way it used to.

Carrier Grade NAT breaks port forwarding for a lot of people now. If you’re on 5G home internet, Starlink, or live in an apartment building sharing infrastructure, there’s a real chance your router never even sees a true public IP address — it’s sharing one with other customers behind your ISP’s own NAT layer. Port forwarding requires control over a real public IP, and a lot of people just don’t have that anymore, full stop, no amount of router configuration fixes it.

Open WebUI and Ollama weren’t built with public exposure in mind. They assume a trusted local network. Forward the port directly to the internet without serious extra security layered on top, and you’re exposing a service that has no real defense against random traffic — anyone scanning for open ports can hit it, consume your GPU running prompts you never asked for, and you might not notice for a while.

Tailscale sidesteps the NAT problem entirely. Instead of opening a port to the public internet, Tailscale builds a private mesh network (a “tailnet”) between your specific devices, using WireGuard under the hood. Your server gets a stable private address in the 100.64.0.0 range that only devices on your tailnet can see or reach. No port forwarding required, because nothing’s actually exposed to the open internet at all.

Common Scenarios

  • Single home server, accessing from your phone on the go — the simplest case, just install Tailscale on both ends and connect by tailnet IP
  • Self-hosted on a NAS (Synology, Unraid) with Ollama on a separate PC — slightly more moving parts, since you’re often bridging Tailscale across two different devices rather than one
  • Docker-based setups with a Tailscale sidecar container — more advanced but gives you HTTPS and a clean hostname without manually configuring the host machine’s networking
  • Wanting to share access with someone outside your own tailnet — this needs Tailscale Funnel specifically, which is a different (and more exposed) setup than basic tailnet access

Step-by-Step Setup

Step 1: Install Tailscale on your Open WebUI server

Download from tailscale.com/download and follow the install for your OS. On Linux, the official install script handles the repository setup automatically — no manual dependency wrangling needed.

Step 2: Authenticate

Run tailscale up. It’ll print a URL — open that in a browser and sign in with Google, GitHub, Microsoft, or a dedicated Tailscale account. Whatever you used to sign in here is the account every device needs to share to land on the same tailnet.

Step 3: Note your server’s tailnet IP

Run:

tailscale ip

You’ll get something like 100.73.42.158. That’s the private address your server now has on the tailnet — write it down, you’ll need it for the next step.

Step 4: Install Tailscale on your remote device

Same install process, same account, on your phone or laptop. iOS and Android both have official Tailscale apps in their respective stores, free for personal use up to 100 devices, which is plenty for most home setups.

Step 5: Connect to Open WebUI from the remote device

Open a browser on the remote device and go to:

http://<your-tailnet-ip>:8080

(Substitute whatever port Open WebUI is actually running on — 3000 and 8080 are both common depending on how you set it up.) You should land on the exact same Open WebUI login screen you see at home, just reached through the tailnet instead of your local Wi-Fi.

Step 6: Set up Ollama as a connection if it’s on a separate machine

If Ollama runs on a different device than Open WebUI, go to Settings > Admin Settings > Connections in Open WebUI, and add the Ollama instance using its tailnet IP and port — typically something like http://100.x.x.x:11434. Once that connection’s added, you can pull and manage models from the Open WebUI interface as if everything were on one machine.

Getting Proper HTTPS with Tailscale Serve

Typing an IP and port works, but it’s clunky, and some browser features (voice input, for example) expect HTTPS to function at all. Tailscale Serve fixes both.

  1. In the Tailscale admin console, go to DNS and enable HTTPS Certificates for your tailnet
  2. Set up a serve.json config that proxies to your Open WebUI container — something like routing / to http://open-webui:8080
  3. If running in Docker, add a Tailscale sidecar container alongside Open WebUI, pointing TS_SERVE_CONFIG at that serve config
  4. Set WEBUI_URL in your Open WebUI environment variables to your tailnet hostname (something like https://my-server.tail1234.ts.net) so internal links and any OAuth callbacks resolve correctly

Once that’s running, you access Open WebUI at a clean hostname with a valid certificate, no port number needed, and no separate reverse proxy to maintain — Tailscale handles the TLS termination itself.

What Actually Worked For Me

First attempt, I just used the plain http://100.x.x.x:8080 approach and called it done — worked fine on my laptop, but the voice input feature in Open WebUI silently refused to function on my phone’s browser. Took me a bit to connect that to the lack of HTTPS, since the error wasn’t exactly clear about what was missing.

So I went and set up Tailscale Serve, expecting it to be a multi-hour fight with certificates the way these things sometimes go. It actually wasn’t — the trickiest part was just getting the serve.json file pointed at the right internal Docker hostname rather than localhost, since the sidecar container and the Open WebUI container talk to each other over the Docker network, not through the host’s local loopback address. Once I fixed that one detail, the certificate provisioning itself was basically automatic, and voice input started working the moment HTTPS was in place.

Advanced Tips and Edge Cases

Use Tailscale Serve’s authentication headers for single sign-on. When traffic passes through Tailscale Serve, it automatically attaches a Tailscale-User-Login header identifying the authenticated user. Open WebUI can trust that header (WEBUI_AUTH_TRUSTED_EMAIL_HEADER) so anyone on your tailnet logs in automatically without a separate Open WebUI password — useful for a household or small team setup where you don’t want to manage individual credentials.

Tailscale Funnel is a different beast than basic tailnet access — treat it carefully. Funnel exposes your Tailscale Serve endpoint to the actual public internet, similar to a Cloudflare Tunnel. It’s the right tool if you genuinely want to share access with someone outside your tailnet, but understand that it removes the “only my devices can reach this” guarantee that makes basic Tailscale access so much safer than port forwarding in the first place.

An exit node setup gets you two benefits at once. If your server (or a NAS) is also configured as a Tailscale exit node, you can route your general internet traffic through your home connection while on untrusted networks like conference Wi-Fi, in addition to reaching Open WebUI. Two separate use cases sharing the same underlying tailnet.

OLLAMA_HOST versus Tailscale Serve for exposing Ollama specifically. Setting the OLLAMA_HOST environment variable is the more permanent way to bind Ollama to your tailnet interface directly. Using Tailscale Serve as a proxy instead lets you leave Ollama on its default localhost binding while still exposing it securely — useful if you don’t want to touch Ollama’s own configuration at all.

Prevention Tips

  • Set Tailscale to auto-connect on boot on your server, so a reboot doesn’t quietly take your remote access down until you notice and manually reconnect
  • Don’t expose ports 8080, 11434, or similar directly to your router’s port forwarding as a “quick fix” — that’s the exact exposure Tailscale is meant to avoid
  • Keep the Tailscale client updated on all devices; auth and security features have shifted over versions
  • If you ever add Funnel for public sharing, periodically check who actually has access and revoke anything you no longer need active

FAQ

Do I need a static public IP address for any of this to work? No — that’s the whole point. Tailscale works around NAT entirely, including Carrier Grade NAT, since nothing relies on your router having a real public-facing address.

Is my data actually private going through Tailscale? Yes, traffic is end-to-end encrypted via WireGuard between your specific devices. Tailscale’s infrastructure helps devices find each other, but it’s not sitting in the middle reading your Open WebUI traffic.

Can I access Open WebUI from a device I don’t own, like a friend’s laptop? Not through basic Tailscale access, no — that device would need to join your tailnet, which means installing Tailscale and signing into your account or being invited as a shared node. For occasional access without installing anything, Funnel is the option, with the tradeoff of public exposure.

Why does voice input or certain browser features not work over plain Tailscale IP access? Some browser APIs require a secure HTTPS context to function at all, and a raw http://100.x.x.x:port connection doesn’t satisfy that, even though the underlying WireGuard tunnel is already encrypted. Setting up Tailscale Serve for proper HTTPS fixes it.

Will this slow down my connection to Open WebUI compared to being on my home Wi-Fi? Usually not noticeably — Tailscale tries to establish a direct peer-to-peer connection between devices when possible, so most of the time it performs close to a direct local connection rather than routing through a distant relay.

Editor’s Opinion

tailscale genuinely feels like the right tool here, way less painful than the old port forwarding dance and a lot more secure by default. the basic IP-and-port setup takes like ten minutes and covers most people fine — only bother with serve and HTTPS if you actually need voice features or just want a cleaner url. dont skip the auto-connect-on-boot setting though, forgetting that one is how you end up locked out of your own server from three states away.

Leave a Comment