Choose Serve, sharing, or Funnel

tailscale serve exposes local content or a local server to permitted tailnet users over a tailnet HTTPS name.

You built a loopback service in a previous lesson. Serve is the piece that publishes it, privately, with a real HTTPS certificate for the device’s ts.net name.

Serve: private to the tailnet

tailscale serve --bg localhost:3000
tailscale serve status

https://lab-server.tail4a5b6.ts.net/
|-- proxy http://localhost:3000

Serve stays private to the tailnet. Only devices in your tailnet, subject to your policy, can reach that URL. The --bg flag keeps the proxy running in the background instead of holding your terminal.

Open the reported HTTPS URL from your laptop. TLS works out of the box because Tailscale provisions a certificate for the device name.

Sharing: one device, one invited user

Sharing gives a specific external Tailscale user access to a device. You send an invite, they accept from their own tailnet, and your policies still control what they can do on it. Good for “my collaborator needs the staging box” without merging two networks.

Funnel: the public Internet

Funnel is different: it publishes a local service to the public Internet. Anyone with the URL can reach it. No tailnet membership, no identity, nothing. Treat enabling Funnel with the same seriousness as opening a port on your router, because that is what it means. If the app behind it has weak or missing authentication, you just published that weakness to the world.

Choose the smallest audience and remember that application authentication may still be required. Private network does not mean logged in.

Practice the full cycle

Enable Serve, open the reported HTTPS URL from your laptop, test a denied user if available, then turn Serve off and confirm the route closes:

tailscale serve off
tailscale serve status
# No serve config

Publishing should be reversible, and you should know where the off switch is before you need it.