How to Make Tailscale Start Automatically on Server Startup

Eric DawsonByEric Dawson Computers & Software

To make Tailscale start automatically on a server, enable the tailscaled service so it launches at every startup instead of waiting for a manual command after each reboot. On Linux, running sudo systemctl enable --now tailscaled turns on the systemd service immediately and keeps it enabled through every future restart. Windows installs Tailscale as a service that is already configured to start automatically, and macOS depends on which of the three available variants runs on that machine. A server also needs a way to reconnect once it comes back online, and it uses its stored node key for that: running tailscale up with an auth key handles initial enrollment without an interactive login, rather than authenticating the machine again at every startup.

How to Make Tailscale Start Automatically on Linux Server Startup

Linux servers running systemd start Tailscale automatically once the tailscaled service is enabled, a single command that both turns the service on and starts it for the first time. Every mainstream Linux distribution shipped as a server image today uses systemd, so the same command produces the same result almost everywhere.

Enabling and Verifying the Tailscaled Service

One command enables Tailscale for every future boot, and a second command confirms it worked.

  1. Install Tailscale. Follow the distribution-specific instructions on the official Linux install page if the package is not already present.
  2. Enable and start tailscaled. Run sudo systemctl enable --now tailscaled. This single command enables the service at boot and starts it immediately, so no separate start command is needed right after.
  3. Confirm the service is enabled. Run sudo systemctl is-enabled tailscaled and look for the word enabled in the output.
  4. Check the running status. Run sudo systemctl status tailscaled to see whether the daemon is active right now, not just enabled for later.

Splitting the work into two commands suits an administrator who wants the service enabled for the next boot without starting it in the current session: sudo systemctl enable tailscaled enables it, then sudo systemctl start tailscaled begins running it whenever that is appropriate. Both orders reach the identical configuration once each command has run.

Starting, Stopping, and Restarting Tailscaled

Systemd controls tailscaled the same way it controls any other service on the machine, through a single verb passed to the systemctl command. Running sudo systemctl start tailscaled, sudo systemctl stop tailscaled, or sudo systemctl restart tailscaled applies that action immediately. Enabling the service beforehand is what makes the daemon return on its own the next time the server boots, rather than staying off until someone starts it by hand.

How to Make Tailscale Start Automatically on a Windows Server

Windows servers get Tailscale autostart during installation itself, because the installer registers Tailscale as a Windows service that Windows is already set to launch automatically with the system. Nothing extra needs to run for the service to come back after a reboot, though a server with no one signed in also needs Run Unattended mode turned on to keep the connection itself alive.

Turning on Run Unattended Mode

Run Unattended mode keeps Tailscale connected at the system level on Windows instead of tying the connection to a signed-in user session, and turning it on requires elevated permissions either way it is done.

  1. Open the system tray icon. Right-click the Tailscale icon in the Windows system tray.
  2. Open Preferences. Choose Preferences from the menu that appears.
  3. Turn on Run Unattended. Select the Run Unattended option, then confirm the elevated permissions prompt.

PowerShell reaches the same setting from a script instead of the tray icon, by running tailscale up with the unattended flag: tailscale up –unattended=true. That command line is the faster route for provisioning many servers at once, since it skips the manual click-through entirely.

Managing the Windows Service Manually

Two command-line instructions cover the Tailscale service the same way Services does with a mouse. Running net stop Tailscale stops it, and net start Tailscale brings it back, neither one needing the graphical console open. The Services application itself, reached by typing services.msc, lists Tailscale the same way it lists any other Windows service, with Start, Stop, and Restart available from a right-click menu.

How to Make Tailscale Start Automatically on macOS

macOS autostart depends on which of the three Tailscale variants runs on that machine: Standalone, Mac App Store, or the open-source tailscaled command-line tool. The two GUI variants, Standalone and Mac App Store, launch automatically through the normal macOS mechanism built into every app, while the CLI-only build runs as a launchd service instead.

Both GUI variants need macOS Monterey 12.0 or a newer release, and the open-source tailscaled CLI-only build is recommended only for administrators experienced enough to manage an unattended installation without a graphical interface. As of January 2026, the macOS GUI variants still lack a system-level execution option the way Linux and Windows have it, a limitation tracked in a public GitHub issue rather than something an administrator can configure today.

How to Reconnect a Server to Tailscale Automatically with an Auth Key

An auth key lets a server join Tailscale without an interactive login; after enrollment, its stored node key lets it reconnect after reboot. Running tailscale up with the key passed as an environment variable authenticates the machine the same way a manual login would, minus the manual part.

Generating and Using a Reusable Auth Key

  1. Generate the key. Create a reusable auth key from the Tailscale admin console, choosing pre-approved, tagged, or ephemeral options depending on how the server should be treated on the network.
  2. Store it as an environment variable. Set the key as TS_AUTHKEY in the environment rather than typing it directly into a command.
  3. Bring the connection up. Run sudo tailscale up --auth-key=$TS_AUTHKEY to connect the server using the stored key.
  4. Set a hostname if needed. Add a hostname flag for a server that needs a specific, recognizable name on the network: tailscale up –auth-key=$TS_AUTHKEY –hostname=$TS_HOSTNAME.

Keeping the Auth Key Secure and Knowing When It Expires

Depending on how it was configured, an auth key itself expires after 1 to 90 days, but that expiry only affects whether the key can be used again to authenticate a new connection. A device that has already connected keeps its own node key, which carries a separate default expiry of 180 days and controls how long that specific machine stays authorized on the network.

Passing the key through an environment variable rather than typing it directly on the command line keeps it out of shell history, where anyone with access to that history could read it later. That one habit is the security difference between a key that stays private and one that sits in a plain text log.

Comparing Autostart Methods Across Operating Systems

The autostart method, the command that triggers it, and the service name all differ by operating system, which is why a checklist built for Linux does not transfer directly to Windows or macOS. A table lining up all three follows below.

Operating System Autostart Method Configuration Command Service Name
Linux (systemd) Systemd service sudo systemctl enable --now tailscaled tailscaled
Windows System service, automatic by default tailscale up –unattended=true Tailscale
macOS (Standalone or Mac App Store) Built-in launch, GUI variant None needed, automatic tailscale
macOS (CLI-only) Launchd service Manual launchd plist configuration tailscaled

Linux is the only platform where the daemon runs at the system level by default, regardless of whether anyone is signed in. Windows reaches the same result when Run Unattended is turned on. The macOS GUI variants cannot yet run Tailscale outside a user login session.

I trust the Linux approach most for an unattended server because it makes the two separate needs visible. Managing tailscaled through the distribution’s service manager handles daemon operation, while an auth key supports non-interactive server enrollment. Windows uses a service named Tailscale, but Run Unattended still needs deliberate setup. macOS is the least suitable choice for this role because its behavior depends on the variant and it lacks the same system-level execution option.

Why a Running Tailscaled Service Is Not the Same as Network Readiness

A tailscaled process can be active on a server while that server is still logged out, disconnected, or blocked by a DNS or firewall rule, so an enabled autostart service is not proof the server is actually reachable over Tailscale. Anything that depends on Tailscale connectivity needs to check for that connectivity directly, because the daemon running and the network being ready are not the same signal.

Systemd handles this gap through a dedicated target file rather than the general-purpose one most services use. A unit that depends on Tailscale should list tailscale-online.target in its own After= line, alongside the standard network.target, so systemd waits for Tailscale to actually be online before starting the dependent service, not just for the network stack in general to be up.

network.target alone tells systemd that basic networking is available, nothing about Tailscale specifically. tailscale-online.target closes that gap, and a service configuration file for anything that only works once Tailscale is connected should list it alongside, not instead of, the standard target.

How to Configure Startup Options for Tailscaled

Startup options for tailscaled live in a different place on each operating system: a flags file on Linux, an environment file on Windows, and registry-backed installer properties for a scripted Windows deployment.

Setting Daemon Flags on Linux

Editing /etc/default/tailscaled changes the FLAGS variable that the systemd unit reads when the daemon starts, without touching the unit file itself. Common flags include –port=N for the UDP port used for peer-to-peer connections, –verbose=N for how much detail the daemon logs, and –statedir= for where its configuration is stored. A static binary install keeps its own systemd service files in the systemd/ subdirectory of the unpacked archive, useful for a server set up outside a distribution’s package manager.

Setting Environment Variables on Windows

Windows reads its own equivalent from a text file rather than a flags variable. Creating tailscaled-env.txt inside C:\ProgramData\Tailscale and adding a line such as PORT=N sets the same kind of option Linux controls through its flags file. A scripted Windows install can also set MSI properties through msiexec during setup, stored afterward in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Tailscale for later reference.

How to Verify Tailscale Started Correctly, and What to Do if It Did Not

Confirm Tailscale is running with sudo systemctl status tailscaled on Linux, or with the equivalent Services entry on Windows, before assuming the autostart configuration worked. A status that reads active, together with an is-enabled check that reads enabled, confirms both halves of the setup: that the service turns on by itself and that it is actually running right now.

Reading the Logs When the Service Will Not Start

journalctl is the first place to look on Linux, since tailscaled logs through the standard systemd journal like most other services on the machine. tailscale debug daemon-logs works the same way across every platform Tailscale supports, streaming the daemon’s own log output directly rather than going through whatever logging system that operating system normally uses, useful when the same troubleshooting steps need to work on both a Linux box and a Windows server.

What to Check if Tailscale Still Will Not Reconnect

Work through a short list before assuming the installation itself is broken. Confirm the service is both enabled and active with the two systemctl commands. Check whether the device’s node key has expired, since an expired node key requires re-authentication even though the daemon still starts normally.

Look for a DNS or firewall rule blocking the connection, since the daemon can report itself as running while the server stays unreachable over the network for an unrelated reason. Check any dependent service’s own configuration for tailscale-online.target as well, since a unit that only waits on network.target can start before Tailscale itself is actually online.

Frequently Asked Questions

Does Tailscale Start Automatically Right After Installation?

Windows and the systemd package on Linux both configure autostart during installation itself, so a fresh install starts automatically on the next boot without an extra command. A static binary install on Linux is the exception, since it needs the systemd unit file from its own systemd/ subdirectory set up manually first.

How Long Does a Tailscale Auth Key Stay Valid?

A reusable auth key stays valid for 1 to 90 days depending on how it was configured when generated. Once a device uses that key to connect, its own node key takes over with a separate 180-day default expiry, so the two timers cover different things.

Can a Server Stay Connected to Tailscale Without Anyone Logged In?

Yes, on Linux by default, since the daemon runs at the system level regardless of login state. Windows needs Run Unattended mode turned on first, and macOS can only reach the same result through the CLI-only tailscaled variant’s launchd service.

What Is the Difference Between Enabling and Starting the Tailscaled Service?

Enabling the service sets it to launch automatically on future boots, while starting it begins running the daemon immediately in the current session. sudo systemctl enable --now tailscaled does both at once, which is why that single command covers most setups.

Does macOS Support System-Level Tailscale Autostart Like Linux Does?

Yes, with CLI-only tailscaled. The macOS GUI variants lack the system-level execution option that Linux has by default, and Tailscale is tracking the request in a public GitHub issue rather than shipping it. For experienced administrators, the CLI-only launchd variant provides this, though Tailscale recommends it only for experienced administrators.

Getting a server to reconnect on its own after every reboot comes down to two separate pieces: enabling the daemon itself through systemd, a Windows service, or launchd, and authenticating it once, either interactively or with an auth key, so the stored node key can reconnect it after every reboot. Without the daemon running and a valid stored node key, the server cannot reconnect automatically.

References

Sources read in September 2026.

Eric Dawson

I'm Eric Dawson, and I write The Money Watch from north Columbus, Ohio. Most of what I cover comes from my own life: renting, a 2014 Honda Fit, parking, computers, food and the bills behind all of it. I spent four years in an apartment-property office and eleven on a distributor's operations desk, reading leases and invoices. Where you need real information, I research the maker's or agency's own page and independent sources and report what they publish. I don't give tax, investment, legal or medical advice.