Shared Tunnels

How a shared tunnel works#

A standard tunnel carries traffic to one machine. A shared tunnel carries it to every machine connected to it: a request arrives once, and each connected teammate receives their own complete copy of it at the same moment.

The URL belongs to the tunnel, not to whoever is connected, so the platform sending the traffic sees one stable endpoint no matter who is online. One connected client is the primary and its reply is returned to the sender; everyone else receives the request as a mirror, which keeps three people debugging the same integration from sending three conflicting answers back.

To follow along you need a Localport account and something listening on a local port on each machine that will connect.

Step 1: Install the agent#

Follow Installation, then confirm it with localport --version. It takes a few seconds: one dependency-free binary for macOS, Linux, and Windows.

Step 2: Create a shared tunnel in the dashboard#

Open dashboard.localport.io, go to Shared, and click New. The create panel asks for a name, a region, and, if you have one ready, a custom domain.

Choose the region closest to your team: that is where incoming traffic lands before it is carried to each machine. The name is a label you can change at any time, and changing it does not change the URL.

Step 3: Bring the URL online#

The dashboard moves to the Connect step and builds the command. Copy it and run it on your machine.

localport http 3000 --token tok_k8f2 --region eu

Everything that arrives at your tunnel URL is carried to port 3000 on your machine, exactly as it was sent. Every flag and form is in the CLI reference.

Forwarding is the URL, and it is the same on every machine that connects to this tunnel. Local is the port on your own machine. Leave the command running; Ctrl+C disconnects only you.

Step 4: Add your URL to the platforms that send you traffic#

The URL is persistent. It is saved to your tunnel, survives restarts and reconnects, and stays yours while nobody is connected, so it can be registered once and left alone.

https://team-webhooks.eu.localport.dev/webhooks/stripe

From then on, every event that platform sends is delivered to every connected teammate, with the same body and the same headers, at the same time.

Step 5: Invite your team, and let them connect themselves#

Nobody passes a credential around by hand. Invite teammates from the Invite teammates row in the connect panel or from your team's Members page, choosing Developer for read and connect access or Admin to manage the tunnel as well.

Once they accept, they open the shared tunnel, press Connect, and run the command the dashboard builds for them against whatever port their own app uses. From that moment they receive every incoming request alongside everyone else.

Any number of teammates, joining at any time#

Connections are independent, so the tunnel behaves the same with one person on it or twenty.

• Join at any point. A teammate who connects mid-afternoon receives from the very next request. Nobody restarts, and no traffic is interrupted.
• Leave the same way. Ctrl+C disconnects that one client. The URL stays live and everyone still connected keeps receiving without a gap.
• The tunnel outlives the session. With nobody connected, the tunnel and its URL stay saved to your account, ready for the next person who runs the command.

Each connected client counts as one client on the tunnel, and the tunnel's client limit is the ceiling.

See who is connected#

The Clients tab is the live view of your team: who is connected, how long they have been on, their IP, live connections, and total requests processed.

The Primary chip marks the client whose reply is returned to the sender. The first client to connect takes it, Set primary moves it, and if the primary disconnects another client takes over immediately. Disconnect drops one client and Disconnect all clears the tunnel, neither of which touches the URL.

Control who reaches it, and where your team connects from#

A shared URL is a public URL, so the tunnel's Network & Security settings give you a lock on both directions.

• Inbound IP Whitelist decides who can reach the URL. Enter the ranges the sending platform publishes and everything else is refused, which pins your endpoint to the one service that is supposed to be calling it.
• Network IPs decides where the tunnel can be joined from. List your office ranges or your VPN and a teammate can only connect the agent from there, so the tunnel stays unreachable from an unfamiliar network even with a valid token.

Both accept plain IPs or CIDR ranges, and blank means no restriction. Basic Auth and Force HTTPS are available too, though many platforms will not send credentials, so check before enabling basic auth. The HTTP tunnels guide covers each in full.

Give the URL your own domain#

Attach a domain you own in the tunnel's General settings and traffic arrives at https://hooks.acme.com instead. Setup is one CNAME record, covered in the custom domains guide, and nothing else changes: same tunnel, same clients, same commands.

You can also edit the Subdomain field in General to any available word, checked for availability as you type.

What else teams point a shared tunnel at#

• Platform events of every kind. Repository pushes, chat slash commands, SMS callbacks, store orders. One endpoint per platform, the whole team receiving.
• QA and engineering on the same traffic. A tester triggers a flow once and the developer sees the identical request land locally, with no reproduction step in between.
• A staging environment alongside a laptop. Point a staging box at the same tunnel and it receives everything a local machine does.
• A stream that is not HTTP. Shared tunnels also carry TCP, where the whole connection is mirrored to every client and only the primary's bytes travel back.

---

Frequently asked questions#

How do several developers receive the same webhook at once?

Create a shared tunnel, add your teammates to the team, and have each of them run the connect command the dashboard builds, pointed at their own local port. Register the tunnel's URL with the sending platform once. Every incoming request is delivered to every connected client at the same time.

Which client replies to the platform sending the traffic?

The primary client. The first client to connect takes that role, it can be moved to anyone in the Clients tab with Set primary, and if it disconnects another client takes over immediately. Everyone else receives a complete mirror of the request and their replies are discarded, so the sender only ever gets one answer.

Does the URL change when someone joins or leaves?

No. The URL belongs to the tunnel and is saved to your account. It survives restarts, reconnects, and periods with nobody connected, so an endpoint you registered with a platform never needs editing.

Can I restrict who reaches the URL, or where my team connects from?

Both. Inbound IP Whitelist limits which addresses can reach the URL, so you can pin it to the ranges the sending platform publishes. Network IPs limits where the tunnel can be joined from, so the agent only connects from your office or VPN ranges. Each takes IPs or CIDR ranges, and blank means no restriction.

Does everyone need to use the same local port?

No. The port is per machine. One teammate can run their app on 3000 and another on 8080; each agent carries the traffic to whatever port that person passed on the command line.

How do I add a teammate to a shared tunnel?

Invite them from the Invite teammates row in the connect panel or the team's Members page. Once they accept, they open the tunnel themselves, press Connect, and copy their command. There is no per-person setup and nothing to distribute by hand.

Do WebSockets work on a shared tunnel?

A connection that upgrades to a WebSocket or a server-sent-event stream is handled by the primary client alone, because a live bidirectional stream cannot be split across machines. Ordinary HTTP requests on the same tunnel keep reaching every connected client.

Can a shared tunnel carry TCP?

Yes, with different semantics: a raw stream has no request boundaries, so the whole connection is mirrored to every connected client and only the primary's bytes travel back. TLS passthrough cannot be shared, because each handshake is negotiated with the primary alone and nobody else could decrypt it. See TCP tunnels.

What is the difference between a shared tunnel and a mesh tunnel?

A shared tunnel is one address that every connected client receives. A mesh tunnel is the inverse: each device gets its own address, and a request reaches the one device you addressed.

What to read next#

• Webhook Development. Platform-by-platform setup for Stripe, GitHub, Slack, and Twilio.
• HTTP & HTTPS Tunnels. Everything an HTTP tunnel can do, including basic auth and IP rules.
• Custom Domains. Put the team's URL on a domain you own.
• Mesh Tunnels. One tunnel, many devices, each with its own address.
• Locked Tunnels. Require a client certificate before any request reaches you — on a single or mesh tunnel. A shared tunnel cannot be locked: it fans one request to every client, so there is no single destination to grant access to, and its callers are webhook senders that present no certificate. Turn on webhook signature verification in the tunnel's settings instead — that is the gate that belongs on a shared tunnel, and it checks the sender's own HMAC.
• CLI. Every flag, option, and exit code.