Introducing TSLink: Share Local Services by Name

TSLink starts with a practical task: open an app or file running on one machine from another device in your Tailscale tailnet. It registers each service as a separate tsnet node, gives it a name, and lets you retrieve its address later. Tailscale already offers private sharing through Serve; TSLink adds a registry for multiple named services and structured CLI/MCP handoffs.

Install TSLink v0.1.1.

First private share

With a web app already listening on localhost:3000:

tslink share 3000 --name preview --json

The result contains a live private URL or data.status: needs_login with data.auth_url. If approval is needed, open that URL, approve the new node, then ask TSLink for the live address:

tslink url preview --wait

Open the returned URL on another device connected to the same tailnet and allowed by its policy. The same share path works for a local file or directory. Quick Start has the full first-run sequence.

Manage more than one service

Use tslink add to keep named services (it starts the background gateway when needed), and tslink list or tslink status --urls to inspect them. Proxy and file HTTP services can use --allow to filter requests by Tailscale identity; raw TCP relies on tailnet policy and the target's own authentication. Each node's network identity does not isolate processes on the host.

For current automation, CLI --json and the MCP control server expose structured operations. Earlier development builds also had a local JSON-over-stdio interface; that top-level command has since been retired. Hosting a third-party MCP server is a separate task: register that HTTP server as a proxy service.

TSLink remains a local tool under development. The roadmap distinguishes shipped behavior from experimental ideas.