--- title: "Tailscale Serve: HTTPS for 50 self-hosted apps, none of them on the internet" description: Every app on my Mac mini listens on 127.0.0.1 only, and tailscale serve gives each one an HTTPS URL that only my own devices can reach. No open ports, no reverse proxy to maintain, real certificates for the phone. Here's the setup and the four traps I hit. date: 2026-10-09 tags: Tailscale, self-hosting, networking, homelab, security --- I run about 50 small apps on a Mac mini at home: dashboards, PWAs, APIs for my phone apps, a local Ollama. None of them is reachable from the internet, and none listens on my home network either. Each app binds to `127.0.0.1`, and **`tailscale serve`** puts it on my tailnet at `https://..ts.net:`, with a real certificate, reachable only from my own devices over Tailscale's encrypted WireGuard tunnel. One command per app, nothing else to run: ```bash tailscale serve --bg --https 5174 http://127.0.0.1:5174 ``` ## The path a request takes

The internet

Anyone elseno route in

My tailnet

My devices

Open the ts.net URL

Mac mini

Funnel off

tailscale serve

The certificate ends here

127.0.0.1

51 serve entries, every one tailnet only

Zones inside zones. The request is encrypted all the way to serve, and only the last step inside the box is plain HTTP. Each square is one of the 51 serve entries.

Right now `tailscale serve status` lists 51 entries, every one marked *tailnet only*. None uses Funnel, the feature that would publish a port to the public internet. ## Why HTTPS, when the tunnel is already encrypted WireGuard already encrypts the traffic between my devices, so plain HTTP would be private enough. HTTPS is for the browser. iOS only runs a PWA's service worker on a secure origin, so without it my phone apps lose offline mode and the home-screen install. Tailscale issues the certificate for the machine's `ts.net` name, so there's nothing to renew by hand. One detail: use the full name. `https://:5174` fails because the certificate is for the `ts.net` name, not the short one.

The tunnel, no certificate

HTTP

Private enough: WireGuard encrypts it

iOS won't run the service worker

No offline mode, no home-screen install

The same tunnel, plus a certificate

HTTPS

A secure origin, so the browser trusts it

Service worker, offline mode, install

Tailscale issues the cert: nothing to renew

https://<machine>:5174✗ the cert is for the ts.net name

https://<machine>.<tailnet>.ts.net:5174✓ matches the cert

Use the full nameThe short one fails the certificate.

Both phones sit on the same encrypted tunnel, the blue line. What changes is what the browser lets my phone apps do, and that depends on the certificate, not on the network.

## Why loopback, not the LAN Binding the app to `127.0.0.1` means the only way in is through `tailscale serve`. A guest on my Wi-Fi can't reach it, and neither can a misconfigured router. In Docker that's the host part of the port mapping: ```yaml ports: - "127.0.0.1:5174:80" # loopback only; tailscale serve proxies to it ```

A guest on my Wi-Fi
LAN address ✗
nothing listening
A misconfigured router
LAN address ✗
nothing listening
My phone, on the tailnet
tailscale serve
127.0.0.1 → the app

The Docker port mapping

127.0.0.1host address: loopback only
5174host port: tailscale serve proxies to it
80the port inside the container

One way inThrough tailscale serve, or not at all.

Three ways to knock, one door that opens. The highlighted part of the mapping is what keeps the other two out.

## Four traps I hit | Trap | What I saw | Fix | |---|---|---| | Serve entry lost | App answers on `127.0.0.1`, the tailnet URL doesn't connect | The entry disappeared after a Tailscale restart. Check `tailscale serve status`, re-add it | | App bound to the LAN IP | Serve returns errors, loopback is empty | A change bound Docker to the LAN address. Back to `127.0.0.1:port` | | Bind race (Ollama) | After a reboot, Ollama crash-loops on `address already in use` | Ollama's "Expose to network" took `0.0.0.0:11434` while serve held the same port on the tailnet address. Turned Expose off | | Host check (Ollama) | 403 through serve, fine locally | Serve forwards the `ts.net` Host header and Ollama on loopback rejects it. A small nginx hop rewrites the Host | The last two only bit Ollama, but the lesson is general: serve proxies the request as-is, so an app that checks the Host header or wants the port for itself needs a look.

1Serve entry lost
Fixre-add it; the app was fine all along
2App bound to the LAN IP
Fixbind back to 127.0.0.1
3Bind raceOllama
Fixturn off Expose to network
4Host checkOllama
Fixan nginx hop rewrites the Host

The lessonServe passes the request on as-is.

The same path four times, with the hop where each trap stopped my request. The yellow square is the request; the last two traps only hit Ollama.

## What I'd tell someone starting - **Bind every app to loopback** and let `tailscale serve` be the only door. - **Use HTTPS from day one** if a phone will open it. PWAs need it. - **Keep a list of the ports.** With 50 apps, a port registry saves you from two apps fighting over one number. - **Check `tailscale serve status` first** when a URL stops working. Most of my outages were a missing entry, not a broken app.

1Loopback only

Serve is the one door
2HTTPS, day one

If a phone opens it, its PWA needs it
3A list of the ports

Two apps never fight over one number
4Status first

Most outages: a missing entry, not a broken app

The same four habits, drawn. The fourth has the blue frame because that's where most of my outages turned out to be.