openwrt-tailscale-enabler: a tarball that boots Tailscale on a small router

The deliverable is a tarball extracted onto the root filesystem

There is no package here to install through the OpenWRT package manager, and no menu entry to add. The project produces an archive laid out as absolute paths, and you unpack it into the root of the device filesystem. Pick the build matching your target, then extract it:

tar x -zvC / -f openwrt-tailscale-enabler-<tag>.tgz

The -C / argument is what makes this work: the archive contains etc/ and usr/ directories intended to merge into the live filesystem rather than a subdirectory. That structure is visible in the repository too, where etc/ and usr/ are top level directories and generate-tar.sh sits beside them. Once extracted you have an init script at /etc/init.d/tailscale, which is the piece that later survives reboots.

Three opkg packages and kmod-tun are the prerequisites

The README asks for the prerequisites of wget and Tailscale before anything runs, and names them exactly:

opkg update
opkg install libustream-openssl ca-bundle kmod-tun

kmod-tun is the loadable module the userspace tunnel needs, and libustream-openssl and ca-bundle are what let the download and the TLS handshake work on a device whose base image may carry neither. If this package list is wrong for your build, the failure surfaces later as a download that never completes, not as an error here.

The stubs download the real binaries the first time they run

This is the mechanism that makes the project small to install and large to run. /usr/bin/tailscale and /usr/bin/tailscaled are stubs, and both download the actual tailscale package to get the binaries into /tmp. The README says the init script start causes tailscaled to be fetched, and that the first time you run a CLI command such as tailscale status, the stub fetches the tailscale client. So on a router with a slow uplink or a tight RAM budget, the first command after boot is the slow one, and it is the interactive command you are most likely to notice.

Starting the service and configuring the login are two separate steps:

/etc/init.d/tailscale start
tailscale up --accept-dns=false --advertise-routes=10.0.0.0/24

The first starts the daemon. The second is the client doing the login and applying settings: --accept-dns=false keeps the router from handing DNS to the tailnet, and --advertise-routes=10.0.0.0/24 makes this device a router for that subnet. Use the URL the command prints to authenticate in a browser. The README pairs this with enabling the service at boot:

/etc/init.d/tailscale enable

Verify it took with a glob over the boot symlinks, which the README says confirms a symlink to the service:

ls /etc/rc.d/S*tailscale*

The real budget line is 27 MB of RAM in /tmp

The README is unusually specific about space: you need at least 11 plus 16, so roughly 27 MB, free in /tmp, and it reminds you that /tmp is usually in RAM on this class of device. That number is the two downloads, the tailscale client and the daemon, living outside the flash filesystem. On a low powered router with a small RAM pool, this is the constraint that decides whether the approach is viable at all, and the repository description says as much when it calls the target low powered OpenWRT devices. Two consequences follow. The extracted stubs persist across reboots, the downloads do not, so a reboot costs a fresh fetch before traffic flows. A memory-starved router also needs enough room in /tmp for the temporary files.

Upgrading means editing a version string inside two binaries

There is no update mechanism and no package manager entry to repoint. The README describes grabbing the latest static package from pkgs.tailscale.com, whose filenames look like 1.2.10_mips, and replacing that version in both /usr/bin/tailscale and /usr/bin/tailscaled:

version="1.2.10_mips"

The version string is embedded in the stub, so the update is a manual edit of two files and nothing else verifies that the pair matches. Release tags in the repository carry an autoupdate suffix, for example v1.92.3-f6c833b-autoupdate, and the most recent is dated 2026-01-09, so the archive itself does not carry the newest client either. Expect to repeat this edit whenever you want a Tailscale version bump, and expect the tag in the filename to include your architecture.

Nothing in the repository handles configuration, only startup

Look at what the project contains and does not. There is no UCI integration, no LuCI page, no firewall rule for the tunnel, and no documented setting that persists across the enable step. The README's step five, rebooting and finding the device in the Tailscale admin portal, is the only end to end check it offers. Your login state, your advertised routes and your accept-dns choice are whatever the tailscale client stored when you ran tailscale up. That is workable for a single router added once and left alone, and thinner than you would want for a fleet, where each device needs the same treatment and the same version string edited.

Against building the package for your own firmware

The alternative is to build a Tailscale package for your OpenWRT target and install it through opkg, or to bake the static binaries into a custom firmware image. The difference in approach is where the download happens. A package in the firmware downloads once, lands in flash rather than in RAM, and upgrades with the rest of the system, so the 27 MB of /tmp disappears along with the first-run delay. What you give up is the property that makes this project attractive: it runs on a stock router with nothing rebuilt. The same static tarball from pkgs.tailscale.com can also simply be placed on the device yourself, in which case this project's contribution is the init script and the boot enablement, not the binaries.

Editorial conclusion

openwrt-tailscale-enabler suits someone with an OpenWRT router whose firmware package feed does not carry Tailscale and who wants mesh VPN on it with a boot time start, and the four command install is as short as this category gets. It is the wrong tool if your router has little free RAM, since the working set lands in /tmp, or if you want unattended upgrades, because changing the version means editing the embedded version string in /usr/bin/tailscale and /usr/bin/tailscaled by hand. Verify first that you have the 11 plus 16 MB the binaries need free in /tmp, and that kmod-tun loads on your kernel, before you start. The last push was on 2026-10-11 and the repository is not archived.

Frequently asked questions

Official sources

1. adyanth/openwrt-tailscale-enabler on GitHub
2. Issues
3. License: MIT
4. README
5. Releases