--- title: "TSLink, Tailscale Serve, Services and Public Tunnels" description: "Choose a sharing workflow for one service, several local apps, stable multi-host services or a public URL." url: "https://tslink.md/docs/comparisons" locale: "en" product_version: "0.1.1" source: "https://github.com/anydoor7/tslink/blob/v0.1.1/docs/comparison.md" --- > Documentation index: https://tslink.md/llms.txt · Installed binary is authoritative: `tslink manifest`. TSLink fits when you run several apps on one computer and want private per-app addresses, named-person deadlines for HTTP/files, and CLI or MCP lifecycle management. Tailscale Serve and Services already offer service publishing; choose by the workflow you need. The choices below are workflow judgments based on official documentation, not performance benchmarks. Serve and Services addressing checked on October 7, 2026. | Tool | A useful starting point when… | What to account for | | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TSLink | One person runs multiple local apps and wants to manage people, deadlines, invitations and recipes | Apps stay on the publishing host. Recipients need Tailscale for private access. Source install requires Go; browser guest links and MCP scopes are shipped, with explicit public/private boundaries. | | [Tailscale Serve](https://tailscale.com/docs/reference/tailscale-cli/serve) | You already run the Tailscale client and want to share a local service, file or TCP forwarder | Serve supports multiple ports on a device hostname; TSLink's per-app embedded nodes are a different operating model. | | [Tailscale Services](https://tailscale.com/docs/features/tailscale-services) | You administer named resources across hosts and want the address to survive host moves or redundant hosts | Services already has stable named services, traffic steering, access controls and host approval. Follow its admin and service-host setup. | | [ngrok](https://ngrok.com/docs/start) | You need a public localhost endpoint for a webhook, demo or external client | Configure endpoint policy and authentication for the audience. Public tunneling does not mean authentication is unavailable. | | [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) | You want outbound connections from your origin to Cloudflare's network | Decide separately which apps are public and which need Access policies. Account, domain and connector setup differ from tailnet enrollment. | For the task-by-task setup and limits, read [When do you need TSLink? Tailscale alone vs TSLink](https://tslink.md/docs/when-to-use-tslink.md). ## TSLink versus Tailscale Serve Serve is enough when device-hostname routes on one or more ports meet your needs. Reuse the Tailscale client you already operate. TSLink embeds a node for each app and keeps their registrations together. Its added workflow includes app recipes, health observations, named people with deadlines, invitation bundles and CLI JSON/MCP operations. TSLink supplies the sharing lifecycle. You still install, configure and run the backend application, retain its own authentication, and keep the publishing computer available. See [share with a person](https://tslink.md/docs/people-sharing.md) and [health checks](https://tslink.md/docs/health-and-alerts.md). ## TSLink versus official Tailscale Services Official Services already decouples service names from hosting devices. For example, its documented command form is `tailscale serve --service=svc:web-server --https=443 localhost:3000`, after the service and host approvals are configured. TSLink's distinction is the local multi-app, per-person lifecycle workflow. It does not provide Services' multi-host routing or high availability, and independent TSLink computers do not form a synchronized cluster. Both depend on Tailscale policy and suitable application security. ## Private sharing or a public tunnel? For a teammate or family member with a Tailscale account, [private people sharing](https://tslink.md/docs/people-sharing.md) can constrain new HTTP/file requests to their login and deadline. Outsiders accept one Tailscale app invitation per app; a bundle reduces owner commands, not recipient accepts. For a finite browser visit, TSLink offers [single-app guest links](https://tslink.md/docs/guest-links.md) with a mandatory gate and optional PIN over public Funnel. The link/PIN can be forwarded and does not identify a person. Open Funnel remains a separate explicit publication; keep application authentication. People revocation cannot recall downloads or end already accepted private streams; guest revoke/expiry cancels tracked guest streams. Read [MCP roles](https://tslink.md/docs/mcp-scopes.md) for bounded delegation and [portal](https://tslink.md/docs/portal-requests.md) for a private per-host directory. Multi-host inventory remains planned. TSLink is an independent project, not an official Tailscale product. Next: [Installation](https://tslink.md/docs/installation.md) · [Local AI](https://tslink.md/docs/local-ai.md) · [Agent/MCP setup](https://tslink.md/docs/mcp-server.md). Sources: official documentation linked above, and [TSLink comparison](https://github.com/anydoor7/tslink/blob/v0.1.1/docs/comparison.md).