Three layers, and none of them replaces the others

Installing Tailscale is not a reason to assume that everything can now reach everything. When something is blocked — or, more importantly, when something is not blocked and you think it should be — the first useful question is which layer made that decision. There are three, and they are managed in three different places.

That last part is the one people skip. Tailscale manages the network path. Home Assistant should still use personal accounts, strong passwords and appropriate admin rights — Tailscale does not replace the Home Assistant login and was never meant to.

Tell those three apart before you change anything, so that later you do not spend an evening clicking in the wrong place. The app itself lives at Settings → Apps in the Home Assistant menu; if your screen still uses the older name, it will say Add-ons. The interface text and its translations vary by version, so recognize the Tailscale app and its Info, Configuration, Log and Web UI tabs rather than memorizing a menu label.

flowchart TD
  A["A phone on some other network"] --> B{"Is this device signed in
to your tailnet?"}
  B -->|"no"| X["There is no path at all"]
  B -->|"yes"| C{"Does the tailnet policy let
this source reach the Home
Assistant machine?"}
  C -->|"no"| Y["The network path stops here"]
  C -->|"yes"| D{"Does this person have a
Home Assistant account?"}
  D -->|"no"| Z["The login page, and it stays there"]
  D -->|"yes"| E["The dashboard, with whatever rights
that Home Assistant account has"]

Least privilege is a list you write before you edit anything

Least privilege means one thing here: give network access to the people and devices that need to use Home Assistant, and to nobody else. Admin rights inside Home Assistant stay where they are, controlled by Home Assistant user accounts.

Two syntaxes exist for writing those rules. The Tailscale docs recommend grants as the modern access-control syntax, and ACL is still supported. If you already have working ACL rules, they have not stopped working; if you are writing something new, grants are what the documentation points you at.

The four steps, in order

1. Step 1

   Take inventory of sources and targets

   On paper, or in a note. Write down who needs to reach Home Assistant, from which device, and which ports or services they actually need. Family members who use the dashboard day to day and the person who administers the tailnet are different roles, even when they are the same person on two different devices.

2. Step 2

   Read the current rules in Access controls

   Open Access controls in the Tailscale admin console and understand the grants or ACL that are already there. Do not paste in a whole policy you found online. A policy from someone else's network describes someone else's devices.

3. Step 3

   Grant the minimum that works

   Grant only the necessary sources access to the necessary machines and services, and preserve the meaning of the rules that were already there. The list from step 1 is what tells you where the edges are.

4. Step 4

   Test with a non-admin account

   Verify Home Assistant from a test device that should have access, and confirm that no account which should not have access quietly picked up a wider scope. An admin account passing the test proves less than you think.

Step 1 sounds like homework you can skip. It is the step that makes the other three short. Written out, an inventory tends to look like this:

flowchart TD
  A["Someone cannot reach
Home Assistant"] --> B{"Should they be
able to?"}
  B -->|"no"| C["Leave the policy alone.
It is working"]
  B -->|"yes"| D{"Is their device signed in
to the same tailnet?"}
  D -->|"no"| E["Fix the device,
not the policy"]
  D -->|"yes"| F{"Is it the network path or the
Home Assistant login failing?"}
  F -->|"the HA login"| G["Sort out their Home
Assistant account"]
  F -->|"the network path"| H["Widen the grant for that one
source and that one target"]

Start small, then expand

Start with the smallest setup that works and grow it deliberately. If all you want is to see your dashboard while you are away, private access over the tailnet is usually easier to control than a public entry point. If you need to reach a LAN subnet, list one subnet with a clear purpose first rather than advertising every network at once.

Serve keeps it inside. Funnel does not.

Serve and Funnel look like two settings on the same switch. They are not the same risk. Tailscale Serve makes a local service available to the devices inside your tailnet. Funnel makes it available to the wider internet. The official docs draw a clear line between them, and this guide deals only with Serve.

flowchart LR
  subgraph F["Funnel, which is out of scope here"]
    direction LR
    F1["Any device on the public
internet, with no Tailscale
installed on it"] --> F2["Tailscale relays
it inward"] --> F3["Home Assistant"]
  end
  subgraph S["Serve, which is what this article sets up"]
    direction LR
    S1["A device signed in
to your tailnet"] --> S2["An HTTPS name that only
exists on the tailnet"] --> S3["Home Assistant"]
  end

Both behaviors are reached through one option in the Home Assistant app, share_homeassistant, which is disabled by default. That default is a good one. Leaving it alone is a valid choice, and if the address-and-port you already use is working for you, you can stop reading here and skip to Part 5.

Five steps to an HTTPS address that stays private

What you get at the end is a URL you can type on any device in your tailnet, with no port number on the end and no certificate warning. What you change to get there touches three different places: a Home Assistant configuration file, the Tailscale admin console, and the app's own options. Do them in this order.

1. Step 1

   Leave Home Assistant on local HTTP

   The official app docs assume Home Assistant is reachable over HTTP. If you already run another HTTPS reverse proxy in front of it, do not stack the two setups on top of each other — assess your situation against the docs before going further. This step is often nothing at all: a default installation is already where it needs to be.

2. Step 2

   Set up trusted proxies, then restart Home Assistant

   In configuration.yaml, inside the existing http: section or a new one, set both of the values below. Save the file, then restart Home Assistant.

   use_x_forwarded_for: true

   trusted_proxies: - 127.0.0.1

   The address 127.0.0.1 is the machine talking to itself — it is the same on every computer, so this is not a value you need to look up or change.

3. Step 3

   Enable HTTPS in the Tailscale admin console

   Go to the DNS settings in the admin console, choose a tailnet name, enable MagicDNS, and then choose Enable HTTPS under HTTPS Certificates. This is the prerequisite for Serve to obtain a certificate — skip it and step 4 has nothing to present to your browser.

4. Step 4

   Set share_homeassistant to serve, then restart the app

   In the Tailscale app's Configuration tab, set share_homeassistant to serve. Leave share_on_port at its default of 443. Restart the app.

   Do not choose funnel. It is the neighboring value in the same field, which is exactly why it is worth pausing on this step rather than clicking through it.

5. Step 5

   Open the new URL from another tailnet device

   From a phone or laptop signed in to the same tailnet, open https://<machine>.<tailnet>.ts.net — with no port number on the end, unlike the address you have been using so far. Then log in with your personal Home Assistant account, as usual.

   The two bracketed parts are placeholders. Your own machine name and tailnet name go there; this guide does not print real ones, and neither should you when you ask for help.

flowchart LR
  A["A device signed in
to the tailnet"] -->|"HTTPS on port 443"| B["Serve, running on the
Home Assistant machine"]
  B -->|"local HTTP,
arriving from 127.0.0.1"| C["Home Assistant, still
on plain HTTP"]
  C --> D["Your normal Home
Assistant login"]

The check, the test, and the note you leave behind

Three quick confirmations before you consider this finished. None of them takes more than a minute, and all three are the sort of thing that is obvious now and impossible to reconstruct in six months.

Cross-check the Home Assistant machine in the admin console

Open the Machines page in the Tailscale admin console and confirm the machine that corresponds to Home Assistant. Finding its name in the list is the easy half. Two other things on that row tell you more:

Test it on two networks

One test proves less than two, because a device at home may be reaching Home Assistant over your LAN without Tailscale being involved at all.

• On your home network: open Home Assistant on the local LAN and confirm that your existing accounts and dashboard were not affected by the changes in this article.
• On a different network: switch a test phone to mobile data or another secure network, confirm Tailscale is connected, then open Home Assistant once. If you are testing routes, test only targets you are authorized to manage.
• Record the result: success or failure, the device you used, and the time. That is far easier to work from later than remembering that “it used to work”.
• Stop at the security boundary: this guide does not cover exit nodes, DNS override or public Funnel setup. Leave them disabled unless you have a specific need for them.

Leave a handover-ready record

The biggest risk with network settings is not that they break. It is that they worked at the time and nobody remembers why. When you finish, write down the date, who did it, the purpose, the state before and after, and the device you verified with — in your password manager or your site maintenance notes.

That record is not a place to store passwords, auth keys or full private subnets. Those belong in a controlled secrets manager. The note holds only the description the next maintainer needs in order to understand the decision. A real one reads like this: “2026-08-19, the administrator confirmed the Home Assistant machine is still in the designated tailnet; private access tested successfully from a managed laptop on a non-home network.” For a subnet router, add that only a single approved LAN CIDR is advertised and approved in the admin console.

Never write street addresses, customer names, the full Tailscale domain or device identifiers into a public repository. The record 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 are handed to someone else.

Check these first, then the questions people ask

Questions that come up every time

Where to go from here