What Can You Do With Tailscale? 8 Real Uses

What can you do with Tailscale?

What can you do with Tailscale? You can reach your own machines from anywhere, as if they sat on one private network, without opening a single port on your router or your VPS. In practice people use it for eight jobs: reach devices at home, send a laptop's traffic out through a VPS, share one service privately, publish one service to the internet, administer servers with no open ports, link servers across providers, put containers on the network, and run their own control plane.

This guide is organised by those jobs. Each section gives the one command or admin-console switch that turns the job on, the limit worth knowing, and what that job does not protect. Each one links to the guide that does it end to end. If you first want the model behind it, start with what Tailscale is and how a tailnet works.

The one step every use shares

A tailnet is your private Tailscale network. Every device you log in with the same account (or invite) joins it and gets a stable address in the 100.64.0.0/10 range. Tailscale builds WireGuard tunnels between those devices. A hosted coordination server, the control plane, hands out keys and addresses. Your traffic does not pass through that server.

On a Linux VPS or home server, install and log in like this:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

sudo tailscale up prints a login URL. Open it in a browser and approve the machine. tailscale status should then list this machine and every other device on the tailnet, each with a 100.x.y.z address. A device marked offline is known to the tailnet but not connected right now.

MagicDNS is on by default for new tailnets, which means you can use a machine's name instead of its address. ssh nas or http://nas:8080 works from any other device on the tailnet.

Reach things at home from anywhere

The job: open your NAS or your Home Assistant panel while you are away, with nothing exposed to the internet.

For any device that can run Tailscale, install it there and you are done. You reach it by name from your phone or laptop. Some devices cannot run it, such as a printer or a camera. For those, one always-on machine on that LAN becomes a subnet router. It announces the LAN range to the tailnet, and it forwards traffic for that range. That machine needs IP forwarding first:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.168.1.0/24

Then approve the route in the admin console, on the Machines page, under that machine's route settings. Linux clients ignore advertised routes by default, so on a Linux laptop also run sudo tailscale set --accept-routes. Windows, macOS and phone clients accept routes on their own.

The limit worth knowing: address overlap. If your home LAN is 192.168.1.0/24 and the café network you sit on uses the same range, two routes claim the same addresses. Pick an unusual range at home if you can. The same pattern works from a VPS, and advertising private ranges from a VPS subnet router covers that side in full. If you would rather build it on plain WireGuard, see routing a WireGuard tunnel to your home LAN.

What it does not protect: a subnet router opens the whole advertised range to every tailnet device your access policy allows. The default policy allows every device to reach every other one. A new tailnet member can therefore reach your printer and your NAS login page until you narrow the policy.

Give a laptop a VPS exit IP

The job: on hotel or café Wi-Fi, send all of your laptop's internet traffic through a VPS you rent, so the local network sees only encrypted packets.

This is an exit node. On the VPS, enable IP forwarding with the same three sysctl lines as above, then:

sudo tailscale set --advertise-exit-node

Approve it in the admin console: open the machine's route settings and enable Use as exit node. On a Linux laptop, use it with sudo tailscale set --exit-node=<exit-node-ip>. Add --exit-node-allow-lan-access=true if you still need the local printer. On phones and desktops it is a menu choice. Check it from the laptop:

curl https://ifconfig.me

The address printed should now be your VPS's public IP. sudo tailscale set --exit-node= with an empty value turns it off again.

The limit worth knowing: you use one exit node at a time, and every byte you browse now counts against the VPS's bandwidth allowance. Setting up a VPS as a Tailscale exit node covers DNS and the provider firewall.

What it does not protect: an exit node moves your traffic to another IP. Websites see the VPS's IP, and that IP is tied to the account you pay with. The VPS provider can see your traffic leave the box. If you are unsure which problem you are solving, a VPS compared with a commercial VPN explains the difference.

Share one service privately with Serve

The job: give yourself or your team an HTTPS address for one web app, such as a dashboard, without putting it on the internet.

tailscale serve --bg 3000
tailscale serve status

This proxies https://<machine-name>.<tailnet-name>.ts.net to the app listening on local port 3000, with a valid TLS (transport layer security) certificate. --bg keeps it running after you close the terminal. tailscale serve status should show the URL and the local target. tailscale serve reset removes it. Serve needs HTTPS certificates enabled for the tailnet. If they are off, the CLI gives you a link to switch them on.

The limit worth knowing: only devices on your tailnet, and allowed by your policy, can open the URL. Anyone outside sees nothing. When to use Tailscale Serve and when to use Funnel compares the two side by side.

What it does not protect: Serve adds no login to your app. Every tailnet device the policy allows gets the same access as you. Also, the HTTPS certificate is recorded in public certificate transparency logs, so your machine name and tailnet name become public text. Name machines with that in mind.

Publish one service to the internet with Funnel

The job: let anyone on the internet open one service, such as a webhook receiver or a demo, while the server itself has no public port open.

tailscale funnel --bg 3000

The URL has the same ts.net form as Serve, but now it works for everyone. Funnel needs HTTPS certificates and MagicDNS. It also needs a funnel node attribute in your tailnet policy file. The CLI tells you which one is missing.

The limit worth knowing: as of October 2026, Funnel listens only on ports 443, 8443 and 10000. It works only on your ts.net name, not a custom domain, and Tailscale applies bandwidth limits you cannot change. You cannot use the same port for Serve and Funnel at the same time. The full list of Funnel limits and ports has the details and the workarounds.

What it does not protect: once Funnel is on, your app is a public website. Tailscale does no login check for it. The app's own authentication and its patch level are the only things between it and every scanner on the internet.

Administer servers with no open ports

The job: SSH into your VPS fleet with port 22 closed to the internet, using your Tailscale login instead of copying SSH keys around.

sudo tailscale set --ssh

Tailscale SSH needs two rules in your tailnet policy. One allows network access to the machine. An ssh rule says which users may log in as which local accounts. Test it from another tailnet device with ssh root@<machine-name> before you change anything else. Only after that works, close port 22 in the VPS firewall. Keep a second session open while you do it. Check mode is an option in the ssh rule. It asks the user to log in again before a session starts, every 12 hours by default.

If you prefer plain OpenSSH, you can keep it and allow port 22 only on the tailscale0 interface. Either way, using Tailscale instead of port forwarding walks through closing public ports safely.

The limit worth knowing: only Linux, and macOS running the open-source tailscaled, can act as a Tailscale SSH server. Keep your provider's web console as a way in, because if tailscaled stops, so does this path to the box.

What it does not protect: your identity provider account is now the key to every server. Protect it with a second factor. A compromised control plane could add a device to your tailnet, which is the risk tailnet lock, where your own devices sign every new node exists to remove.

Link servers across providers

The job: connect an app server at one provider to a database at another, over a private path, without exposing the database port.

Install Tailscale on both machines. Then bind the database to the tailnet address only. tailscale ip -4 prints that address. The app connects to the database by machine name. Nothing else is needed. Connecting two VPS over a private network does this end to end, with firewall rules.

The limit worth knowing: when the two machines cannot reach each other directly, traffic goes through Tailscale's DERP relay servers. DERP (designated encrypted relay for packets) keeps the link working, but it is slower. tailscale ping <machine-name> tells you which path you have. A reply via DERP(fra) means relayed. A reply via a public IP:port means direct. Why a Tailscale connection is relayed instead of direct explains how to fix it.

What it does not protect: the database is still only as strong as its own password. A tailnet path keeps internet scanners away. Other tailnet machines that the policy allows can still try to log in.

Put containers on the tailnet

The job: give one Docker app its own tailnet name, separate from the host, so you can reach it or Serve it on its own.

The official tailscale/tailscale image runs as a sidecar container. It reads an auth key from the TS_AUTHKEY environment variable, and you set its name with TS_HOSTNAME. Your app container then shares its network with network_mode: service:tailscale. Running Tailscale in Docker Compose has the full compose file.

The limit worth knowing: set TS_STATE_DIR and mount a volume for it. Without saved state, every container restart logs in as a brand new machine.

What it does not protect: an auth key is a password for joining your tailnet. A reusable key committed to a git repository lets anyone who reads the repository add machines.

Own the control plane with Headscale

The job: keep using the Tailscale clients, but run the coordination server yourself.

Headscale is an open-source reimplementation of that server. You run it on a VPS, then point each client at it:

sudo tailscale up --login-server https://headscale.example.com

Self-hosting Headscale as a Tailscale control server covers the install and the TLS setup.

The limit worth knowing: Headscale covers the core features but not all of them. Anything that depends on Tailscale's hosted infrastructure, Funnel among them, is not available.

What it does not protect: you are now the control plane. If your Headscale server is compromised, an attacker can add machines to your network. Patching it and backing it up are now your jobs.

What each use costs

This guide gives no device counts and no prices, because they change. For what the free plan includes, read the Tailscale free plan limits. For paid tiers, read how Tailscale pricing works for households and teams. Then check the live Tailscale pricing page before you decide.

Why a feature you turned on does nothing

Most failures come from a short list of causes, and each has a check you can run.

Exit node or subnet route does nothing. If you advertise routes before you enable forwarding, the CLI warns that IP forwarding is disabled and that subnet routing and exit nodes will not work. Run sysctl net.ipv4.ip_forward on the router machine. It must print net.ipv4.ip_forward = 1.

The route exists but a Linux client cannot use it. The route was never approved in the admin console, or the Linux client never ran sudo tailscale set --accept-routes. Linux clients do not accept routes until you ask.

Everything works but feels slow. Run tailscale ping <machine-name>. A reply via DERP means you are relayed. Usually a strict firewall or NAT (network address translation) on one side blocks the direct path.

For how all of this compares with running the tunnels yourself, read WireGuard compared with Tailscale.

FAQ

What is Tailscale actually used for?

Most people use it to reach their own devices and servers from anywhere without opening ports. Common jobs are reaching a home network, sending a laptop's traffic through a VPS exit node, sharing a web app with Serve or Funnel, and SSH into servers that have port 22 closed to the internet.

Can Tailscale replace a commercial VPN?

It can do one part of that job. An exit node sends your traffic out through a machine you control, so the local Wi-Fi sees only encrypted packets. It does not give you a shared IP or anonymity, because websites see your VPS's IP and that IP is tied to your account.

Do I need to open any ports to use Tailscale?

No. Tailscale makes outbound connections and uses NAT traversal to connect devices directly. When a direct path is blocked, it falls back to encrypted DERP relays. tailscale ping <machine-name> shows whether a connection is direct or relayed.

Can people outside my tailnet reach my services?

Not by default. Only devices on your tailnet, and allowed by your access policy, can connect. The exception is Funnel, which publishes one service to the public internet on port 443, 8443 or 10000. Your app's own login is then the only protection.

Is my traffic sent through Tailscale's servers?

Your traffic travels in WireGuard tunnels directly between your devices. The coordination server only hands out keys and addresses. When a direct connection fails, traffic goes through DERP relays, but it stays end-to-end encrypted, so the relay cannot read it.