About hostlocal

Zero-install, browser-based localhost tunneling — powered by WebRTC peer-to-peer. No accounts. No CLI. No forwarded ports. Just a URL.

What is this?

A developer visits the site, types in a local port number, and gets a shareable link. They send that link to a friend or colleague. The friend opens the link and sees whatever is running on the developer’s localhost — live, in their browser.

The only requirement: the host browser tab must stay open while the session is active.

How it works

hostlocal is a signaling server paired with a browser-side WebRTC proxy. When the host starts a tunnel, their browser connects to the signaling server, which brokers a WebRTC handshake between the host and each viewer. Once the peer connection is established, all HTTP traffic travels directly between the two browsers — the server never sees the contents of your local site.

Host browser          Signaling Server        Viewer browser
(localhost:3000)      (hostlocal.io)          (friend's browser)

  1. Enter port  →  create session    →
  2. Get link                           →  open link
  3. WebRTC offer → relay offer/ICE   →  WebRTC answer
  4. ═══════════════ P2P data channel ════════════════
  5. HTTP fetch   ←──────────────────────── request page
  6. proxy :3000  ──────────────────────→   render site

For connections that cannot go direct (corporate firewalls, symmetric NAT), a TURN relay server provides a fallback path. The connection quality indicator in the host dashboard shows green for direct P2P, yellow for TURN-relayed, and red when the connection has failed.

Privacy & data

The signaling server only ever sees opaque WebRTC handshake messages (SDP offers, ICE candidates). It does not see the content of your HTTP requests or responses. Sessions are held in memory and deleted when the host disconnects. Nothing is written to disk.

When connecting across the internet, both peers’ public IP addresses are disclosed to the STUN server during ICE candidate gathering. This is standard WebRTC behaviour. No session content is sent to the STUN server.

Tech stack

Node.js — signaling server (TypeScript)
WebRTC — peer-to-peer data channel
WebSockets — signaling transport
Service Worker — intercepts viewer fetches and routes them through the tunnel
STUN — Google’s free stun.l.google.com
TURN — Metered.ca (optional, for NAT traversal fallback)

Session limits

Anonymous sessions (no login) expire after 3 hours and use STUN-only NAT traversal. Authenticated sessions (free account) do not expire and include a TURN relay for connections behind symmetric NAT. See the Plans page for a full comparison.

FAQ

Do I need to install anything?

No. hostlocal runs entirely in the browser. Open the site, enter your port, and share the link. Your colleague needs only a modern browser too.

Why does my local server need CORS headers?

The viewer’s browser fetches your local site from the hostlocal origin. Without CORS headers, the browser’s security policy blocks cross-origin responses. Add Access-Control-Allow-Origin: * to your local server’s responses. Most dev servers have a one-line option to enable this (e.g. server.cors: true in Vite, cors() middleware in Express).

What happens if the host closes their tab?

The server keeps the session open for 30 seconds to allow a page refresh to reconnect. If the host does not reconnect within that window, the session is deleted and viewers will see a “host disconnected” message.

Can multiple people view at the same time?

Yes. Each viewer gets their own dedicated WebRTC peer connection. The host dashboard shows a row per viewer with a live connection quality indicator.

Does this work over the internet (not just a LAN)?

Yes, that is the primary use case. WebRTC with STUN handles most network topologies. For connections behind symmetric NAT (common on some corporate networks), the TURN relay server provides a fallback path.

Is the traffic encrypted?

Yes. WebRTC data channels are encrypted with DTLS-SRTP by the browser — this is mandatory for all WebRTC implementations. The signaling server communicates over HTTPS/WSS in production.

Can I self-host this?

Yes. The server is a single Node.js process. Clone the repo, run npm install && npm run dev, and point a browser at http://localhost:8000.

What ports and protocols does the viewer’s browser need access to?

The viewer needs outbound HTTPS and WebSocket access to the signaling server, plus outbound UDP (or TCP fallback) for WebRTC. If UDP is blocked entirely, the TURN relay uses TCP port 443, which passes most firewalls.