glinet-tailscale-updater keeps Tailscale current on a GL.iNet router

A community script for a specific router family

glinet-tailscale-updater is an automated Tailscale updater for GL.iNet routers. It periodically checks for new releases, downloads the correct build, and installs or updates Tailscale reliably by script, for OpenWrt and GL.iNet firmware.

The script was created by Admon for the GL.iNet community, and the README says it is tested on nearly all GL.iNet routers with firmware 4.x. Two badges in the README set the terms of use plainly. It is community maintained and part of the GL.iNet Toolbox project, and it is an independent project, not officially affiliated with GL.iNet or Tailscale.

That second badge matters for anyone considering it for a device that routes their traffic. The project is written by a member of the community for that community, it is not vendor supported, and it modifies the binaries on a device that other people depend on for connectivity.

The problem it solves is a real one. A GL.iNet router ships with its own Tailscale build, which ages as Tailscale moves on, and the usual answers are to rebuild firmware or to accept an old client. The script takes the third route: it fetches the current Tailscale release, chooses the build that matches the device, and installs it over the firmware's copy, with a path back to the original if it goes wrong.

The repository is small, with the script itself as update-tailscale.sh at the root, plus scripts, patches, images and a readme.md, and the licence is MIT.

Requirements: firmware 4.x, 15 MB free and one of five architectures

The requirements table is short and the constraints are the sort that decide whether the script will work on your device before you run it.

The router must be a GL.iNet router with firmware 4.x, and the table names the GL-BE9300 Flint 3 as an example. There is a separate row for the GL.iNet KVM devices, Comet and Comet Pro, which the README says were reported working by the community on firmware V1.9.1 and 1.10, and the feature list adds that KVM support updates Tailscale on Comet and Comet Pro following the device's own init script.

The architecture must be one of arm64, armv7, mips, mipsle or x86_64. That list is the interesting part, because it is the union of what GL.iNet's hardware uses over the years, and the script has to pick the right build for whichever one it finds.

Free space must be at least 15 MB, and the table notes that this can be bypassed with --ignore-free-space, with a warning to use it with caution on low storage devices.

There is also a precondition in a callout that is easy to miss: please make sure that you enabled Tailscale in the GL.iNet router settings before running this script. The updater assumes the router is already set up to run Tailscale, and it is not an installer for the client in the sense of setting up the device's Tailscale configuration.

One command, and a warning against running it unattended

The quick start avoids cloning the repository entirely. The script is fetched and run in a single line:

wget -q https://get.admon.me/tailscale -O update-tailscale.sh ; sh update-tailscale.sh

The repository description says the same thing: keep your Tailscale installation current with just one command.

The callout immediately after is the most important line in the quick start section: do not run this script as a cron job, and manual execution is recommended.

That is worth respecting. A cron job would apply a new Tailscale release to a device that routes your traffic without anyone watching, at a moment when the device may be carrying a session. The script has prompts and a restore path, and both of those depend on a human being present. There is a --force flag for unattended installations, and it exists for the cases where you have already decided the answer, not as a replacement for the advice.

The script is served from a third-party domain rather than from the repository, so the wget line is fetching and then executing a remote shell script. The repository itself is the place to read what that script does, and the scripts and patches directories in the listing are where the implementation lives.

Thirteen flags, and the ones that change what gets installed

The argument table is the real documentation, and a few entries matter more than the rest.

The space check has --ignore-free-space, which bypasses the free space check and is marked for use with caution on low-storage devices. --force skips all confirmation prompts and makes the installation permanent, which the README calls ideal for unattended installations. --force-upgrade forces the upgrade even when the current version is already up to date, which is useful for reinstalling the same version.

Two flags change the binary rather than the process. --no-tiny uses the full Tailscale binaries instead of the tiny version, and the README says plainly that this is not recommended for GL.iNet routers. --no-upx skips UPX compression, so the binaries are larger but the installation is faster. The tiny binaries and the compression are the reason the script fits on a device with 15 MB free, and giving them up is how you trade space for time.

Then there are the escape hatches. --no-download skips downloading binaries and uses a pre-downloaded archive at /tmp/tailscale.tar.gz, which is what you want on a metered or slow link. --select-release displays the available releases and lets you choose a specific version, with a warning that downgrading Tailscale is not officially supported and may cause unexpected behavior. --testing uses prerelease versions from the testing branch, with a warning that they may contain bugs or unstable features.

Two flags change the router's configuration rather than the client. --skip-config skips the adjustment of the gl_tailscale script, and --ssh enables the Tailscale SSH feature after installation. The remaining entries are --restore for putting the firmware binaries back, --log for timestamps in log messages, and --help.

The restore flag deserves a close read. It restores the original firmware binaries, /usr/sbin/tailscaled and /usr/sbin/tailscale, and it does not restore config files, and it is not available on GL.iNet KVM devices.

Release names track the Tailscale version

The release history explains how the project is versioned, and it is worth a minute because the numbers do not match the project's own version scheme.

The recent releases are v1.104.1 titled Small Tailscale v1.104.1 on 2026-10-08, v1.102.5 titled Small Tailscale v1.102.5 on 2026-09-30, and v1.102.4 titled Small Tailscale v1.102.4 on 2026-09-11. In other words, the releases are named after the Tailscale version they carry, and the Small prefix refers to the tiny binary builds.

That is a sensible scheme for a project whose whole job is to ship a third-party client's binaries. There is no independent version of the updater to track, because the meaningful number is the client version, and the script's own behaviour changes only when the Tailscale release format does.

The alternative to this scheme, tracking an updater version separately, would let you pin the updater while the client moved on. Here, a new release is a new client, and the two move together.

The repository is not archived and the last push was on 2026-10-08, the same day as the newest release, so the project is being worked on at the pace of the Tailscale release cycle rather than on its own schedule.

Where the updater is the wrong tool

The limits are narrow but they are real.

First, the hardware. This is for GL.iNet routers on firmware 4.x, plus the Comet and Comet Pro KVM devices on the firmware versions the community has reported. It is not a general script for OpenWrt, and it does not support the wider Tailscale install matrix.

Second, it replaces binaries on a device that routes your traffic. The install is reversible in the sense that --restore puts the firmware's own /usr/sbin/tailscaled and /usr/sbin/tailscale back, but the restore does not put your configuration back, and it is not available on the KVM devices. On a router at a remote site, that asymmetry between installing and un-installing is the part to think about.

Third, the script fetches and executes code from a remote domain, over a connection you are relying on. The MIT licence covers the code in this repository, but the one-line install path pulls whatever is being served at that moment. If your policy requires reviewing a script before it runs, download it from the repository and read it.

Fourth, the design assumes a human is watching. The README's advice not to use cron is not a limitation of the implementation so much as a statement about what the author considers safe, and the --force flag exists for people who have made that decision themselves.

Fifth, the flags that matter most are the ones that change what ends up on the device: --testing for prerelease clients, --select-release for a downgrade that Tailscale does not officially support, and --no-tiny for full binaries that the README says are not recommended on these routers. For a router that other people depend on, the default flags are the conservative choice.

Editorial conclusion

Owners of a GL.iNet router who want a current Tailscale without rebuilding an image should use this updater, because it handles the architecture-specific build choice, the space constraints of small devices and the router's own init script, and it can put the firmware's binaries back. It is the wrong tool if your router does not run GL.iNet firmware 4.x, and the wrong tool if you want an unattended pipeline, since the README explicitly advises against running it as a cron job. Before running it, read the warning about Tailscale SSH and about downgrades, and check the free space on the device, because the script refuses to proceed without at least 15 MB unless you override the check.

Frequently asked questions

Official sources

1. admonstrator/glinet-tailscale-updater on GitHub
2. License: MIT
3. Project website
4. README
5. Releases