> Give every device in a fleet its own public URL with mesh tunnels. One token, many devices. Built for IoT, dev environments, and multi-device setups.

# Mesh Tunnels

Mesh tunnels give every device in a fleet its own public address under a single tunnel. Name each device once, and it's reachable by name forever — no matter where it's running, what network it's on, or how many siblings it has.

## When to use a mesh tunnel

A standard tunnel is one connection, one URL. If you're running ten Raspberry Pis, you'd need ten tunnels and ten tokens — and you'd have to invent your own naming system on top. That doesn't scale.

Mesh tunnels fix this. One tunnel, one token, and every device that connects gets:

- Its own subdomain: `sensor-1.abc123.tunnel.localport.dev`
- Its own TCP port (for non-HTTP services)

## Setting it up

### 1. Create a mesh tunnel

In the [Localport dashboard](https://dashboard.localport.io), go to your team and click **Mesh**. Create a new mesh tunnel. You'll get a single token that all devices share.

### 2. Connect devices

On each device, run the CLI with a unique `--name`:

```bash
# Device 1
localport http 8080 --token MESH_TOKEN --name sensor-1

# Device 2
localport http 8080 --token MESH_TOKEN --name sensor-2

# Device 3
localport http 8080 --token MESH_TOKEN --name camera-front
```

### 3. Access any device by name

Each device is reachable at its own URL:

```
https://sensor-1.abc123.tunnel.localport.dev
https://sensor-2.abc123.tunnel.localport.dev
https://camera-front.abc123.tunnel.localport.dev
```

For TCP devices, each also gets a dedicated port:

```
tcp://sensor-1.abc123.tunnel.localport.dev:25001
tcp://sensor-2.abc123.tunnel.localport.dev:25002
```

## How device names work

The `--name` flag becomes part of the URL. Names are cleaned automatically for DNS compatibility:

| You type | URL becomes |
|---|---|
| `--name sensor-1` | `sensor1.abc123.tunnel...` |
| `--name My.Laptop` | `mylaptop.abc123.tunnel...` |
| `--name pi-zero-kitchen` | `pizerokitchen.abc123.tunnel...` |

If two devices use the same name, the second one gets a numeric suffix (`-2`, `-3`, etc.).

## Reconnection behavior

When a device disconnects — network hiccup, reboot, whatever — its port and subdomain are reserved for 60 seconds. If it reconnects within that window, it gets the exact same address back. No URL changes, no downtime for monitoring systems.

> [!INFO] Stable during network blips
> This reservation system means short outages don't break your monitoring dashboards, scripts, or bookmarks.

## Mixed protocols

Mesh tunnels support mixing HTTP, TCP, and TLS clients on the same tunnel. One device can serve a web dashboard over HTTP while another exposes SSH over TCP — both under the same mesh.

## Requirements

- Available on all plans
- Each connected device counts toward your client limit

## Use cases

- **IoT fleets** — Raspberry Pis, sensors, cameras, each individually addressable. [IoT guide](/docs/iot-devices)
- **Dev environments** — Every developer's machine gets its own URL within a shared tunnel
- **Edge computing** — Distributed compute nodes, each directly reachable
- **Kiosks and displays** — Manage screens in different locations through one tunnel

## Next steps

- [IoT Device Management](/docs/iot-devices) — Deployment guide for device fleets
- [Locked Tunnels](/docs/locked-tunnels) — Add mutual TLS so only devices you've issued certificates to can join the mesh
- [Shared Tunnels](/docs/shared-tunnels) — Broadcast traffic to all clients instead
- [Homelab Remote Access](/docs/homelab) — Tunnel self-hosted services at home