Tailscale Setup Guide: Install to Your First Tailnet

Getting two devices talking over Tailscale takes about five minutes. Getting a tailnet you will still be happy with in six months takes about an hour, and the difference is almost entirely in the decisions you make before and immediately after that first login. This guide walks the setup in the order those decisions actually arrive.

If the underlying model is unfamiliar, read how a Tailscale mesh VPN works first. This page assumes you know that the coordination server distributes keys and never carries your data.

Decide who owns the identity before you click anything

Tailscale has no local user database. Every account is bound to an SSO identity provider, and the provider you choose on the very first login becomes the owner of the tailnet. Changing it later is a migration, not a setting.

The Tailscale documentation notes that the plan you land on is also derived from that first sign-in. Sign up with a public domain address such as @gmail.com and you are enrolled in the free Personal plan. Sign up with a custom-owned domain and you are automatically enrolled in a 14-day Enterprise trial instead, which has to resolve into a paid tier or drop back down when it lapses. That surprises people who sign up with a work domain for a two-device homelab and then find themselves fourteen days into an enterprise trial.

Two practical rules follow:

• For a personal or homelab tailnet, sign in with a personal account you will still control in five years. Do not use an employer identity for infrastructure you own.
• For anything shared with other people, sign in with the domain that will still be the organisation’s identity provider after the next reorganisation.

According to Tailscale’s published pricing, the Personal tier is free, covers up to six users with unlimited user devices, and includes 50 tagged resources plus 1,000 minutes a month of ephemeral-resource time. For a homelab, the six-user ceiling is the only line most people ever touch, and devices are not what runs out. The paid Standard and Premium tiers, listed at $8 and $18 per user per month respectively, lift the user limit and add the provisioning, posture, logging and just-in-time access features; Premium is also where the ephemeral allowance goes to 10,000 minutes. Check the pricing page before budgeting, since tiers and limits are revised periodically.

Install the client and bring up the first node

Install the package for the platform, then bring the interface up. On Linux that is:

sudo tailscale up

The command prints an authentication URL. Open it, sign in with the identity provider you picked, and the machine appears in the admin console. On desktop and mobile the same flow happens inside the app.

Two flags are worth knowing on day one rather than day thirty:

• --hostname sets the name the rest of the tailnet will see. Set it now. Renaming later works but breaks anything that already hardcoded the old name.
• --accept-dns=false is the escape hatch when a machine has a resolver configuration you do not want touched. Leave DNS acceptance on unless something breaks.

Confirm the node is healthy before moving on:

tailscale status
tailscale ip -4

The address will sit inside the 100.64.0.0/10 carrier-grade NAT range. That range is deliberate: it does not collide with the 10.0.0.0/8 and 192.168.0.0/16 blocks your physical networks already use, so an overlay address is never ambiguous with a LAN address.

Add the second device and verify the path

A one-node tailnet proves nothing. Install the client on a second machine, authenticate it with the same identity, and check what kind of connection the two negotiated:

tailscale status
tailscale ping <peer-name>

Tailscale’s documentation on connection types describes the states you will see. A peer marked direct has a peer-to-peer UDP tunnel. A peer marked relay is going through a DERP server. tailscale ping typically shows the first packets travelling via DERP and then switching to a direct route once hole punching completes, so give it a few seconds before concluding anything.

Both states work. Only one of them is fast. If a peer stays relayed, that is a fixable condition and it is covered in detail in why Tailscale throughput is slow and how to fix it. You can also model the latency and throughput gap between the two path types with the mesh latency and throughput estimator on this site.

Turn on names before you memorise addresses

MagicDNS gives every device a name drawn from the admin console and is enabled by default on new tailnets. Once it is on, ssh nas resolves inside the tailnet without any hosts-file maintenance. Use it from the first day, because every address you write down by hand becomes a small piece of technical debt.

The one recurring failure is search-domain conflict. If a machine already has a corporate or ISP-supplied search domain, short names can resolve to the wrong place depending on resolver order. When a name resolves oddly, test the fully qualified tailnet name first to establish whether the problem is the overlay or the local resolver.

Close the policy that is open by default

This is the step most setups skip, and it is the one that matters most.

Tailscale’s tailnet policy file documentation is explicit that a newly created tailnet ships with a default policy that allows communication between all devices. Every node can reach every other node on every port. A mesh in that state is a flat network with better encryption, which is not the security posture people believe they are buying.

The same documentation describes how evaluation changes once you write rules: access becomes deny-by-default, so anything not explicitly granted is refused. Rules are directional, meaning a grant from A to B does not imply B to A. Enforcement happens on the devices themselves rather than at a central chokepoint.

A sane first policy does three things:

1. Replaces the blanket allow with explicit grants for the handful of destinations that actually need to be reachable, scoped to ports rather than whole hosts.
2. Puts servers and appliances behind tags rather than the human account that enrolled them, so access follows the role instead of the person.
3. Leaves personal laptops and phones with only the access they need, which is usually far less than everything.

Write the restrictive version while the tailnet has four devices. Writing it after it has forty means auditing forty devices’ worth of assumptions.

Tags and key expiry for unattended machines

Device keys expire on a schedule. For a laptop that is a mild annoyance because someone is sitting in front of it. For a headless server it is an outage that arrives at an unpredictable time and looks like a network fault.

Handle it deliberately. Tag infrastructure nodes so they are owned by the tag rather than a user, which detaches them from any individual account, and make an explicit decision about disabling key expiry on those specific machines. Disabling expiry is a real tradeoff: it removes an automatic revocation deadline, so it should be paired with actually reviewing the device list rather than letting it accumulate.

For containers, CI runners and anything short-lived, use ephemeral nodes so entries clean themselves up. Otherwise the machine list fills with ghosts and the policy file starts referencing devices that no longer exist.

Reach the things that cannot run a client

Plenty of hardware will never run a Tailscale client: managed switches, IPMI and BMC interfaces, printers, cameras, a 3D printer running Klipper on a small controller board, older NAS units. A subnet router is how those get reached.

Per Tailscale’s subnet router documentation, a Linux node needs IP forwarding enabled at the kernel level first, then advertises the range:

sudo tailscale set --advertise-routes=192.168.1.0/24

Advertised routes are not trusted automatically. An administrator approves them in the admin console, or an autoApprovers rule pre-authorises specific routes from specific owners. The documentation also notes that routing uses longest prefix matching and that Tailscale does not fall back to a less specific route when the router for a more specific one goes offline, so redundancy requires each router to advertise both the broad and the narrow prefix.

The trap that catches multi-site setups is address collision. If two locations both use 192.168.1.0/24, meshing them creates genuine ambiguity. Renumber one side before joining them, not after.

Exit nodes are a targeted tool

An exit node routes all of a device’s internet traffic through another node. It is the right answer for egressing from a specific network, reaching a geo-restricted internal service, or getting a laptop on hostile Wi-Fi onto a trusted path. It is the wrong answer as a default, because every packet then crosses one machine’s uplink and inherits its bandwidth, its latency and its failure modes.

Advertise it on a node with a good uplink, approve it, and turn it on per client only when a client needs it.

The checklist before you call it done

• Identity provider is one you will still control, and the plan tier is the one you expect.
• Every device has a deliberate hostname.
• At least one peer pair verified as direct rather than relay.
• MagicDNS on, and short names resolving to the right place.
• Default allow-all policy replaced with explicit, port-scoped grants.
• Servers and appliances behind tags, with a conscious key-expiry decision recorded somewhere.
• Subnet routes approved, and no overlapping ranges across sites.
• Exit node advertised only where it is wanted, and off by default on clients.

If you are still choosing between overlay networks rather than configuring one, Tailscale compared with ZeroTier and NetBird covers where each one fits and what changes if you want to self-host the control plane.