---
title: "TSLink v0.2.0: one gateway share for several private apps"
description: "Opt-in portal gateway mode, health-check changes, upgrade steps and registry compatibility."
url: "https://tslink.md/blog/tslink-v0-2-0"
locale: "en"
product_version: "0.2.0"
source: "https://github.com/anydoor7/tslink/blob/v0.2.0/CHANGELOG.md"
---

> Documentation index: https://tslink.md/llms.txt · Installed binary is authoritative: `tslink manifest`.

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`:

```bash
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:

```bash
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](https://tslink.md/docs/portal-gateway.md) 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`:

```bash
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](https://tslink.md/docs/health-and-alerts.md).

## Upgrade

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

   ```bash
   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](https://tslink.md/docs/installation.md).
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](https://tslink.md/docs/portal-gateway.md#registry-schema-and-downgrade); replacing only the binary is not a downgrade.

Read the [site changelog](https://tslink.md/changelog) and [TSLink v0.2.0 changelog](https://github.com/anydoor7/tslink/blob/v0.2.0/CHANGELOG.md) for the complete release notes.

[Markdown version](https://tslink.md/blog/tslink-v0-2-0.md).