Learn Tailscale - Tailscale Serve & Funnel

#Introduction

So far we've connected devices and secured access. But there's one big question: how do you expose services? You have an app running on port 3000 on a home server, and you want to access it from anywhere — or even share it with the internet.

Episode 15 introduces two features that answer this: Tailscale Serve for exposing a service only inside the tailnet, and Tailscale Funnel for exposing it to the public internet. Both use automatic TLS from MagicDNS, without opening ports on a firewall.

#Tailscale Serve

#Tailscale Serve Concept

Tailscale Serve turns a node into a reverse proxy that forwards requests to a local service, accessible only from inside the tailnet. No need to open ports on a router or firewall — access is via the MagicDNS hostname with automatic HTTPS.

sudo tailscale serve 3000

The sudo tailscale serve 3000 command exposes port 3000 as https://<hostname>.<tailnet-name>.ts.net. The TLS certificate is handled automatically via MagicDNS.

#Background Mode and Status

To run serve without blocking your terminal:

sudo tailscale serve --bg 3000
tailscale serve status

tailscale serve status shows all services currently being served along with their targets.

#Serving Other Services

Serve can also proxy to a different port or handle multiple paths:

sudo tailscale serve --bg --set-path=/status 8080

The --set-path pattern lets a single hostname serve multiple services on different paths — great for sharing many internal apps from one node.

#Tailscale Funnel

#Tailscale Funnel Concept

Tailscale Funnel exposes a service to the public internet — anyone with the URL can access it, with no Tailscale account needed. Traffic still comes in through Tailscale's infrastructure and TLS is managed automatically. Funnel is useful for demos, POCs, or services that genuinely need to be public.

sudo tailscale funnel --bg 3000

The sudo tailscale funnel --bg 3000 command publishes the service to a public URL https://<hostname>.ts.net. Nodes that can use Funnel are restricted to certain regions.

#Checking Status and Disabling

tailscale funnel status
sudo tailscale funnel off

tailscale funnel off stops the public exposure. Always turn Funnel off after a demo is done — don't leave private services publicly exposed longer than necessary.

#Serve vs Funnel

#Key Differences

Serve  -> tailnet only, needs Tailscale login
Funnel -> public internet, no account
 
Serve  -> access via internal .ts.net hostname
Funnel -> access via public .ts.net hostname

• Serve: for you, your team, and devices already on the tailnet. Secure by default because ACLs govern access.
• Funnel: for the outside world. Public exposure, so make sure the app is safe and only active when needed.

#When to Use Which

• Internal dashboards, dev APIs, and tooling → Serve.
• Product demos to clients, webhooks for external services, public POCs → Funnel.
• Need TLS without certificate config → both, automatically.

#Example: Serving an Internal API

You have an API running on port 8080 on a home server and want the team dashboard to reach it:

sudo tailscale serve --bg 8080
tailscale serve status

sudo tailscale serve --bg 8080 exposes the API only to the tailnet. The team opens https://<hostname>.ts.net without needing to know the internal IP — and without opening any firewall ports.

#Best Practices

• Always start with Serve; Funnel only for clear public needs.
• Combine Serve with strict ACLs (episode 14).
• Always check serve status and funnel status regularly.
• Never expose databases or admin services via Funnel.

#Closing

Episode 15 gave you two ways to expose services: Serve for the secure tailnet and Funnel for controlled public access — both with automatic TLS and no firewall changes.

Key takeaways:

• Serve exposes a service only to the tailnet.
• Funnel exposes a service to the public internet.
• tailscale serve 3000 and tailscale funnel --bg 3000.
• TLS and hostnames are handled automatically via MagicDNS.
• Use Serve first; Funnel only when truly public access is needed.
• serve status and funnel off are must-knows for control.

In the next episode, episode 16, we'll cover Kubernetes, Docker, and containers — running Tailscale as a sidecar in Docker, the tailscale up pattern in immutable containers, and the Tailscale Kubernetes Operator for Ingress, Egress, Service load balancers, and workload identity.