TSLink v0.2.0: one gateway share for several private apps

TSLink v0.2.0 adds opt-in portal gateway mode for sharing one or more apps with someone outside your tailnet. The visitor installs Tailscale, signs in with the granted account and accepts one device share of the portal node. You can then change which routed apps they may open without sending another invitation. Per-app sharing remains the default.

TSLink is an independent project, not made or endorsed by Tailscale.

Turn on gateway mode

For an already registered private HTTP or file app named photos:

tslink portal enable --owner you@example.com --gateway
tslink portal route add photos
tslink portal route list --json
tslink status --urls

Finish portal enrollment if prompted. The dashboard uses HTTPS port 443; each app route uses its own HTTPS port, allocated from 8443-8499 by default. Use the exact returned addresses.

For a new outside visitor:

tslink people add alice@example.com --apps photos --for 7d --invite --print-links

Replace the accounts with actual Tailscale logins. Invitation creation requires a stored user-owned Tailscale API token; send the generated message yourself and keep its bearer link private. For an existing person, use people update. Each request is checked against people grants, and Tailscale network policy still applies. See gateway mode for setup, private recipient steps and stale-invitation recovery.

Gateway mode also supports portal-only apps and explicitly registered HTTPS apps on other hosts. Remote apps use an observed tagged gateway; the remote host authenticates that gateway, not the visitor. There is no automatic multi-host discovery. TCP, Funnel and guest-link apps cannot be gateway routes. Apps on gateway ports share cookies, so retain application authentication and check app compatibility.

Health checks

HTTP checks without an explicit status range now accept 200-399, without following redirects. Unexpected status or body responses remain degraded and send no app_down alert. Only unreachable backends become down after three consecutive failures. Status includes the observed status_code, and doctor reports app_probe_unexpected_response for an unexpected answer.

Use the new health-only edit instead of replacing the app with add:

tslink health set photos --path /health

Choose the app's actual health path. This changes health settings while retaining access, tags, people scope, routes and enrollment. The owner MCP tool health_set provides the same operation. Read health checks.

Upgrade

1. Upgrade the binary through your installation channel. For Homebrew:

   brew upgrade --cask anydoor7/tap/tslink

   For Scoop, run scoop update, then scoop update tslink. Archive/package users download the v0.2.0 release through the installation guide.

2. If TSLink runs as a background service, run tslink install again so it starts the new binary.

3. Check tslink status --json and tslink doctor --json, then test the app from a permitted receiving device.

Compatibility and downgrade

Existing registries keep their schema version until gateway mode is configured. Gateway state uses registry schema 3, which older releases refuse.

Before downgrading, stop the new daemon, back up the registry and portal state, then use v0.2.0 to remove or replace portal-only/remote apps, remove all routes and disable gateway mode. Recorded gateway invitations keep schema 3 even with gateway off; if any remain, restore a pre-gateway registry backup, losing later people and invite changes. Confirm device shares and authorization expectations before starting an older daemon. Follow the full downgrade procedure; replacing only the binary is not a downgrade.

Read the site changelog and TSLink v0.2.0 changelog for the complete release notes.

Markdown version.