[kwsantiago]

Bumps the wrapped upstream client from Tailscale 1.102.5 to 1.104.1 (the current stable release), per UPDATING.md. This is a client-line jump, 1.102 to 1.104.

Changes

• Dockerfile: ghcr.io/tailscale/tailscale:v1.102.5 -> v1.104.1
• startos/versions/current.ts: 1.102.5:1 -> 1.104.1:0, with release notes in all five supported locales

No migration is needed: nothing in the package's on-disk state (tailscaled.state, serve-config.json, ts-status.json) changes shape across the bump, so migrations.up stays a no-op.

What 1.104.1 brings

Relevant to this package:

• "Client-side netmap caching improves start up speed and connectivity when the Tailscale control plane is unreachable." (Linux)
• "WireGuard packet buffering uses less memory while waiting for peer handshakes." and "WireGuard packet queue depth scales with CPU core count, reducing peak memory usage under heavy traffic." (all platforms)
• "WireGuard allocates a single packet buffer for batched I/O, improving throughput and reducing memory usage." (Linux)
• "An issue that could prevent traffic over IPv6 link-local addresses from flowing through direct and Tailscale Peer Relay connections is resolved." (Linux)
• Go is updated to 1.27. The container image entry for 1.104.1 is "This version contains no changes except for library updates."

The rest is desktop and mobile only. 1.104.0 was a release candidate for testing only, so 1.104.1 is the first shipping release of this line.

One change worth calling out, and why it does not apply here

1.104 changes serve's listener binding: Tailscale Serve on Linux now listens only on the Tailscale interface, and a new TS_SERVE_ALLOW_ALL_INTERFACES envknob opts back out. That reads like it could affect this package's serve routes, so I checked the source rather than assuming.

It does not apply. The binding change is on localListener in ipn/ipnlocal/serve.go, which carries the comment "This is not used in userspace-networking mode" and exists "purely for connections from the machine itself, as that goes via the kernel". This package runs tailscaled --tun=userspace-networking, where serve traffic is intercepted by netstack instead. No envknob is needed, and the FROM bump is the whole change.

Verification

• ghcr.io/tailscale/tailscale:v1.104.1 publishes both linux/amd64 and linux/arm64 (and no riscv64, so the ARCHES := x86 arm override in the Makefile still holds). It is also what latest and stable now resolve to.
• Every CLI surface the package drives still exists in 1.104.1, checked against --help in the actual image: tailscaled --state/--socket/--tun, tailscale status --json, tailscale web --listen, tailscale serve --bg --http/--https/--tcp, tailscale serve status --json, tailscale serve reset, tailscale funnel --bg --https, tailscale funnel reset. /bin/hostname is still present for the device-name step.
• Ran tailscaled --tun=userspace-networking in the new image: tailscale status --json still emits the two fields startos/fileModels/status.ts parses (BackendState and Self.DNSName), and tailscale serve status --json exits 0 with {} on an unconfigured node, which is what checkServes parses.
• Checked the ServeStatus shape in startos/utils.ts against ipn/serve.go at the v1.104.1 tag: TCP, Web, AllowFunnel, and the nested HTTP, HTTPS, TCPForward, Handlers and Proxy fields all still marshal under those names.
• tsc --noEmit and prettier --check startos pass.
• make builds clean for both arches, both reporting v1.104.1:0.

Not verified: a live install on StartOS with a real tailnet sign-in, including an actual serve applied against a signed-in node. I have no hardware to run that against here. Given the serve listener change above, that is the one thing worth a smoke test on hardware before release even though the source says userspace-networking is unaffected.