Two ways in, and only one of them is private

Home Assistant is already reachable from your sofa. The problem is only ever the journey from somewhere else — a train, an office, a hotel. There are two shapes of answer to that.

Tailscale groups the devices that join the same tailnet into one private network. Your phone joins it, your Home Assistant machine joins it, and from then on they reach each other as if they were both on your home wiring — whatever network the phone is actually sitting on. It does not require you to open a router port for Home Assistant to the internet.

flowchart LR
  A["Your phone, away from home"] --> B{"How does it get in?"}
  B -->|"port forwarding"| C["A port opened on your router"]
  C --> D["Reachable from the whole
public internet"]
  D --> F["The Home Assistant login
is the only thing left"]
  B -->|"tailnet"| G["Phone signed in to the same tailnet"]
  G --> H["Private path to the
Home Assistant machine"]
  H --> F

Notice that your Home Assistant login sits on both paths. Tailscale manages the network path; it does not replace accounts, passwords, MFA or admin rights inside Home Assistant. Treating it as though it does is how people end up less safe than they started.

Three things called “Tailscale,” and why it matters

Almost every confusing hour in this subject comes from clicking in the wrong place. Three separate things share the name, and each one fails differently.

Two more words, because the rest of the series leans on them. A tailnet is your private Tailscale network. A machine is one device that has joined it — your phone is a machine, your laptop is a machine, and after Part 2 your Home Assistant will be one too.

The payoff is that troubleshooting stops being guesswork. Two questions narrow a failure to a single layer:

flowchart TD
  A["You cannot reach Home Assistant"] --> B{"Is Home Assistant listed
in the Machines page?"}
  B -->|"no"| C["Layer 2: the HA Tailscale app.
Finish the Web UI login,
then read the app log"]
  B -->|"yes"| D{"Is the phone or laptop signed in
to that same tailnet?"}
  D -->|"no"| E["Sign that device in to the
same tailnet first"]
  D -->|"yes"| F["Layer 3: Home Assistant itself.
Check the HA login account
and the URL you are using"]

Take inventory before you install anything

Four items, written somewhere you will find them again.

Those last two are least privilege in practice: only the people who need to reach Home Assistant get a path to it, and only the people who need to manage the tailnet get admin console access. It is easier to grant a right later than to work out who quietly has one already.

While you are looking, decide how far you actually want to go. Start with the smallest workable setup, then expand step by step. If all you want is to see your dashboard while away from home, private access over the tailnet is usually easier to control than a public entry point — usually, not always, and it is still your own network and security policy that decides. If you need to reach a LAN subnet, list one subnet with a clear purpose first, and do not advertise every network at once. Starting small is what keeps each step testable.

Install, start, and then deliberately stop

Four short steps. The discipline is in the fourth: stop before logging in. That belongs to Part 2, on a device you have thought about.

1. Step 1

   Confirm you have Apps, then search

   Go to Settings → Apps, open the store and search for Tailscale. If there is no Apps entry in Settings, stop here: this is not a Supervisor-managed environment, and the app cannot be installed the way this chapter describes.

2. Step 2

   Open the official app and read before installing

   Open the Tailscale entry and read two things on that page before you click anything: the current version, and the permissions it asks for. Then choose Install.

3. Step 3

   Press Start, and change nothing else

   When the install finishes, press Start. Do not enable options you are not using yet. You will meet settings like share_homeassistant, advertise_routes and userspace networking later in this series, and each one gets its own chapter for a reason.

4. Step 4

   Check the three tabs, then stop

   Go back to the app and look at Info, Configuration and Log. All you are confirming is that it starts and does not fail right away. Logging in and verifying the machine are Part 2's job.

flowchart TD
  A["Settings, then Apps"] --> B{"Is there an Apps page?"}
  B -->|"no"| C["Container or Core install.
This click path does not apply"]
  B -->|"yes"| D["Search the store for Tailscale"]
  D --> E["Read the current version
and the permissions"]
  E --> F["Install"]
  F --> G["Start"]
  G --> H["Check Info, Configuration and Log"]
  H --> I["Stop. Login and machine
verification are Part 2"]

It is worth reading now what Part 2 will ask you to confirm, because it tells you what “installed correctly” is going to look like. Open the Machines page in the Tailscale admin console and confirm the machine that corresponds to Home Assistant, its last-seen status and its feature badges. Three things, not one.

The things left out on purpose

Tailscale can do more than this series asks of it. Three features are left switched off on purpose, and it is worth knowing their names so you recognize them when a forum post suggests one.

• Exit nodes — routing all of a device's internet traffic through another machine. Useful, and a much bigger change than it sounds.
• DNS override — letting the tailnet decide how names resolve on your devices. When it goes wrong it goes wrong everywhere at once.
• Funnel — publishing a service to the public internet. That is the opposite of what this guide is for.

Leave all three disabled unless you have a specific need, and plan them separately from the Tailscale Docs, which are named with their address at the end of this article. Later in this series you will meet Serve, which sounds like Funnel and is not: Serve stays inside your tailnet, Funnel faces the open internet.

The same caution applies in reverse, and it is a different mistake from the one above. That one was about publishing your values. This one is about borrowing someone else’s: do not copy the names or IPs in the screenshots as your own values. A device name or an address in a screenshot — in this series or any other guide — is the author’s network being illustrated, not a setting for you to type in.

Three things to check before you call a chapter done

This check belongs at the end of this chapter and at the end of every chapter after it. It is three questions, it takes a minute, and it catches the mistakes that are cheap now and expensive in a year.

• The account signed in to Tailscale is the right one. Not a colleague’s, not an old personal account you were logged into in the browser already, not a shared one. Whoever that account belongs to now owns this tailnet.
• Home Assistant is still managed with separate personal accounts. One account per person, with their own password and their own MFA, and admin rights only for the people who need them. Joining a tailnet changes nothing about this and is not a reason to relax it.
• The Machines list has no unknown or retired devices. This is the one people skip, and it is the one that quietly accumulates.

Least privilege is what makes that list short enough to read. Only the people who need to reach Home Assistant get a path to it, and only the people who need to manage the tailnet get admin console access. A list of four machines you can account for is a security control. A list of nineteen you cannot is a to-do you will keep postponing.

Test on two networks, then write it down

A change to network settings is only finished when you have proved it from somewhere other than your sofa. Two tests, in this order.

First on your home network: open Home Assistant on the local LAN and confirm the accounts and dashboard you already had were not affected by anything you just did. Then from a different network: switch a test phone to mobile data or another secure network, confirm Tailscale is connected, and open Home Assistant once. Test only targets you are authorized to reach.

flowchart LR
  A["Change one thing"] --> B["Test on the home LAN:
nothing else broke"]
  B --> C["Test from mobile data or
another secure network"]
  C --> D["Write down the date, the purpose,
the result and the device used"]
  D --> A

The biggest risk with network settings is not that they are wrong. It is that they were right at the time and nobody remembers why. So when you finish a chapter, note the date, who did it, the purpose, the state before and after, and the device you verified with, in your password manager or your maintenance notes. Something this ordinary is enough:

That note holds no secret and still tells the next person what they need. Secrets belong in a controlled secrets manager, never in the notes.

If the change involved a subnet router, add one clause to that sentence: only a single approved LAN CIDR is advertised, approved in the admin console. It is short, and it records the two things nobody can reconstruct later by looking at the router — that you deliberately advertised one range rather than several, and where the approval that made it live actually lives. Write the clause, not the CIDR itself, and never write street addresses, customer names, the full Tailscale domain or device identifiers into a public repo.

That is what lets you judge which layer to roll back when a phone is lost, a router is replaced, the app is updated, or admin rights change hands.

The questions people actually ask first

Two documents settle arguments in this series, and it is worth having both bookmarked before you need them. This guide treats them as authoritative:

The first covers the app itself — its options, its Web UI, and settings such as share_homeassistant and advertise_routes. The second covers Tailscale as a service: subnet routers and route approval, access controls, and Serve. Interface text changes with the app and the admin console version, so when a name on your screen differs from a name here, go by your screen and those two documents, in that order.

Where to go from here