How to Set Up Tailscale: Sign Up, Install, First Tailnet

To set up Tailscale, install the client (on Linux, curl -fsSL https://tailscale.com/install.sh | sh and then sudo tailscale up), sign in with Google, Microsoft, GitHub, Apple or another supported identity provider, and repeat on a second device. That first sign-in creates your account and your tailnet; there is no separate registration form.

Getting two devices talking that way takes 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.

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.

What is a tailnet?

A tailnet is your private Tailscale network, which Tailscale defines as “a secure, interconnected collection of users, devices, and resources” that the public internet cannot reach. You do not install a tailnet. It is created the first time you log in to Tailscale on any device, and every device you authenticate afterwards joins it.

Each tailnet has a DNS name ending in .ts.net, either a random default like tailfe8c.ts.net or a personalised one like yak-bebop.ts.net, shown on the DNS page of the admin console. “Install tailnet” therefore means installing the Tailscale client.

Create your Tailscale account: which identity provider to sign up with

To sign up:

1. Go to tailscale.com and select Get Started, or install the client first and sign up from inside it, as the quickstart allows.
2. Pick an identity provider. The native options are Apple, Google, GitHub, Microsoft, Okta and OneLogin, plus any custom OpenID Connect provider. There is no username-and-password option, so this choice creates the account.
3. Authorise Tailscale with that provider and complete its sign-in prompt. That is the whole registration step; there is no separate form to fill in.
4. On the Welcome page, choose Business use or Personal use, then install the client on your first device and sign in with the same identity.
5. On each further device, install the client and sign in with the same provider (on Linux, sudo tailscale up); that adds the machine to the tailnet you just created.

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. If the hosted account itself is the objection, Headscale vs Tailscale covers self-hosting the control server.

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 (checked October 2026), 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

Every client is linked from the download page. At the time of writing the stable release is 1.104.1, dated October 7, 2026 in the changelog and on the stable package server.

Install Tailscale on Linux

The Linux install script covers Debian and Ubuntu derivatives, RHEL, CentOS, Fedora, Raspberry Pi OS, Amazon Linux, openSUSE and SUSE Linux Enterprise, Oracle Linux and VMware Photon OS:

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

If you would rather not pipe a script into a shell, the package server lists repository commands per distribution and release; on Fedora that route adds sudo systemctl enable --now tailscaled before tailscale up. Arch, NixOS and static-binary installs are documented separately. The one kernel requirement is the tun module; run sudo modprobe tun if it is missing.

Sign the node in

sudo tailscale up 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.

For a headless server, generate an auth key on the Keys page of the admin console and pass it instead:

sudo tailscale up --auth-key=tskey-xxxxxxxxxxxx

Keys can be one-off or reusable, ephemeral, pre-approved and pre-tagged, and expire after 1 to 90 days (90 if unset).

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 with tailscale set --hostname works, but per the CLI reference it changes the MagicDNS name and breaks anything that already hardcoded the old one.
• --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 and authenticate it with the same identity. The quickstart offers to send that device a link, or Add device on the admin console’s Machines page does it per OS; with device approval enabled, the newcomer waits as “Needs approval” until an admin approves it. Then 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.

Connect to another device on your tailnet

Once two devices share a tailnet, connect by MagicDNS name or Tailscale IP with the client the service already speaks: ssh nas, an RDP client pointed at desktop, a browser at the 100.x.y.z address and port. Tailscale’s connection guide lists three conditions: Tailscale runs on both ends, the policy allows it, and the target is listening.

The default policy allows everything, so a first connection rarely fails on policy; after you tighten it (below), it can. For SSH, sudo tailscale set --ssh on a Linux target enables Tailscale SSH, which hands SSH authentication and authorisation to the tailnet.

Logging in is two separate things. The admin console, whose Machines page sits at console.tailscale.com/admin/machines (filter-devices docs), manages devices, DNS, keys and policy; users with the Member role cannot open it. The client login is per device: tailscale login signs a device in, tailscale logout expires that login, and sudo tailscale up --force-reauth forces a fresh one (not over an SSH session you depend on, since it can drop).

Turn on names before you memorise addresses

MagicDNS gives every device a name drawn from the admin console and, per the MagicDNS docs, is on by default for tailnets created on or after October 20, 2022. A device’s full name is its machine name plus the tailnet name, such as monitoring.yak-bebop.ts.net. 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. Tailscale ACL examples explained writes those policies out with tests.

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.

New tailnets default to a 180-day node key expiry, adjustable from 1 to 180 days on the Device management page, according to the key expiry docs. If a server you cannot reach has already expired, an admin can select Temporarily extend key on the Machines page, which buys 30 minutes to re-authenticate it.

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 Tailscale subnet router configuration guide covers autoApprovers, SNAT and MTU.

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 full Tailscale exit node setup, including scoping who may use it and isolating it on its own VLAN, is a separate walkthrough.

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.

FAQ

can i sign up for tailscale without a google account

Yes. Tailscale also accepts Microsoft, GitHub, Apple, Okta and OneLogin accounts, plus any custom OpenID Connect provider. What it does not offer is an email-and-password account, because it is not an identity provider itself. Passkeys only let an invited user join an existing tailnet, so a new tailnet always starts from one of those providers.

can i change my tailscale login provider later

Sometimes, but treat it as a migration rather than a setting. Tailscale documents a separate switch-identity-provider procedure, and it cannot move a tailnet to or from GitHub or Apple at all. If you signed up with either and later want Google Workspace or Okta, expect to rebuild rather than switch, so choose carefully at first login.

does every device need tailscale installed

No. Anything that can run the client should, because that gives it its own identity and a direct encrypted path. Hardware that cannot, such as printers, cameras, managed switches and BMC interfaces, is reached through a subnet router: one node that advertises the LAN range, with that route approved in the admin console.

can one device be on two tailnets at once

It can be logged in to several, but only one is active at a time. Run tailscale login to add another account, then tailscale switch to move between them; switching skips re-authentication unless the account is new to that device or its key has expired. Each tailnet is unaware of the other.